If you were an UGV, what kind of truck would you be?

This week I have been digging into the 2d plane again. Yeah, that sounds kind of odd, but I think it is pretty accurate. I am looking for a platform that will let me test my own avionics and code in a way that will not have $10k at 300' and then in a heartbeat have it smashed into dust . The ground does rush up pretty quickly at the wrong times.

One of my colleagues at my real job has egged me on, so I have been evaluating what it takes to get my software to work in a constant altitude kind of setup. Ok for all non-geeks, it means on a truck. I think that the premise has been tossed around several times.

I found that several things during this evaluation. One, electric 1/5th scale trucks are not common. There are lots of 25cc gasser trucks. The three that I was reviewing were:

HPI Baha 5T






NuTech Mega Monster






Redcat Racing







After reading a bunch of information about all of these chassis, and 10's or 100's of reviews and projects. I even found 1 from Sony on the HPI... The Nutech seems to be ahead in the research. It does not weigh as much as the Redcat. The Nutech is Chinese, try not to just mail money to them these days. The HPI has great reviews but is significantly more expensive. I have not found anything to say that one is better than the others. So it may come down to weight and cost.

I will not be using the 23-26cc engine. It will be replaced with some pretty beefy NEU motors and a lot of LiPo. My Mini9 will probably be its brain for the foreseeable future. I do need to work on a COM to handle the code.

Kind of cool to watch the movies of these guys flipping around. I know mine won't do it, but will get its fair share of curb crashing I am sure.

Ok, I guess it should not bother me

I have been researching the Android 2 as a robotics platform. Several people have weighed in to say that the only big advantage of Google's Android 2 is that it is essentially free to distribute. However, it has other overhead that has to be overcome. It has to be recompiled per processor, so there is more to sourcing cpus and instruments for it.

I did find in my rolodex that Toradex has a Limestone PDA kit that claims to boot Android 1.6. I have to keep looking. One of my mad scientist ideas is the multiple chips flying closely together to distribute computing projects into manageable chunks. I will keep looking for more. I am not an EE so it is important these solutions be mostly plug and play.

The only "robot" stuff, that I have found before are canned apps from canned boards. I guess I was thinking robot not rc kit. Yeah, I use a lot of rc stuff, but I am not looking to directly control the devices at every turn. They should have increasing levels of autonomy. However, I do have to say that I like that some companies have the same idea that I do. The kit I have found that has the most coverage is the Surveyor SRV-1. It looks interesting enough, but PIC sucks. ;) An interesting couple of "rc toys" on Android movies can be found at robots.net.

Android 2 or windows 7

I saw this and liked it. If anyone has any real reason to choose one over the other without the opensource vs. proprietary hate. I would be interested in hearing it. The thrust is for robotics and control systems, not multi-media or similar applications.

UGV autopilot

Taking the lessons learned from the UAV stuff, I am trying to trim down the UAV pilot to a UGV pilot. The two have different requirements so I am hoping that it can all be put into the mission planner. I have found playing with the UAV autopilot that the event driven solution works well, but is a bit honery.

So I am working on a bus model. Where the individual managers all call into the bus to pass messages, then the bus manages the message delivery. This should decouple the messaging. I was trying to avoid the inevitable hard coding of observers and subjects in the code. This would make the relationships less fixed and hopefully ini-file-able.

I have some other lessons learned about this.

One other question, does anyone have any opinion of Java on Android 2 rather than c#.NET on Windows 7? They would both target netbooks or computer on modules (COM). Let me know if anyone has any practical/constructive opinions of these platforms. info "at" fatmanflying.com

Stereographic Vision

I have been messing with the AForge library now for a week. It is the best known and rated .net image processing library. Everyone has tried CV and getting the interop wrappers to work is tough. I have given up several times myself trying to just get all of the constants wrapped.

I have been working on a version of their two camera tracking system. My cameras are a bit lager pixel counts than his, and I think that is where some of my timing issues are coming from. I think that the other piece that is beating me at the moment is the revisualization part of it. I think my composited movie needs to be output through the player control or just written to disk. I will have to monkey around with it. It may turn out that the movie meeds to go 360p or something to this effect and increase the frame rate.

I am pretty sure that it is not a processing power thing, more about crappy code on my part. If the frames are smaller, my inefficient algorithms will probably be less impacted. I may also have some other ideas on how to composite the video, frame-wise may also be a bit on the slow side. Let's go for snappy. I have enough to do what the original project was intended for. It can track an object in the scene. Now, I need to get it up so that I can pick which object to track.

Will keep everyone posted.

The Girls Love the Long Ball, But the Boys Love the Spin

Someone once told me that it is not the boom, it is all about the shock wave. I guess that is true, you need to feel the motion of the ocean.

You ask, what does this have to do with gyros? Well, if you cannot figure out how fast it is twisting, there is no way to know how far your ball will go. Yeah, actually a lot, since driving a golf ball is not a momentum problem alone. The dimples hold the boundary layer on and make it go much farther.

Gyroscopes are cool, I have the neat little 300 deg/s board from SparkFun, built on a 3DOF IMU. I soldered on some pins so that it is easier to connect to. Connected the ground to the system ground and connected each of the signal pins to a separate "connector". Really, easy and I am a bit electrically declined.

I then set up an easy pseudo code system to watch the ISensor.DataUpdated method. That lets me see the phidgets.datachanged event in my little API. The delegate that I use for ISensor.DataUpdated feeds my smoothing algorithm. I use the smoothing algorithm to keep out shorts and wonky voltage changes that happen. This would feed the Kalmann filter which I still do not have.

I then feed these data updated events into an ArrayList and do my Runge-Kutta routines on them to integrate the unknown functions. This running integration is how I get an approximation of the position of the gyro. Remember gyros return the rate of change of the gyration, an angular velocity so to speak.

We can do a simple integration to get back to a position.

xi = xdot*dt+xi-1

for constant timestep dt and the previous position, xi-1.

I will put some code together for the next post on this.

How I started writing a DIY Autopilot

My intention still is to write my own c# based autopilot. It is not trivial as I found out. Lots and lots of details are needed. The first thing that needs to be done is to determine the instruments that you will need to measure the quantities that you need to know to control flight. Even this seems to be a matter of opinion. For a reference, I found every group that I could that was writing their own version.

From my perspective the quantities that we need to know to control flight are:

• air speed, ft/s or m/s
• altitude, ft or m
• orientation, roll, but pitch is good

These are intrinsic quantities that are really easy to do yourself. Air speed is the model's forward velocity. Altitude is the vehicle's position relative to the surface of the earth. Pitch and roll are the angles of the vehicle relative to the ground. Let me rephrase that, roll is the angle between the right wing and a plane parallel to the ground. Pitch is also known as angle of attack. Pitch is the angle between the plane at the center of the vehicle located on vectors from the center of gravity to the right wing tip and the center of gravity to the tip of the nose and the relative wind.

At the beginning you will need to measure the following quantities:

• air pressure
• acceleration in at least two directions
  

Pressure taps are the easiest ways to measure air pressure in a flying vehicle. Piezo-electric accelerometers are cheap these days and are really accurate. In the next post we will talk about issues with these instruments and the physical quantities that you are actually measuring and how to use those as a basis for a control system.

For all of those inch haters, a quick note about units. You can do this in any unit system. It is unimportant. I will write a quick post on the conversions between the US Customary System and the metric (mks) system. Remember metric is actually several unit systems in one and you have to keep them consistent. Oh, and for those trying to buy nuts and bolts, Japanese manufacturers use odd metric sizes, European use even metric sizes, and the US Customary System/SAE is in units of 1/64th of an inch. So SAE/SAME will have three bolt sizes for every bolt size in the two metric systems. Remember that the thread counts are different though.

In my opinion, if the units are managed consistently then the issue is one of presentation to the user. Part of the display system of my code will show you how to do this with a simple object oriented approach.