My control systems prof said every engineer has done an inverted pendulum problem in school and nobody in their career has ever been asked to balance an inverted pendulum. So our final was a thermostat instead.
An unstable rocket (almost all of the big ones) is an inverted pendulum of sorts. The combined center of thrust and aerodynamic forces is usually below the C.G, and the rocket tends to tip over if not actively stabilized. To add a little, a slight margin of tipping is allowed, but the rocket tends to break up if the angle of attack crosses certain limit at high speeds.
Liquid fuel rockets complicate matters: think "inverted pendulum with a couple of stacked, full wine glasses that you absolutely must not spill balanced on top. Oh, and there's a gremlin drinking from them so both CG and total mass are constantly moving."
Yeah, his professor wasn't too bright if he said that. He probably never heard of Segway, One-Wheel, "hoverboards", or motorcycles with stability control.
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.
Is this still true? It seems like most IoT stuff has chips that easily eclipse the capabilities of my Amiga1000 and are 32bitbwith hardware floats. Looking around, I'm having trouble finding something that isn't a 32bitHF in my house. Possibly my Keurig machine? Even using digital instead of an RLC implementation in a coffee machine seems like a waste, but I'm old.
I've had about as many floating point PID implementations running on the attached core of an embedded ASIC as I have fixed point implementations (running fully within the hardware).
Even where the hardware is available, it can be harder to prove properties about the behavior of the floating point versions. It's no fun when everything turns to NaNs because of surprise cancellation in subtraction.
It's robust. I hamstrung the model solution by forcing pistonAcceleration to be 0, and forcing hingeAcceleration to be 0 during the first second, but it still "caught" and balanced the ball.
I'm still on the first level playing with various 'P's and 'D's (no 'I's yet), but I think I have a novel scheme!
function controlFunction(block)
{
let L = Math.floor;
let x = block.x;
// Use Collatz. L(x+½) is the closest integer.
return
-(L(x+0.5) % 2 === 0
? x/2 // Even, we chop it
: 3*x + 1 // Odd, we triple-plus-one it.
);
}
It's not very good, but it does beat or tie some of my earnest attempts to get below 8 seconds.
On the "Cruise Control Intro" challenge it's not made clear what the output of the controlFunction is. Am I returning a throttle position? A delta to the throttle position? Something else?
I didn't have any trouble until I got to "Ball on Platform: Balance" which seems to be multiple steps more difficult than the previous ones.
I think the variable limits are not always made clear. The objective is only really accessible on that first menu, otherwise you cannot re-check it. Errors in the console are mostly squashed and don't give important details like line numbers.
Don't get me wrong, I think this is really awesome! We are only talking about a few UI improvements to what is already an excellent resource.
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's exactly under the arrow at the times your digital controller measures it.
This would probably not be a concern in this digital simulator, but such an error can pop up when trying the same thing out in real life.
Readit News
The (spring loaded) inverted pendulum was one of the earliest analyzed models of legged locomotion.
Thats what all those self-balancing scooters are.
https://github.com/RhysU/helm
Both are useful.
Is the sample solution just hardcoded or is there some maths behind it to make it work from any location/initial speed?
Deleted Comment
Pretty neat website overall. Seems like I'll be wasting some time on it.
On the "Cruise Control Intro" challenge it's not made clear what the output of the controlFunction is. Am I returning a throttle position? A delta to the throttle position? Something else?
I didn't have any trouble until I got to "Ball on Platform: Balance" which seems to be multiple steps more difficult than the previous ones.
Don't get me wrong, I think this is really awesome! We are only talking about a few UI improvements to what is already an excellent resource.
This would probably not be a concern in this digital simulator, but such an error can pop up when trying the same thing out in real life.
See slide 17 here for a plot: https://www.slideserve.com/sibyl/finite-settling-time-design