Category Archives: Work

Job: Acquired

Plus: Why you shouldn’t keep your hotel room key in the same pocket as your phone.

Well, it’s finally happened.  After forty-five applications, twelve weeks, eleven interviews, five hotels, and five offers, I’ve finally accepted a full-time job.  And while I’m very thankful to have received so many nice options, I’ve got to say, job hunting kindof stinks.

If you’ve ever been jobless, you can probably relate to this.  For the past few months, my life has mostly consisted of hours upon hours of mindless internet job searches and lengthy, impersonal applications, punctuated only by the occasional nerve-racking interview or site visit.  Of course, traveling can be fun, especially when someone else is paying your way.  I had a blast traveling down to Austin, TX to interview with National Instruments (NI).  Those guys sure know how to make work fun.  They even paid for an extra day, giving me time to meet up with a good friend from college.

For me though, traveling gets old fast.  Fact: the word travel originates from the Middle English word travailen, which means “to toil.”  And my desire to toil was pretty much satisfied after my third on-site interview.  But of course, people in my line of work (electrical/mechanical engineering), don’t usually get job offers over the phone.  So to Indianapolis, IN I went for Dow AgroSciences.  To Austin, TX for NI.  To Kansas City, KS for Garmin.  To Waterloo, IA for John Deere.  And to St. Louis, MO for Boeing.

Now I’m psyched to say that after every on-site interview, I received an offer of employment.  So, five offers.  Pretty good offers, too (although sometimes that took a bit of negotiation).  And having so many options is great!  Awesome, even.  But it does make the decision-making process a little tougher.

However, after giving it a lot of thought and consideration, I’ve made up my mind.  So who did I choose?  Well, I suspect the image below will answer that:

John Deere 7530 Premium Series Tractor

Yes, I’m now employed by John Deere as an Engine Controls Applications Engineer.  I haven’t started work yet; that’ll happen on Dec. 6th.  But I’m already pretty excited.  I know, I know, they’re probably not going to let me drive the big tractors right away, but eventually.  🙂  For now, I’m keeping myself occupied by packing all my worldly posessions into surprisingly-expensive cardboard boxes.  I do hope the weather holds up next week, as I’ll be driving across I-90 in a big ol’ Penske truck.

Oh and I promised to address the issue of hotel keycards and cell phones.  Well, you probably know that most hotel keycards, like credit cards, have a magnetic stripe down one side which stores the data necessary to open your hotel room door.  You probably also know the this data can be rewritten by a specialized device which contains an electromagnet.  What you may not know is that these magnetic stripes come in two flavors: low-coercivity (LoCo) and high-coercivity (HiCo).  Credit cards normally use HiCo stripes, which last longer and can handle frequent use.  However, hotel keycards are rewritten so often that they are typically made with LoCo stripes.  The problem with low-coercivity stripes is that they’re susceptible to corruption by small magnets.

So why shouldn’t you put your keycard into the same pocket as your cell phone?  Well all phones contain at least one speaker of some kind, and all speakers contain magnets.  So if that speaker happens to get too close to your hotel keycard, it’s gonna wreak havoc with your card’s magnetic stripe.  I learned this the hard way a couple of months back.  So, keep hotel cards away from anything magnetic.  I’ve heard that even credit cards, if they get too close, can cause problems with hotel keys.  Who knew?

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!

Enter the XMOS

XMOS XC-2Funny how time flies. It seems like only yesterday I was scrambling around grabbing books, spec’ing parts, and testing components for my MS thesis. In fact it’s been almost a year since I wrapped up my design for a six-DOF laser-based position sensing system. But last September, I was busy pounding my head against a Xilinx Spartan-3AN FPGA development board (and given its numerous header pins, this wasn’t particularly pleasant).

What I needed was an easy way to run four independent 32-bit counters at 100+ Mhz, to communicate with eight discrete serial ADCs, to perform multiple floating-point calculations, and to return all of the resulting data to a control PC using a single high-speed serial line.

I was told, and still believe, that this should be no problem for an FPGA like the Spartan-3AN. Unfortunately, prior to this project, I had no experience with VHDL, Verilog, or anything having to do with FPGAs or CPLDs (besides the blessed CompactRIO). So needless to say, I was having all sorts of weird problems. I started off coding just a single counter in VHDL. It measured the time between digital interrupts and returned a value via a parallel interface. The only problem was that, at high frequencies (above 150Mhz), it would occasionally return bad data. Well, I could go on and on about my troubles with this FPGA, but I’ll cut to the chase. I was running out of time and needed a solution fast. So, I posted on SparkFun’s forum asking for recommendations. One of the guys suggested I look into XMOS. I’d never heard of it before and sortof dismissed the idea at first. I mean, a quad-core microprocessor? That didn’t sound very helpful. But given its ability to handle 10ns pin events and to run an almost unlimited number of counters at 100Mhz, I convinced my advisor to spend $150 on the XC-2:XMOS XC-2And boy am I glad I did. Once I got to writing code for the XMOS, I was an instant fan. Just take a look at the specifications for this powerful chip (the XS1-G4):

  • Four processor cores providing 1600MIPs (at 400Mhz) and up to 32 concurrent, deterministic real-time tasks.
  • Up to 64 input/output pins (per XCore) that can be dynamically configured as input, output or bi-directional.
  • Each port provides 10ns timing resolution for precise interfacing.
  • Next-cycle event servicing from pins, communications or timers.
  • The XMOS-originated XC language extends C to support parallelism and real-time control.
  • 64KBytes single-cycle unified SRAM (per XCore) for code and data storage.

This device was unlike anything I’d worked with in the past. And yet, I could code it in C or the C-like XC language (which supports parallel processing). This fact is what really set my mind at ease. The only slight issue was the lack of standard hardware modules you’d find in most microcontrollers; the XS1-G4 has no built-in hardware to transmit serial data, measure analog inputs, or generate PWM signals. But hey, neither do FPGAs. The plus here is that the XMOS has so much horsepower, you can implement anything in software.

The XC-2 development kit I received even came pre-programmed with a fancy web server demo application. All I had to do was plug it into the network, attach the supplied 5VDC power adapter, and point my browser to the correct address. And of course, the good folks at XMOS provided source code for the entire project, plus code for a generic Ethernet interface, digital audio transmission, UARTs, and more. I also found the XMOS support forums to be very helpful. I was actually able to explain my problem to the support staff and have them detail how it could be accomplished with this development board. Plus, there’s now the XCore Exchange community of users.

Now I imagine this is starting to sound like a paid endorsement of XMOS. But let me assure you, it’s not. I’m just a satisfied customer. The XC-2 helped me finish my thesis work much sooner than if I were to have stuck with the FPGA. In the end, my sensors were able resolve positional changes of less than 1mm in all directions.


So at $150, the XC-2 may be a little bit pricey for most hackers. However, if speed and power are what you’re looking for, you should seriously consider it. The single-core, $99 XK-1 module (pictured above) may also be worth looking into. Multiple XK-1s can also be linked together. I may pick one up myself if I find a good excuse. 🙂 Oh, and did I mention the development tools are free and unlimited? The package even includes a simulator so that you can try out your design without a device. You can download the tools for Windows, Mac, or Linux here. Have fun and let me know what you make!

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):

Talking in Toronto: IEEE CASE 2010

Last weekend (August 21-24) the sixth annual IEEE Conference on Automation Science and Engineering (CASE) was held in Toronto, Ontario. So I, being fortunate enough to have the General Chair as my thesis advisor, was invited to attend. Actually, I did more than just attend, I presented a portion of my MS thesis to a group of about 30 people. I have to say, it was pretty exciting. Now I think everything went well, but it’s hard to be objective about your own presentation. Plus, when you’re up there talking (and when you have no means of judging time because your cell phone died), time seems to run faster. Toronto was an interesting place – it reminded me a lot of New York City, actually. This was my view from the hotel room Sunday morning:

Toronto, Ontario

If you’re interested, my paper’s abstract can be found here: CASE 2010 Paper Abstract. It was given the very exciting title, “Application of 6-DOF Sensing for Robotic Disturbance Compensation.” As a quick summary, the paper begins with a discussion of my work developing a 6-DOF (degree-of-freedom) laser-based sensor. This custom sensor measures not only the position of an object in 3D space, but also its orientation – pitch, roll, and yaw. Its positional accuracy is as good as 1mm over a 15m x 10m x 1m area. The end application for this sensor involves measuring the base position of a robot and using that data to stabilize the robot’s end-effector at a desired location. Here’s one example we whipped up to show the robot’s motion with and without compensation:

Disturbance Compensation ExampleThe robot in use here is the Stäubli TX90. It’s a six-axis industrial robot capable of moving a 25kg payload within its 1m reach. In this example it’s mounted to a freely oscillating platform (think diving board) along with our sensor package. The sensors measure the position of the base, then relay that information to the control system. The control system makes the appropriate adjustments and calculations, then sends corrections to the robot.

In the picture above, the robot was first programmed to draw a house shape using a red dry-erase marker without disturbance compensation. That is, its base was oscillating, but the end-effector was not compensating. Then, the compensation system was enabled and a black marker was used to draw the same shape. As you can see from the above image, after an initial “turn-on” squiggle, the black line shows very little error compared with the red line. This is the ultimate goal of the system – to maintain a desired position despite potentially large motions in the base of the robot. In this case, the base was moving by up to 50mm while the end-effector was stabilized to within 2mm.

I’m looking forward to writing more about the inner workings of the sensor system at some point in the future (particularly after our patent clears the USPTO). So, until next time!

P.S. Driving across the US-Canada border is no picnic. That is, unless you brought food and drink, in which case just roll a blanket over the hood of your car and settle down for a bite. Actually, I only had to wait about 30 minutes to get into Canada and 40 minutes to return to the US. My friends on the train, however, were stopped for a full three hours on the return trip while everyone was processed. Anyway, advice for anyone stuck in this situation: don’t change lanes. It never helps, plus it frustrates the agents and pretty much every driver in your vicinity. Yay for courtesy! 🙂