Launching My Graduate Project

In the fall of 2011, I took Stochastic Signals and Systems at RPI Hartford with Dr. Mesyia, who is also my academic advisor. I approached him with an idea for a culminating graduate project. I wanted to design and implement a control for an arduino based two wheeled balancing robot, layering concepts from my classes into the design. He suggested I speak with Dr. Eberbach who had robotics research experience.

After discussing my background and project idea with Dr. Eberbach after one of his classes, he mentioned he would like to see more academic robot work and suggested I investigate classes and textbooks prior to starting the project. Taking that suggestion, I delayed my project one semester. Unfortunately, the recommended classes available at MIT and Carnegie Mellon could not fit in my schedule around work due to the travel time required. No robotics classes were available at local universities such as RPI and UConn for the fall semester that fit the bill either. Seeking alternative solutions, I thought it best to work through as much MIT OpenCourseWare material as possible while donating additional time to mentoring a local FIRST Robotics Team, 3182 - Athena's Warriors, for additional hands on exposure.

At the end of the fall 2011 semester, after working with Dr. Mesiya to get in contact with Dr. Eberbach again, Dr. Eberbach and I sat down on February 6th to discuss the project. We discussed the situation with the prerequisite scheduling, and decided the OpenCourseWare and mentoring would be enough to get started. We took some time to discuss the project options that were available, and decided that the original arduino project would be too difficult to complete in the time allowed. Since I would be creating the platform from scratch, the focus of the project would not be on the control design itself. As alternatives, my advisor suggested exploring the work on the robot the FIRST team put together to use for the project. Also, using my LEGO mindstorms platform designed for my control systems course could also be a potential option.

From these conversations I created my first project proposal and submitted it to Dr. Eberbach on February 13th. The proposal included a background section on how I got to where I am today with robotics, and a discussion of all the available options. Most importantly the proposal included a final composite of the definition and deliverables of this project: I would build a two-wheeled balancing robot from the LEGO Mindstorms kit, and implement a PID control with it's tuning values identified empirically, and using a linear quadratic regulator. I would also include video, code, and paper materials with the final deliverable.

A couple days later, Dr. Eberbach responds via email with some suggested improvements. Since none of the other options will be used in this project, they can be removed from the proposal. The background section could also be removed as he felt it unnecessary. He also suggested using evolutionary algorithms to tune the control rather than empirically or using the regulator.

Taking these considerations in mind, on February 23rd I submitted a second project proposal including Dr. Eberbach's suggestions, as well as an overview of mobile robotics and evolutionary algorithms. He accepted this proposal, and the project is underway! :)

Below is a copy of the second proposal's text. See the proposal for references.

Evolutionary Algorithms and Mobile Robotics

Overview of Mobile Robotics and Evolutionary Algorithms

A mobile robot is an agent who's main purpose is deeply rooted to it's ability to translate through its environment. The robot is situated in the real world and embodied by a physical chassis. However, for the purposes of simulation, the robot may solely exist in a virtual environment as a “softbot”. The robot's apparent intelligence is expressed by its interaction with the environment it inhabits. (Eberbach)

Mobile robotics is an area of increasingly active research with many academic institutions. This is especially true for mobile robots that have inherent instabilities and nonlinearities such as the class of balancing robots. These are generally difficult to control, but they also may provide more utility for a given task. (Fankhauser)

It may be possible to simplify the creation of controls for these complex mobile robotics using evolutionary algorithms. An evolutionary algorithm takes the burden of optimization off of the creator and leverages it with the system. From a space of all possible solutions, the poor solutions are removed, and better solutions are combined to create new solutions altogether. This is iterated using the space of new solutions until an ideal or suitable solution is found. (Eiben)

As it applies to mobile robotics, the evolutionary algorithm may be able to determine reasonable, if not optimal, tuning values for controls to keep the robot balanced. I would like to explore this area for my graduate project.

Definition and Deliverables

For my culminating graduate project, I will continue to build my proficiency in robot design and control using a two-wheeled LEGO balancing robot with some modest improvements derived from my earlier experiences at RPI. The overall design will remain the same enabling most of my focus to remain on the control. The only changes will use parts already in my possession, and will enhance the existing hardware for the control's ability to respond to stimuli.

I will then implement a PID control using tools such as Matlab and Simulink. I will use the Ziegler-Nichols tuning method to create a baseline of functional PID tuning values that at least keep the robot upright. I will then use evolutionary algorithms to determine tuning values which generate minimal overshoot and distance to keep the robot upright. These implementations will be deployed to the robot and it's behavior will be recorded.

For deliverables, I will record videos of the robot running each of these controls with a summary narration of their performance. I will discuss in detail the fundamental differences between the controls and their behavior in a paper. Throughout the evolution of the project, I will log my progress at least weekly in an internet blog at the address http://roboreflections.blogspot.com.

The Deadline

After my last post, I emailed my professor asking for help on the questions I was stuck on. He got back to me early yesterday giving me a lot of time to  (thanks!). Here are some realizations that followed.

In my last post, I noticed some very strange behavior from the model. The responses I was getting didn't agree with the LTI model responses. Turns out there were two problems. First, my selection of a time delay block was not the best choice. Since the rest of the model uses blocks intended for continuous time and the time delay block is explicitly discrete time, the response was undefined. My professor added the integrator block in its place and rewired signals accordingly.

I don't think this problem could have been avoided. I still consider myself a Simulink novice. A problem like this has to be tripped over before you can really understand what's going on under the hood, a classic learn-from-your-mistakes scenario.

Running the model with a initial angle offset of 5 was way to high for the non-linear simulation. Units for the angle of the platform in both the linear and non-linear models is radians. Since the linear model is reachable, it will glady map any input you give it to some 'reasonable' output. However, using 5rad (~280°) on the non-linear simulation model was sure to deliver unstable behavior. This violates the assumption from an earlier post that the angle will remain small.

This could have been avoided if I was more diligent tracking units through the modelling process. At the time that I arbitrarily picked 5 for the initial angle offset, if I had realised that the model was expecting radians at the time, I would have set a value that was more appropriate.

The following two charts show the response in the system and actuation after the corrections have been made. Poles are set to -3+i and -3-i, and initial angle offset is .35rad.

With these lessons learned, I prepared to build the software for the control. This would help me identify appropriate poles in conjunction with the characteristic polynomial identified in my last post.

A few basic properties and conversion factors needed to be found first. For example, the accelerometer outputs 0 → 50 when pitching up (leaning backward) from 0° → 90°, and 255 → 204 when pitching down (leaning forward) over the same range. Once converted to the same range of 0 → 50, scaled by (π/2)/50 (~0.0314). This is handled in one of two switch blocks in the section labelled "Raw Data Conversion to Radians". Another conversion needed to take place to get the velocity value into the motors. After doing some testing, 100% power correlates to ~.30897m/s.

Everything seemed ready for the first test, so I went forward with installing the software on the NXT, and for the first time ever... nothing happend. There was an "Error: Unknown error - Download program" error reported back from the transfer. Baffled, I did some research online. On forum post suggested re-flashing the firmware on the device. I gave it a try. In the middle of the "Preparing the NXT..." step, the NXT began to make a clicking sound. Figuring it was part of the flash procedure, I let it click for about fifteen minutes with no progress. Frustrated, I cancelled the flash restarted my computer and the NXT, and still nothing but clicks from the NXT. I believe that the unit did not fully accept the re-flash from my computer, and some additional time will be needed to debug the problem.

Frustrations in the Eleventh Hour

Well it's been a frustrating past couple of days. After a few multi-hour sessions of tinkering, I haven't made as much progress as I would have liked, but things are moving, ideas are still flowing.


Testing Against a Non-Linear Simulation

I've been focusing on designing a non-linear simulation model to test the controller from earlier this week. I was having trouble finding a way to pass the θ value back into the non-linear simulation to be re-evaluated. I tried directly wiring it, using a contortion of summations blocks, and building the entire non-linear simulation function in Simulink to pick out the value. It wasn't until a little earlier that I found the memory block which would do exactly what I wanted. I later opted that out for the unit delay block to do the same thing. I was finally able to complete the following which I believe should accurately test the control against the non-linear simulation.

In hindsight, using a unit delay block makes sense. Even though this exercise was not directly driving improvements to the project, it has greatly strengthened my skills with Matlab and Simulink. Before ECSE 4440, I had barely used this tool, even in my signals and systems class in undergrad. There were no projects or labs that used it. But my recent experiences have been my first major foray with the utilities and a lot has been learned.

That aside, I'm still wary of this model's behavior. Is there a better way of putting this together?

Assuming that this model is correct, the following are the responses to the same configuration as in my last post, with an initial angle offset of 5 and using arbitrary poles at 1+i and 1-i. The following plots are of the viewer locations marked at y (upper) and u (lower), where y is the angle (solid line) and angle delta (dashed line), and u is the acceleration of the base.

Something isn't right. The system eventually settles, but with some very odd behavior before hand. Possible sources of error include a faulty model, poles set to odd locations, or a controller design that can't completely handle the non-linear simulation. What does the above sort of response most likely suggest?

Also, just as a bit of eye candy (if you could call it that) and proof of the work I've put in, here's the model that breaks down the non-linear simulation function mapping acceleration to angle delta and the control. Note that this diagram is not complete. There are the beginnings of noise on the input, and the angle delta doesn't alter the current state of the angle. However, from what I found above, the state of the angle should be trivial to add with the unit delay block.

Identifying Reasonable Poles

Although the non-linear simulation work has taken most of my time, I've still managed to do a little work on identifying reasonable poles for the system. Below is the derivation which leads to the characteristic polynomial of the system. I should be able to compare this with it's canonical second-order representation to select poles for a reasonable rise time, overshoot, and settling time.

I haven't found a reasonable way to post my Matlab / Simulink files within this blog, so for the time being they remain unavailable from the web.

Properties and State Feedback

Properties

There are three essential properties identified in my last post that I must know about my platform before proceeding: l, the distance from the axle to the center of gravity, m, the mass of the platform with the axle and wheels, and M, the mass of the axel and wheels alone. It was easy to determine the center of gravity. I placed the platform flat on the edge of a table and slid it to the point of just about falling off. I measured the distance from this point to the axle.

The weight proved to be a bit of an issue though. My bathroom scale wasn't sensitive enough to pick up the whole platform on its own or with my help. I could have purchased a mail scale from Staples or a small shop scale from a hardware store for $40 or so, but this was outrageous just to weigh it once and be done with it. Instead, my little platform and I visited our local Shaw's and used the produce scales! :) I weighed the unit with and without the wheel and axles to find both measurements.

Plugging in the values above into the slightly modified matrices from my last post produces

Notice that the sensor matrix, C, has changed to include the change in angle. More on this in a moment.


Reachability

Before designing a state feedback control, to be certain that it can be controlled in the first place, it's good practice to determine that the steady state system is in fact reachable. To do this, we examine the rank of the reachability matrix W_r.

The rank of W_r for the model is 2 and is equal to the system matrix and is therefore controllable. Yay!


State Feedback Control

A typical state feedback control system can be diagrammed as below with reference input r, controller elements k_r and K, disturbance d, and output y.

Using the basic blocks found in Simulink I was able to mirror this design with the following diagram. Note that the stabilisation block should read "-K*uvec" with a negative sign in front of the K.

I had some trouble running basic simulations with my old steady state matrices. I missed a subtlety that designing this sort of control is based off the assumption that all components of the state vector are measured. In other words, y is the output of the next x. Without this, my simulations never settled or would oscillate. Altering the C matrix to pass along the change in angle state fixed the problem.

The response of this system to an initial offset of 5 is graphed below with poles arbitrarily set to -1+i and -1-i. y₁ is the angle of the platform, y₂ is the change in angle.

Looking forward, I'd like to identify more appropriate poles, test the controller against a non-linear simulation, and if that succeeds, install the controller on the platform.

Meeting and Modeling

A Brief Meeting

I sent an email off to my professor with a link to the blog earlier this week. He said it looked very good and interesting! I talked with him after class on Thursday to discuss the software I was using and the details of the project. We determined I should continue with the following steps:

1. Create a linear time-invariant (LTI) state space model of the platform
2. Design a simple state feedback control over the model
   
3. Perform pole placement on the control
   
4. Test the model against a non-linear simulation
5. Construct a discrete-time control to operate on the unit
6. Install the control on the platform
   

The State Space Model


As mentioned in an earlier post, the platform that I've created can be modelled by a cart and pendulum system. A diagram with the dynamics such that the position does not need to be controlled is

where γ is the coefficient of rotational friction, J_t = J + ml², and F is the force applied at the base. For my system, I'm going to neglect damping by setting γ = 0, break apart F into its acceleration and mass components, and assume J = ml² as in a cylindrical mass system. With these modification, the dynamics become

To convert this non-linear system to a LTI, I define the state of this system to be θ and the derivative of θ, and the actuation to be the acceleration a. I assume that θ = 0 is an equilibrium point and that the change in angle θ is small. This allows the system to be approximated as

It follows that the state space matrices should be

Now I must determine the properties of my platform to populate the variables of the state space matrices and find the poles of the system.

Mark I Control

Time to look at the control. An ideal PID control is defined as

where u is the control signal, e is the control error (reference minus actual), and k_p k_i and k_d are the proportional, integral, and derivative gains. For this project, the control signal will be the velocity requested from the motors, and the error will be the angle of tilt from the accelerometer.

The terms in the equation above can be thought of as accounting for the present, past, and future error of the system to be controlled. A simple proportional gain can be applied to the current error to get close to a reasonable control signal at the current time. An integral component can be added to help account for any deviation of the process value from the reference value over time. I plan to attempt adding both of the components to my controller. The derivative term, which predicts the future error, will probably generate too much noise and will be difficult to tweak. I do not intend to implement this, but will consider it if time allows.

Starting small, the first control I'm trying to work with is a simple P control. Assuming that the error from the accelerometer's orientation on the platform is negligible (r == 0), this is as reasonably respectable way to control this system.

To implement this, I created a program using the LEGO Mindstorms NXT 2.0 software with the accelerometer sensor block add-on. Coming from a strong software background, this seemed unnecessarily convoluted. Where are my variables? Where's my mathematics? All I wanted to do was type out some variables and leave it at that! But like anything else, doing an activity for the first time will always be the hardest time through. I stumbled through creating the following program.

The above program applies some gain to the tilt angle coming from the x-axis of the accelerometer and inputs it to the velocity of the motors. The direction of the motors is set with a separate connection and is based off the sign of the x-axis angle.

Using experimentation, I was unable to find an acceptable value for the proportional gain k_p using the program to keep the platform upright. There are many reasons why this might not work, but the biggest contributor at the moment is most likely my inexperience with the LEGO software.

I need to spend more time experimenting with the LEGO software before I can call this one way or another.

Mark I Platform

Here is my first pass at a prototyping platform. I've constructed it with two interactive servo motors with tires, an accelerometer (above the right tire from the camera), the NXT, and a LED lamp as a generic indicator (above the left tire from the camera).

A brief description on the accelerometer from the HiTechnic product page.

Now you can make robots that know which way is up! The HiTechnic Accelerometer / Tilt Sensor measures acceleration in three axes. It also measures tilt along each axis. Using the sensor, you can measure the acceleration of your robot build robots in the range –2g to + 2g. Great for experimenting with acceleration forces in cars, on amusement rides, even on swing sets. This sensor will also tell you if your robot is level so you can build self-leveling robots and much more.

Sounds exactly like what I need! The definition of the three axes are pictured. Notice that the accelerometer has been mounted as low on the unit as possible and with the x-axis is positive in the forward direction, and is level with respect to the rest of the unit. This will greatly reduce the amount of error due to structural weaknesses in the platform.