[From Bruce Abbott (2018.02.16.1500)]
In a previous post I briefly described the Lego Mindstorms EV3 robotics kit and pointed to a few examples of simple control systems posted on my YouTube channel. In this post I describe my efforts to implement a self-righting rotary inverted pendulum based on an example from another YouTube site.
On my YouTube channel I have a video showing the inverted pendulum demo I created in software for Bill Powers’ Living Control Systems III (https://www.youtube.com/watch?v=ceboW9ZaF04 ). This was slightly modified from the LCS III version in that it is capable of self-inversion, i.e., it can bring the pendulum to a balanced inverted position starting from hanging straight down. My goal was to build a version of this based on the EV3. Unfortunately, Lego does not offer a rotary angle sensor other than those that are built into the EV3’s large and medium motors, and I needed one that could rotate freely in order to record pendulum angle, so I ordered a Lego-compatible angle sensor from a second party vendor, HiTechnic.
Because I wanted the system to be self-inverting, I needed to provide space for the pendulum to hang down. My first attempt involved having the pendulum pivot mounted on the side of the motorized cart. The cart was placed next to the edge of a counter top with the pendulum hanging down over the edge. Unfortunately, this proved not to work well, as the inertial forces generated by the swinging pendulum as the cart moved fore and aft caused the cart to turn so that it was no longer running parallel to the counter edge, causing the pendulum to strike the side of the counter. I could have removed this flaw by creating a fixed track on which the cart could run, but by this time had found a different arrangement that looked more attractive to me as it eliminates the problem of the cart potentially running out of room on the counter. This different arrangement is called a rotary inverted pendulum. In this configuration, the pendulum is mounted on a horizontal arm whose other end connects to a motor shaft. The motor can turn the arm clockwise or counterclockwise at varying speeds in order to keep the inverted pendulum balanced. It can also swing the pendulum from an initial downwar-hanging position to the inverted position. Because the pendulum pivot travels in a circle, there is no worry about running out of room in which to move the pivot in order to keep the pendulum balanced.
The video showing the rotary inverted pendulum on which I based my version is located here:
https://www.youtube.com/watch?v=xrPAGlFUDlQ
This system does not use the standard Lego EV3 motors; rather, a Lego Power Functions motor has been pressed into service. This motor was used because it has less slop in the gear-train than the EV3 motors, thus permitting more precise control over shaft position. The motor lacks the rotary encoders of the EV3 motors, so a second-party encoder has been substituted, with the advantage that its readings are more precise than those of the encoders in the EV3 motors (plus or minus 0.5 degrees versus plus or minus 1 degree).
Below is my version, which uses a standard EV3 medium motor and a HiTechnic angle sensor. This angle sensor includes a Mindstorms programming block that can be downloaded from the company and installed in the Mindstorms programming environment.
Because the HiTecnic angle sensor is larger than the one used in the video and is housed in a small enclosure similar to those of the standard EV3 sensors, I had to make changes to the design. The extra bulk and mass of the sensor as well as the need to mount it to other Lego parts meant that I could not simply mount it on the end of the motor shaft coming from the medium motor below. Instead, the sensor, arm, and pendulum mount on a turntable, with the motor shaft passing through to the base holding the sensor. Without the turntable, the mass of the suspended parts is great enough to cause the plastic shaft from the motor to flex. Consequently the horizontal arm pivots vertically as the pendulum swings and this induces a rather chaotic motion in the pendulum, which is being swing both back and forth and because of the flex, slightly up and down. I had to add the turntable and stiffen the shaft in an effort to reduce this effect, but was unable to eliminate it entirely.
A second problem is that the HiTechnic angle sensor proved to be rather noisy, with angle readings varying spontaneously by around plus or minus three degrees. Finally, the standard Lego EV3 cables are rather stiff and the one connected to the angle sensor tended to interfere with the horizontal rotation of the arm.
The builder of the rotary inverted pendulum was able to get around these problems by using two of the 0.5 degree precision angle encoders to measure motor-shaft and pendulum angles. These encoders are very lightweight and the cables used for them are also more flexible than the standard Lego cables, producing less interference to movement.
A final problem to mention is the flexibility of the plastic Lego shafts and other parts. Rapidly changing the motor’s direction causes the shaft to twist a little and function a bit like a torsion spring. This can add additional (and unwanted) dynamics to the system that the control system will have to deal with, if it can. In my case the extra mass of the turntable and HiTechnic sensor made the problem worse. For the system shown in the video there must be some shaft twisting but due to the light-weight sensor and mounting it evidently does not produce anything that the control system cannot handle.
The take-home lesson is that the EV3’s sensors, motors, and plastic parts do not necessarily make for a system that operates a precisely as one would like. For some applications this may not pose a significant problem but for others (such as this one), one might find it a bit wanting. The EV3 kit was, after all, designed mainly to serve as an education tool and not as a platform for serious robotics development.
That said, one still can learn a lot about control systems using the EV3. For example, I’ve programmed proportional controllers for the wheeled vehicles. Unlike our computer simulations, these do not require a leaky integrator output in order to perform well. Physical systems such as these induce their own integrations and lags due to inertia etc., making a leaky integrator in the output unnecessary.
Bruce
