We aren't quite to PID controllers in the class I'm teaching yet, but getting there. Any ideas on a good demo to build? I was thinking of controlling the angle of a paddle blown by a fan, inverted pendulum, or something like that. (Assuming I have time to build a demo). I saw this demo and would love to make it, but it's not in the cards this time around.
Project-wise, Balance Bots are getting common, sensor fusion, Kalman fitering etc. Are your students comfy with gyros & accelerometer? Simple BBs have also been done using just a Ping sensor or Sharp IR sensor. Still requires PID.
There was a lab exercise the CS under grads used to do in my uni which I thought was kind of cool:
A big ball bearing would be free to run along a couple of feet of horizontal aluminium L section.
One end of the L section was hinged and the other end was lifted and lowered by a motor, thus causing the ball bearing to run from one end to the other.
The position of the ball was measured resistively by means of some resistive film on the inside of the L section.
Enter the computer control. A PDP-11, would get the ball position and drive the motor and the students control code would try to drive it to some set point.
Of course you can build this with different materials, a rolling wheel rather than a steel ball bearing, different position sensors etc.
I was thinking of controlling the angle of a paddle blown by a fan
That's pretty good, as would be a heater/thermostat system. Something which (unlike a balance bot/inverted pendulum) has a slow response time and can be initially controlled by gross bang bang commands and improved by a PID loop. You could gather data points (Stamp plot lite, etc) and analyze the system response as variables are changed.
I thought about the heater/thermostat problem. What with me being "heater" and all.
Somehow I'm not so keen on it because it's a bit hard. A PID controller can drive the system up or down in an attempt to achieve what it wants. But usually with a temperature controller you can apply more or less heat to drive things up but you cannot drive cooling to drive things down. You are out of control in that case.
Anyway, it's not as dramatic as actually positioning something. Preferably something with a bit of inertia so that it will overshoot in the bang-bang case.
Positioning a paddle position controlled by a fan has the same issues. But a pivoting beam whose position is controlled by a fan at each end sounds like a winner. Like a one dimension quad copter. THat might appeal to students. A balancing bot with two arms with fans at the ends.
There was a lab exercise the CS under grads used to do in my uni which I thought was kind of cool:
A big ball bearing would be free to run along a couple of feet of horizontal aluminium L section.
One end of the L section was hinged and the other end was lifted and lowered by a motor, thus causing the ball bearing to run from one end to the other.
The position of the ball was measured resistively by means of some resistive film on the inside of the L slection.
Enter the computer control. A PDP-11, would get the ball position and drive the motor and the students control code would try to drive it to some set point.
Of course you can build this with different materials, a rolling wheel rather than a steel ball bearing, different position sensors etc.
Wow! Lots of great ideas. The students only know sensor basics, but for a demo they won't need it all.
For a thermal demo - I saw one awhile back with a fan and light to give heating/cooling capability. I like the beam with props on each end or fans below it balancing it.
What about a ping pong ball suspended by air in a tube? Some inertia and a system that pushes back.
On the other hand, how about keeping it super simple? Balancing bots and balls on plates might be impressive demos but they might also be overwhelming for students who are just starting out and perhaps don't have sophisticated maths chops.
Super simple would be just build a servo.
Get a motor. A nice big demo sized one! Attach some kind of position encoder, a pot would do. Attach a wheel to give it some inertia so that it will overshoot a bit. Add a pointer to indicate its position. Get a position command signal from another pot. Simple, self evident, PID demo.
Has the great advantage that you can build it pretty quickly.
Way back in the 1970's our chemistry teacher posed this problem for us kids: "I put a box on the desk in front of you. After some time the box flips onto it's side. Then again on to it's next side. What is in the box?". We scratched our heads and eventually I thought here might be some mass on a lever that gets wound up and released, the resulting reaction tipping the box. Using the magic of reaction wheels did not occur to me despite having played with gyros and such before.
A few months ago I was visiting a company in Helsinki that is about to put up some Cube Sats. I asked how they steer the thing to keep the Earth facing camera they have on board pointing in the right direction. Easy the director said, we have a flywheel on a motor in each direction. Reaction wheels.
Satellites and even the ISS use reaction wheels for orientation control. Really small satellites have used magneto-torquers to work against the Earth's magnetic field and people have even used the gravitational gradient to hold orientation.
A servo - that is a simple demo as well... Hmmm. Now the question is can I build a demo before we get there in the lectures? We use PID in the lab to control some hydraulic rams, but not wanting to introduce all of that complication to them. (See photo)
Not hydraulic but one of my favorite achievements back in technical school was building a couple of J-K Flip Flops, basically a 2 bit binary counter, out of 1 meter long pneumatic rams and spool valves.
Still trying to understand what goes on with some of these items undergoing extreme pressure.
Batteries I know, but diskettes throwing out black clouds of what looks like noxious fumes I don't get. Then again the magnetic material that they are coated with could be making what looks like smoke.
The ball bearing subjected to the press was a real eye opener, explosive!
The best Hydraulic Press Channel video is one in which he decides it must be possible to fold a sheet of paper in half more than 7 times by squishing it in the press.
In squishing down the last fold the paper block explodes violently. He ends up with a sheet of solid, powdery, ceramic like stuff.
The thing is that is a serious press he has there. When that squishes things a huge lot of energy is put into a small space. That is to say heat.
I'm sure applying heat to floppy disks can release a lot of noxious fumes.
I love the hydraulic press channel. Our instrument is a 1 MN biaxial press we use to look at the frictional behavior of materials. We shear powders and rocks at 0.1 um/s - 1 mm/s under normal loads of 1 - 100 MPa generally. A lot of fun!
On page 8 is the typical diagram of the upside down pendulum control problem.
On page 9 is a strange looking signal flow diagram. The symbols are defined in later pages. After staring at it for a while it seems to be the simplest expression of the dynamics of the inverted pendulum I have ever seen.
All it needs is to continue the signal flow diagram with the PID control loop and we can simulate the whole thing in a few lines of code.
Heater, that's really neat. I had an idea a few years ago for a math program that works similarly to those diagrams, but never found the time to really do much with the idea. It's like LabVIEW, except you can plug outputs into each other and it will do the algebra and calculus and figure it out. You'd be able to describe a system to it in either diagrammatic or algebraic notation, and it would solve it for the correct inputs and outputs, compile it using LLVM or something, and either output an object file that you can include in your program or use the compiled function to do an efficient interactive visualization.
Somehow that is really neat. But I'm not quite sure why or how. I keep getting drawn back to that paper and wondering what it's about really.
On the one hand electronics and control systems engineers have been drawing signal flow diagrams like that since forever. Kind of high level block diagrams or maps of what their system does. But as far as I can tell they have been kind of informal things. Make up whatever symbols and connect them how you like.
On the other hand John Baez is a serious mathematician and into Category Theory. Whatever that is. In maths everything has to be rigorously defined.
To that end most of that paper seems to be about making strict definitions of a set of symbols for such signal flow diagrams. Their precise meaning and what it means to combine them. Rather like in maths you first have to define exactly what your numbers are, and what the operators "+", "-", etc, do, and what happens when you combine "+" with "*" etc.
On the other hand he seems to be making connections between Control Theory from the electronics world and Category Theory from the maths world. Here I am lost. What is this "monoide"of which you speak?
The inverted pendulum problem there is just an example he uses to show the point. But it amazes me. Normally when you read about the inverted pendulum problem they develop a mathematical model of the system, including angular momentum and stuff, ending up with some equation. Then they talk about the control system, which may include some signal flow diagram. Here however it shows that the system you are controlling is a mess of "signals", actual physical quantities like speed and angle, that can be represented in a signal flow graph. It's a really neat picture.
Actually it sounds like a language I worked in years ago, Lucol, that was used for aircraft control systems.
In Lucol things go like this:
1) Your program is run on a time tick, every 10ms or whatever.
2) All input's are read and all outputs updated on every run.
3) Your program has no internal state, no local variables.
4) There were no loop constructs in the Lucol language. Your code starts at the top runs through a bunch of statements, including conditionals, and ends at the bottom.
5) As there were no loops the execution time of a Lucol program was known exactly, very important for real-time, safety critical systems. If you wanted to iterate you just had to do it over multiple runs of your code.
With that in place Lucol could produce beautiful control flow diagrams from your source.
Also, the absence of loop constructs and internal state makes this "Functional Programming" and reasoning about the correctness of such code possible.
Given Lucol rules as above it would be relatively easy to create a GUI program that allowed drawing signal flow graphs as shown in the paper and generate code from them. In C or Spin or whatever language.
Only hiccup here is that feed back loop shown in the inverted pendulum diagram, the angle θ. That loop would have to be broken. θ would have to be an output at the bottom and come in as a new θ at the top.
I think that would be quite a neat project. And not such a huge undertaking.
Given that one has created a GUI program that allows drawing the signal flow diagrams....
Let's assume that it maintains some data structure of the nodes and connections. A net or graph.
Let's assume we get rid of those loops. In the example the outputs of the g/l and -mg nodes would have to go out the bottom and get pushed in as new inputs at the top.
What we have then is a simple DAG, Directed Acyclic Graph. The Acyclic just means no loops. It makes generating code easy.
Just start at an input, follow the edges of the graph, emit some code for the nodes you meet. That emitted code is just a function call with the inputs as parameters.
Until you have reached an output or some node has missing inputs.
I've done exactly this - Maya has a directed graph called the HyperGraph, and I wrote a tool to compile it into token code. We ran that on a virtual machine, or compiled it directly to C++. That system is partly what makes the players and other characters in the NBA2K series move realistically. It was challenging to get right, but a fun project too.
Who would of thought it? One can be modeling dynamical systems and generating control algorithms for then in Maya.
Now I have an itch to do this in Javascript in the browser and use webgl to animate the model. It could emit Spin or PASM or C control code for the real thing.
Comments
Project-wise, Balance Bots are getting common, sensor fusion, Kalman fitering etc. Are your students comfy with gyros & accelerometer? Simple BBs have also been done using just a Ping sensor or Sharp IR sensor. Still requires PID.
A big ball bearing would be free to run along a couple of feet of horizontal aluminium L section.
One end of the L section was hinged and the other end was lifted and lowered by a motor, thus causing the ball bearing to run from one end to the other.
The position of the ball was measured resistively by means of some resistive film on the inside of the L section.
Enter the computer control. A PDP-11, would get the ball position and drive the motor and the students control code would try to drive it to some set point.
Of course you can build this with different materials, a rolling wheel rather than a steel ball bearing, different position sensors etc.
That's pretty good, as would be a heater/thermostat system. Something which (unlike a balance bot/inverted pendulum) has a slow response time and can be initially controlled by gross bang bang commands and improved by a PID loop. You could gather data points (Stamp plot lite, etc) and analyze the system response as variables are changed.
Somehow I'm not so keen on it because it's a bit hard. A PID controller can drive the system up or down in an attempt to achieve what it wants. But usually with a temperature controller you can apply more or less heat to drive things up but you cannot drive cooling to drive things down. You are out of control in that case.
Anyway, it's not as dramatic as actually positioning something. Preferably something with a bit of inertia so that it will overshoot in the bang-bang case.
Positioning a paddle position controlled by a fan has the same issues. But a pivoting beam whose position is controlled by a fan at each end sounds like a winner. Like a one dimension quad copter. THat might appeal to students. A balancing bot with two arms with fans at the ends.
Cool....I might just build one of these.
Re: Resistive feedback from the plate; If your ball was heavy enough, you could use an old Koalapad for sensing.
Doesn't that have to many servos? Surely we only need to gimble the thing in two dimensions?
Like so:
For a thermal demo - I saw one awhile back with a fan and light to give heating/cooling capability. I like the beam with props on each end or fans below it balancing it.
What about a ping pong ball suspended by air in a tube? Some inertia and a system that pushes back.
Not sure I would go to the trouble to make a balance bot like in video two, cool to watch but that all it does.
Video three is baffling, erco gave some possibilitys on how it was done. And the simpler ball and plate in video four was a treat to see.
Very entertaining.
Super simple would be just build a servo.
Get a motor. A nice big demo sized one! Attach some kind of position encoder, a pot would do. Attach a wheel to give it some inertia so that it will overshoot a bit. Add a pointer to indicate its position. Get a position command signal from another pot. Simple, self evident, PID demo.
Has the great advantage that you can build it pretty quickly.
Way back in the 1970's our chemistry teacher posed this problem for us kids: "I put a box on the desk in front of you. After some time the box flips onto it's side. Then again on to it's next side. What is in the box?". We scratched our heads and eventually I thought here might be some mass on a lever that gets wound up and released, the resulting reaction tipping the box. Using the magic of reaction wheels did not occur to me despite having played with gyros and such before.
A few months ago I was visiting a company in Helsinki that is about to put up some Cube Sats. I asked how they steer the thing to keep the Earth facing camera they have on board pointing in the right direction. Easy the director said, we have a flywheel on a motor in each direction. Reaction wheels.
https://www.reaktor.com/blog/introducing-the-reaktor-hello-world-satellite/
Seems satellites have been doing this since forever.
A servo - that is a simple demo as well... Hmmm. Now the question is can I build a demo before we get there in the lectures? We use PID in the lab to control some hydraulic rams, but not wanting to introduce all of that complication to them. (See photo)
Not hydraulic but one of my favorite achievements back in technical school was building a couple of J-K Flip Flops, basically a 2 bit binary counter, out of 1 meter long pneumatic rams and spool valves.
Yeah, go for simple.
This guy is dangerous, I bet there is no outdated tech in his house. And his scoop shovel is probably flat too.
I love his accent. He is Finnish and around here they call that "Rally Driver English".
Such a simple idea, and one million YouTube subscribers!
It's kind of an obsessive view of endless destruction!
Especially sweet when it's devices going under the press that have annoyed you before.
Batteries I know, but diskettes throwing out black clouds of what looks like noxious fumes I don't get. Then again the magnetic material that they are coated with could be making what looks like smoke.
The ball bearing subjected to the press was a real eye opener, explosive!
http://forums.parallax.com/discussion/164542/ball-bearing-explosion#latest
In squishing down the last fold the paper block explodes violently. He ends up with a sheet of solid, powdery, ceramic like stuff.
The thing is that is a serious press he has there. When that squishes things a huge lot of energy is put into a small space. That is to say heat.
I'm sure applying heat to floppy disks can release a lot of noxious fumes.
Whilst aimlessly browsing unrelated mathematical things I found a bit of a gem regarding application of Category Theory (Whatever that is) to control systems by mathematician John Baez. http://math.ucr.edu/home/baez/networks_warsaw/control_web_warsaw.pdf
On page 8 is the typical diagram of the upside down pendulum control problem.
On page 9 is a strange looking signal flow diagram. The symbols are defined in later pages. After staring at it for a while it seems to be the simplest expression of the dynamics of the inverted pendulum I have ever seen.
All it needs is to continue the signal flow diagram with the PID control loop and we can simulate the whole thing in a few lines of code.
Anyway, thought someone here might be interested.
Somehow that is really neat. But I'm not quite sure why or how. I keep getting drawn back to that paper and wondering what it's about really.
On the one hand electronics and control systems engineers have been drawing signal flow diagrams like that since forever. Kind of high level block diagrams or maps of what their system does. But as far as I can tell they have been kind of informal things. Make up whatever symbols and connect them how you like.
On the other hand John Baez is a serious mathematician and into Category Theory. Whatever that is. In maths everything has to be rigorously defined.
To that end most of that paper seems to be about making strict definitions of a set of symbols for such signal flow diagrams. Their precise meaning and what it means to combine them. Rather like in maths you first have to define exactly what your numbers are, and what the operators "+", "-", etc, do, and what happens when you combine "+" with "*" etc.
On the other hand he seems to be making connections between Control Theory from the electronics world and Category Theory from the maths world. Here I am lost. What is this "monoide"of which you speak?
The inverted pendulum problem there is just an example he uses to show the point. But it amazes me. Normally when you read about the inverted pendulum problem they develop a mathematical model of the system, including angular momentum and stuff, ending up with some equation. Then they talk about the control system, which may include some signal flow diagram. Here however it shows that the system you are controlling is a mess of "signals", actual physical quantities like speed and angle, that can be represented in a signal flow graph. It's a really neat picture.
Just random thoughts...
Random thoughts, part two ...
That maths program idea has been done I think.
Actually it sounds like a language I worked in years ago, Lucol, that was used for aircraft control systems.
In Lucol things go like this:
1) Your program is run on a time tick, every 10ms or whatever.
2) All input's are read and all outputs updated on every run.
3) Your program has no internal state, no local variables.
4) There were no loop constructs in the Lucol language. Your code starts at the top runs through a bunch of statements, including conditionals, and ends at the bottom.
5) As there were no loops the execution time of a Lucol program was known exactly, very important for real-time, safety critical systems. If you wanted to iterate you just had to do it over multiple runs of your code.
With that in place Lucol could produce beautiful control flow diagrams from your source.
Also, the absence of loop constructs and internal state makes this "Functional Programming" and reasoning about the correctness of such code possible.
Given Lucol rules as above it would be relatively easy to create a GUI program that allowed drawing signal flow graphs as shown in the paper and generate code from them. In C or Spin or whatever language.
Only hiccup here is that feed back loop shown in the inverted pendulum diagram, the angle θ. That loop would have to be broken. θ would have to be an output at the bottom and come in as a new θ at the top.
I think that would be quite a neat project. And not such a huge undertaking.
Random thoughts, part three ...
Given that one has created a GUI program that allows drawing the signal flow diagrams....
Let's assume that it maintains some data structure of the nodes and connections. A net or graph.
Let's assume we get rid of those loops. In the example the outputs of the g/l and -mg nodes would have to go out the bottom and get pushed in as new inputs at the top.
What we have then is a simple DAG, Directed Acyclic Graph. The Acyclic just means no loops. It makes generating code easy.
Just start at an input, follow the edges of the graph, emit some code for the nodes you meet. That emitted code is just a function call with the inputs as parameters.
Until you have reached an output or some node has missing inputs.
Process the next input similarly.
And so on until all the inputs have been handled.
Who would of thought it? One can be modeling dynamical systems and generating control algorithms for then in Maya.
Now I have an itch to do this in Javascript in the browser and use webgl to animate the model. It could emit Spin or PASM or C control code for the real thing.