Tag Archives: demo

The Mechatronics TVIP (+Video)

MechatronicsToday’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:

Thrust-Vectoring Inverted Pendulum (CAD Model)

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.

The Details

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.

The New Thrust-Vectoring Inverted Pendulum

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!

LabVIEW: Graphs, Files, and Dials, Oh My!

This summer I took on a small consulting job with the RPI Mechanical, Aerospace & Nuclear Engineering (MANE) department: to develop a completely new LabVIEW control interface for their subsonic wind tunnel. Their last interface had worked fine for awhile, but failed when new DAQ hardware was needed. However, the guys in charge wanted more than just an update, they wanted a completely new VI (virtual instrument) with all the bells and whistles. Here’s what I came up for them:

Wind Tunnel Control VI

The program consists of a single front panel from which tunnel speed can be controlled, along with a couple other settings. The graphs display both commanded and actual air speed, along with the pressure measured to determine actual speed. In addition there are a number of features which are less obvious:

  • The program maintains a commanded speed using a simple PI control loop. Essentially, the controller monitors the error between the commanded and actual speeds and sends speed commands to the fan motor which are proportional to that error. This error is also integrated over time so that the system will gradually compensate for any small errors that might be missed by simple proportional control. This results in a very tight speed regulation.
  • Data is logged for thirty seconds whenever the program starts or a change is made in any of the panel controls. (Separate programs were created for experiments done in the tunnel – this VI is for speed control only).
  • For safety, commanded speed is limited to 150 ft/s unless an “Instructor Password” is provided in the red box. If the correct password is given, the box turns green and the tunnel can be commanded to a maximum speed of 300 ft/s.
  • Total tunnel run-time is also recorded and is cumulative between runs of the program. This is done by storing a small configuration file in the computer’s application data directory (the computer is running Windows 7).

So why am I posting about this? In the hope that it may be a useful example for other LabVIEW users. The complete project can be downloaded at the link below. The block diagram is divided up based on a stacked sequence structure. The first step of that sequence simply opens files and writes headers. The most interesting bits really happen in the second step, which is shown here:

Wind Tunnel Control Block DiagramYes, there are quite a few structures mixed in there. While loops and event structures to detect control changes, timed loops to perform control and logging, and lots of logic case structures. The top large loop is used to perform logging, the second from the top runs the speed control loop, and the one below that takes care of data acquisition.

While I could go on and on about each element of this VI and its function, I imagine that would bore some folks. Plus, I’ve added a ton of comments that I hope you’ll find helpful. Feel free to ask any questions via comment or through the Contact page.

The files (created with LabVIEW 2009): wind_tunnel_control.zip

LabVIEW: Managing Interactive SubVIs

I do a lot of LabVIEW programming. Quite a lot, in fact. Fortunately, I rather enjoy a good block diagram. Plus, the ability to work with virtual instruments (VIs) for control and data acquisition seems highly prized at RPI. Either that, or nobody else wants to do it.

When building programs with LabVIEW, I often find it convenient to group code into subVIs. This can really help clean up a messy block diagram. Occasionally I’ll employ a subVI for user interaction of some type – a sophisticated dialog box, or perhaps a sub-application of sorts. But just how is this done? By default, a when you drag a subVI onto your block diagram, its front panel won’t show when executed. To force the front panel to display when called, first right-click on your subVI, then select “SubVI Node Setup.” Then simply check the following:

SubVI Node Setup

If checked, the option to “Close afterwards if originally closed” will close your subVI once it’s finished executing, if it started closed. This is typically my preference, but there may be a time when you want your subVI to stay open after it stops.

Of course, there are a few other tricks you may wish to employ. Perhaps you’d like your application to be reset its subVI’s values to defaults. Or maybe you’d like to run the subVI, but only display its front panel when certain conditions are true. All this and more is possible with the “Static VI Reference” block, found under “Programming” → “Application Control” and shown here:

Static VI Reference

Place this block on your diagram. Now drag your subVI onto the “Static VI Reference” block you’ve just created. You’ll notice it takes on the same icon as your subVI. From here there are a world of possibilities. To see what I mean, move your cursor over the reference output of this block (as if you were wiring it) and right-click. Next, select “Create” and then “Method for VI Class.”

VI Methods

From here, you can choose to run the subVI, show or hide its front panel, reset its values to default and more. If you back up a step on this menu tree and select “Property for VI Class,” you can further alter the appearance of the subVI window, including hiding buttons (abort, run, etc.) from the toolbar and changing the window title.

Hopefully you’ve found these tricks helpful! I’ll try to post more from time to time.

A Shiny Box of Fuel Cells

This week I completed the last of what RPI requires for a Master of Science degree in Electrical Engineering. Since I’d finished my thesis in the spring, I only needed three more credits to graduate. So I opted for a summer independent study. And what did I independently study? Fuel cells! (From an educator’s perspective.) It just so happened that my supervisor had previously purchased a commercial 300W PEM fuel cell stack. He wanted to use it in some sort of educational demonstration, but wasn’t sure exactly how to make that happen. So my project for the summer was to design and build just such a system. Our goals were to make the system:

  • Instructional for students of all ages
  • Portable and self-contained (no need to ever plug into AC power)
  • Visible (both the components and their connections)
  • Interactive (something you’d like to play with)

With this in mind I put together what I felt was a solid design, then went to work constructing it. With the help of some of my lab mates, we built the following:

Fuel Cell Demo System FrontWhat you see here is a large 80/20 box measuring about 30″ x 20″ x 11″ and covered with acrylic panels. As you probably guessed, the large red tank is the hydrogen supply, pressurized to 2000psi when full. That pressure is regulated down to about 6psi for the fuel cell stack. The gas passes through a ball flow meter and solenoid valve before reaching the fuel cell stack – located just to the left of and behind the red LED panel voltmeter.

Our fuel cell stack is produced by Horizon Fuel Cell Technologies, model H-300 (more details here). It’s an air-breathing PEM-type stack, composed of 72 individual fuel cells strung together in series. The voltage produced by the stack varies from 40-60VDC depending on the amount of current drawn. Now this variation is unsuitable for most electronics, so it’s first passed through a DC-DC converter (the largest black box just to the left of center). The converter takes the varying input voltage and steps it down to about 13VDC for use in the rest of the system.

You may also notice a 12V lead-acid battery strapped into the middle of the demo box. This serves two purposes. First, and most importantly, it provides power to the stack’s control module during startup. This is necessary to open the solenoid valve and engage the three fans mounted to the side of the stack. Second, it provides a bit of buffering during transients (e.g. when all the light bulbs are flipped on). One problem with fuel cells is that they cannot respond quickly to changing loads. Batteries, however, can rapidly supply more or less current without significant changes in voltage (large capacitors also have the same effect).

The rest of the system consists of an array of ten 12V, 13W light bulbs, a 120VAC inverter, and equipment to monitor voltages and current at several points within the system. This equipment is mounted to the rear of the system, shown here:

Fuel Cell Demo System Rear DAQ HardwareThe data acquisition (DAQ) module shown above is produced by National Instruments, model USB-6009, and is capable of monitoring eight analog inputs at 14-bit resolution. These analog inputs are fed from a custom PCB I designed, mounted directly below the DAQ module. This PCB is responsible for measuring currents using ACS712 hall-effect sensor ICs. It also performs voltage division so that the system’s voltages are within the measurement range of the DAQ. Last but not least, the PCB allows for computer control of the ten light bulbs using MOSFETs controlled by the DAQ’s digital outputs.

From the start, I knew I wanted to use LabVIEW to monitor and control the system – it’s built for data acquisition and handles simple controls quite well. The only question was, what sort of hardware should I run it with? Since I didn’t need much horesepower and in fact was looking to minimize electrical power consumption, I went with the Asus Eee PC, model 1001PX:

Asus Eee PC 1001PXWith its dual-core Atom processor, the 1001PX actually performs quite well running Windows XP. Its 20-30W power consumption (when charging) is equally impressive. Running LabVIEW 2009 presented no performance problems whatsoever. My only qualm is the lack of screen resolution – 1024 x 600 is just a bit tight most of the time. However, space was no issue since all of my LabVIEW VIs were compiled into executables without scrollbars, menubars, etc. Here’s how the main panel turned out:

LabVIEW Front Panel

From this panel the user can monitor voltage, current, and power at different points throughout the system. The light bulbs can be turned on and off with a single mouse click. I’ve also created VIs for taking polarization curves (voltage vs. current density) and for monitoring the stack’s voltage at high speed (48kHz) during transients. To top it all off, the Eee is loaded with a sample presentation containing the principles of operation for fuel cells as well as diagrams for the demo system itself.

The system has yet to be tested in a real classroom environment. Sadly, I may not be around to see that happen. But I’m pretty confident that it’ll be put to good use. The grand total for all parts in the system? About $4000. Thanks for reading!