Earlier quoted context omitted.
None of which existed in 1995
Ok, then how about the gun barrel stabilizers on tanks and gunships which had PID controllers since WW2.
Now compare those to the number of thermostats built since that time
PID Control Challenges
71–80 of 123 posts
Re: PID Control Challenges
#72Shouldn't this have some thrust limits? I'm not sure if they are added later(I've only seen the first example), but it would make the problems more realistic, interesting and related to control theory.
Re: PID Control Challenges
#73Some sort of 'high score' would be nice so I can understand how close my solution is to the ideal. Pretty neat website overall. Seems like I'll be wasting some time on it.
The ideal solution, given that there is not input limit, depends on the simulation accuracy. Theoretically, you could achieve 0 time solutions.
Re: PID Control Challenges
#74Earlier quoted context omitted.
best solutions will be "Insane value to instantly teleport to the point. Insane anti-value to instantly stop."
I think what you are suggesting is similar to the "dead-beat controller" in discrete-time control literature. While a controller designed with this method can get the position error measured at the sampling times to zero very quickly, it gives no guarantees that the error stays zero between the samples. This means the block could be wildly oscillating around the arrow in reality, but oscillating in such a way that it…
It's actually a concern due to simulation error.
Re: PID Control Challenges
#75I cheated on level one and entered: function controlFunction(block) { let x = 5; if (block.dx > 0) { x = block.dx; } if (block.T > 1.75) { return 0; } return 2 * x; }
Why is that cheating? But it is still very slow, I got it down to 0.42 seconds. function controlFunction(block) { const t = Math.round(block.T / 0.02); return (t Misses the target by 6.1E-16 at an velocity of 6.3E-15. But yes, this should probably randomize the initial conditions or parameters like friction and gravity a bit so that you actually have to control the system.
It's cheating because real world PID controllers only apply linear feedback, i.e. feedback expressed by a linear function. Ifs/elses etc. are not linear.
Re: PID Control Challenges
#76An “obvious in hindsight” (I missed it) application of control theory in general and PID controllers in particular is exploring more of a corpus when the fleet is less loaded in an IR setting. @ajtulloch might be the world’s leading expert in making 100 billion bucks in 2 months with a device that can be built out of mechanical parts.
Could you elaborate please.
Re: PID Control Challenges
#77Shouldn't this have some thrust limits? I'm not sure if they are added later(I've only seen the first example), but it would make the problems more realistic, interesting and related to control theory.
I believe there are hidden ones.
Re: PID Control Challenges
#78Re: PID Control Challenges
#79Earlier quoted context omitted.
True. Liquids make control difficult. > full wine glasses that you absolutely must not spill balanced I'm not sure what you mean by spilling. The liquids are usually contained in fully closed tanks and cannot spill. The thrust usually keeps the liquid at the bottom around the engine intakes. However, liquid sloshing inside the tanks is a problem. Even with slosh dampers, sloshing liquid manages to create attitude dis…
My inner child of Doc Brown and Wernher von Kerman says, it's time to develop non-newtonian fuel sponges, which would release fuel if squeezed gently and steadily, but behave like solid if things start shaking too much, preventing sloshing.
Or maybe giant syringes? There can't be sloshing if there is no free space because top of cylinder just moves to adjust volume.
Re: PID Control Challenges
#80Earlier quoted context omitted.
It's a nice theoretical implementation but few practical examples would be found using floating-point math, running as they are on systems that don't support it.
I find this hard to believe. Even a humble arduino can do 34,000 software float divides per second. https://gist.github.com/cellularmitosis/506c878631f806cfe6f8...
It can but that doesn't mean it's a great idea.
Unless your chip has a hardware floating point unit, you're stuck using software float operations. They're slower, though not extraordinarily so. But the main drawback is the floating point library can massively inflate your code size to the point that it no longer fits in available memory.
If you can get away with it, it's fine, but when you can't it's a huge problem.