Today’s post is going to be a trip down memory lane for me. The TVIP or Thrust-Vectoring Inverted Pendulum was my very first real engineering project in college. My good friend Alex and I constructed it almost five years ago, during the second semester of our freshman year at RPI. We actually started designing the system during our very first semester. However, the bulk of our work was performed for an independent study in the [former] RPI Mechatronics lab during the spring of 2006. By the way, in case you’re wondering, the RPI Mechatronics lab closed down when Dr. Kevin Craig decided to leave RPI for Marquette University. Of course, he took most of the lab with him, and now runs the Multidisciplinary Mechatronics Innovations lab at Marquette!
Why do I bring this up now? Five years later? Well as I’ve mentioned before, I’ve been doing a lot of job interviewing lately. During interviews, the TVIP seems to come up pretty frequently. It’s still a great example of the work I did while employed in the Mechatronics lab. And I’m still pretty proud of this rickety old thing. I consider it to be quite an accomplishment, particularly for a pair of college freshmen. 🙂
So what exactly is the Thrust-Vectoring Inverted Pendulum? Well, like many Mechatronics lab projects, it’s a demonstration of control systems, mechanical dynamics, electronics, and modeling. To be more specific (and simple), it’s a big aluminum pendulum with a scary-looking propellor attached at the end. A diagram should help explain:
What you see there is a dual A-frame, about three feet tall, supporting a horizontal shaft to which a pendulum is connected. That shaft is suspended by a pair of bearings. An optical encoder is used to detect the angular position (angle θ) of the shaft and pendulum. At the end of the pendulum, the propellor and motor are attached to a geared DC servo motor, which is used to vary the direction (angle φ) of the propellor’s thrust. Hence the term thrust-vectoring (plus, five years ago, it sounded really cool).
Now the purpose of this setup was to demonstrate the control of an unstable system. Thus, our goal was to vary the direction and magnitude of the propellor’s thrust in order to swing up the pendulum and then balance it in its inverted, unstable position.
This was accomplished by using two separate control loops, both implemented within LabVIEW. The first controller was responsible for swing-up (since the propellor could not produce enough thrust to pull the pendulum straight up). As you’ll see in the video below, the swing-up algorithm was essentially a proportional controller with an excessively high gain. This actually caused the system to go into unstable oscillations. That sounds pretty bad, doesn’t it? But it’s exactly what we wanted. Just like a child on a playground swing, our proportional controller caused the pendulum to swing higher and higher. However, instead of continuing to let the system oscillate unchecked, once the pendulum started to close in on its balance point, LabVIEW switched the output over to a PID control loop. The job of this second controller was to catch the pendulum and then hold it, as closely as possible, in its verticle, inverted position. How about a video before I go on?
Now that video was taken at the conclusion of the Spring 2006 semester. You’ll notice that the pendulum still oscillates slightly (plus or minus about eight degrees) when inverted. This was due to an improperly tuned PID controller. We did improve that performance somewhat over the next year or so. During my later employment in the Mechatronics lab, I wrote up a paper that, unfortunately, never made it to publication. It contains a bit of the more serious math on modeling and control I didn’t really understand when Alex and I first designed this system. You’ll find a link to this paper at the end of my post.
So just what makes this thing tick? Well, the motor and propellor are pretty standard fare for RC electric planes. Of course that doesn’t make them any less scary. Running this thing indoors produced a lot of noise, and you had to keep clear of the pendulum while it was operating (lest you lose a finger). The propellor and motor were connected to a standard geared DC motor which was actually capable of rotating 360 degrees. This presented another safety hazard; if the positioning motor rotated too far, the prop would begin biting into the aluminum pendulum. Amazingly, in two years of operation, this never happened. But it could have. Control of this positioning motor was accomplished by a third PD control loop within LabVIEW. Angular feedback was given by an optical encoder.
Now we really should have bought a commercial, heavy-duty hobby servo in order to vector the thrust of our prop. This would have likely been safer and easier. But what did we know back then? Ultimately we solved the safety issue by replacing the propellor with a ducted fan. It didn’t quite produce as much thrust, but you didn’t have to worry about how to grab the pendulum in the event of a control/electronics failure.
And speaking of electronics failures, we did have a couple of frightening moments during our initial testing. The speed of the propellor motor was governed by a power MOSFET. Twice, that FET failed during operation; in both cases it failed by shorting. The result?
Instantaneous full-power thrust.
Pretty scary stuff, particularly since we first powered the prop motor using a 12V lead-acid battery. However, we also eventually replaced that battery (which you see in the video above) with a dedicated high-current power supply (the box with the RPI sticker).
Now as I started to mention earlier, both the propellor and positioning motors were driven by microcontroller-produced PWM signals wired into power transistors. We used a microcontroller (MCU) for PWM generation because the NI data acquisition (DAQ) hardware we had available at the time could not generate these signals. Instead, it produced analog outputs which were fed into the ADCs of our MCU. The MCU (an AVR ATTiny13) then produced PWM signals whose duty cycles were proportional to those analog inputs. Fortunately, the DAQ hardware we had could easily process our two quadrature encoder inputs into angular measurements.
Well I’ll leave the rest of the details to the paper linked below. If you’re interested in how to model this system mathematically, as well as how to implement the various controllers described here, have a read! I think you’ll find my test in characterizing the viscous damping of the ducted fan rather interesting. If only I’d had Eureqa back then… Oh, and I’ve also included MCU source code for the ADC-PWM conversion:
Paper: A Mechatronics Case Study: Thrust Vectoring and Control of an Unstable System
Schematic: GIF Image (Also available in the paper)
Feel free to make comments or ask questions in the comment section. Thanks!