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.

...And the First Problem

Well then.

Just as I'm gearing up for this project, my computer bites it. Hard. While booting the computer it hangs during POST on the video hardware. Hangs! How does POST hang?

Well, this is an Asus A8N-SLI Deluxe. Notice the nForce4 SLI controller just to the right of the RAM slots? It overheated from a faulty fan and damaged some surrounding components in close proximity.

Well, I guess this is a reasonable excuse to by some new parts... i7-920 Quad-core, here I come! :)

newegg.com package tracking says I should have the parts by the middle of next week.

Delivery

My Mindstorms kit was delivered today!

I took some time to build the demo unit that comes with the instructions with little trouble. The demo unit doesn't have a lot on it: two motors with tank treads and a third motor not connected to anything. No sensors are included in the directions. This platform is really meant to be expanded upon with new ideas for basic experimentation, but what I've got in mind isn't going to make much use of what's there. A new platform will have to be built.

The NXT allows you to enter basic programs via an interface in the unit itself. I have been able to write small programs that allow the unit to move around and avoid obstacles using this interface. Here the platform is pictured with a sonic range finder off of the front. My computer has been acting odd lately so I haven't been able to write any mature code. I look forward to having my computer working again so I can do some real programming with this.

One thing that is going to become troublesome, however, is the massive amount of unorganised pieces. When I was investigating the kit online, it seemed as if it came with a case to store and organise the parts. Instead, there are many small bags that tear easily. I'll either have to order a case from LEGO or use a tackle box or something.

First Day

There's a project coming up in ECSE 4440: Control Systems in which we will have to create a controller for a specific system. This sounds ok, but I'd like to take a different approach. Instead of controlling a given system, I'd like to design a simple system myself and try controlling it. I find that the more tangible that an experience is, the more I learn and the easier it is to retain and recall. And since the material in this class forms the basis for most other classes in my curriculum, the more I retain the better!

I would like to build a self balancing robot, something similar to a Segway. This is a permutation of the classic cart and pendulum system. This type of system consists of a wheeled base connected to a mass by a rigid rod that has a joint at the base. This is an excellent system to build since it is simple and easy to model. We've also gone through many exercises in class dealing with this system keeping it fresh in my mind.

To build the platform, I'd like to use LEGO Mindstorms as a rapid prototyping platform. Mindstorms provides a quick and stable solution. Building a frame from other materials such as wood or metal and using a microcontroller are all possible, but would take time. It is out of the scope of the project to do this. The LEGO Mindstorms kit has been around since the late 1990s  and has been through three generational upgrades, each adding new features, sensors, and communication options. (Wikipedia) Universities recognise Mindstorms as an option as Tufts, Carnegie Mellon, and MIT have all created some projects using Mindstorms. (LEGO)

I plan to construct the test platform using the Mindstorms NXT 2.0 kit (#8547). The platform will consist of two interactive servos motors with tire attachments, the NXT control unit, an accelerometer, and interconnecting LEGOs. The servos with tires will be at the base of the unit "shoulder" width apart. These will be connected and attached to the NXT such that the weight will be evenly distributed across each servo. The nxt will in turn connect and attach to the acceleromoter above the NXT.

I may or may not have put the order in already... :)