UGV work

Another kind of cool development is that we were asked to see if we could make a unmanned ground vehicle,UGV, with the same brains as we use in the UAVs. That combined with our ripe fruit turret idea gave me a bunch of new ideas about how to separate the hardware from the software stacks. The turret will use some interesting ideas on color detection and correction to detect whether fruit is ripe enough to be picked.

Now there is a UGV in the mix. What better a system to tow the turret around, than a 1/5th scale 4WD buggy. It is also leading us onto a bunch of other applications with the same device. Our new ideas, we hope are very investment worthy. If President O actually does something for small business, then we may be able to attract some investment. I think that there are several interesting campus or property management applications that will make the software easy enough to develop and/or repurpose.

Hopefully, I will get some more pictures of our electric conversion of the buggy and some assembly stuff. So that everyone can get an idea of how to do the electric conversion and the other steps that we took setting things up. We have some math that we have already worked out to hopefully help reduce some of the initial setup mistakes. Many scientific papers all say that small alignment errors in setup can ruin the mathematical assumptions that are made in software. That is why we keep trying to set up our software and then back out the math. Not always a working approach, but it is better than thinking everything is perfect.

Neah, engineers are never perfect... we are within 20%, 80% of the time.

Before we get to actual code...

Before we hop off into any actual implementation, I would suggest that we sit and think about some basics. The very first thing that should be done is to come up with a basic skeleton of the code that you would like to write. This may impact many decisions down the line. Basically, a UGV and a UAS/UAV are the same from the code's perspective. The UAV/UAS use different actual algorithms for certain processes, but the data flow and data collected are not so different. Some data is read, a decision is made, a servo solution is calculated, servos are moved into position and then the system loops again.

One thing that I did, was to develop an object that was a sensor, ISensor. This will be the part that actually interact with any device. ISensorReading will also act as a fundamental contract for data. I would make sure that this object follows in general an observable pattern. That way it is easy to allow other objects to read its data, or to be notified when new data is available. This will make it easy for filtering algorithms to execute and work on the newest data as soon as it arrives. It will also make it easier to make the data collection to be asynchronously collected and processed.

Then I made an instrumentation manager, IM. The IM will have factories for each kind of sensor and observe instances of each of the instruments. This way if something happens the IM can close an instrument and try to reconnect with a new object. In turn, the IM presents data to other parts of the code as needed. No other parts of the code need to see the sensors or interact with them directly.

On top of the instrumentation system, should be a director layer. This will actually be the layer that does all of the work. It makes a nice break line between the device and the presentation, or intelligence. Separating the systems is an important object-oriented technique that is necessary for keeping the code healthy.

More about the director later... I will see if I can get some pictures in to make it easier to see.

Basic Quantities and Some Trigonometry

So You Want to Build a DIY Autopilot

Accelerations

One of the most important quantities for you to measure are accelerations. If your two or more-axis accelerometer is mounted along the traditional axes of the aircraft it will be the easiest to code for. The three traditional axes are:

• From the nose through the center of gravity on the line of symmetry, the Y-axis, roll
• From the center of gravity out of the fuselage toward the tip of the right wing, the X-axis, pitch
• From the center of gravity away from the earth, the Z-axis, yaw
  
     

Figure of Rigid Aircraft Axes

So, now for some basic Trigonometry, everyone remembers SOH CAH TOA.

In general, the following picture is true for a vehicle moving through space.

Figure of the Direction of the Force of Gravitation on a Body

As you can see from the image, the angle of pitch relative to the surface of the earth is the same angle offset of the weight vector relative to the z-axis in the body frame of reference. If we put our accelerometer so that one of its axes is parallel to the body's z-axis at its center of gravity we are measuring this offset vector. Which is really neat, because it means that we can express the angle of the body in level, non-accelerating motion as ratios of the accelerations

Pitch: 

The angle theta between the actual gravity vector and the measured gravity is related to the pitch of the aircraft (pitch = theta + 90°). If we know theta, we know our pitch! Since we know the magnitude of the earth’s gravity, simple calculus gives us our pitch angle:

accelerometer = cos (theta) * gravity

theta = acos (accelerometer / gravity)

And since pitch = theta + 90°

pitch = asin (accelerometer / gravity)

Woot, we calculated the pitch orientation of our airplane using an accelerometer. Pretty easy, huh?

The real formula that we need to use for the software looks like this:

pitch = atan2(accelerometer / gravity, z / gravity)

Common piezo-electric accelerometers return in units of, g, 32.17 ft/s^2 or 9.81 m/s^2. We also know some more things about the flight that let us calculate the angles relative to the ground. More on this later, it is a bit more than basic trigonometry to describe. These equations assume non-accelerating flight. You can use a magnetometer to get the relative plane in space with less math, but magnetometers generally take more interface programming in my experience.

Roll:

Roll needs a second accelerometer with an axis perpendicular to the first so that we can figure out the resultant vector between them and then the angle. Essentially the vector between the accelerometers becomes the "gravitational" acceleration and the relative readings lets us calculate the angle with an atan2 function. The second accelerometer will have some other things to manage such as the effects of the distance between them on the accelerations measured. Physics fun and none of the boring class.

Yaw:

Yaw is the hardest of the angles to measure. The only answer is to use a magnetometer or a compass. In many ways, yaw can be solved by dead reckoning. Dead reckoning is all that is important for most of the projects in the DIY garage. They will be covered later.

Next we will discuss gyroscopes and the beauty of rates and integral calculus