Another Session!

Woot! Two nights in a row! Still not a lot of progress though. This SPI bus sharing is a little dicier than I thought. Of course I'm making it hard on my self, as usual. I want the bus to multiplex. I want the bus the be able to read data in from one device after I've commanded a second device to gather data and am waiting for it to get the result and pop its READY line. Its a bit tricky keeping track of when the bus is available and when its not. I know that my logic right now is pretty busted. It so busted that I got disgusted and put off fixing it for another night.

I'll come back at it soon and straighten it out.

RoboMagellan Progress (Inchworm style)

Well I spent a few hours working on the RoboMagellan bot tonight. I didn't get much accomplished really. Much of it was setting up a work environment here in my computer room.. one of two air conditioned rooms in the house. Man it was hot today.

I modified my SPI bus. I put 180 resistors in series with the 3-axis compass. To my delight I found that the circuit still worked AND I didn't have to remove the MCU to drop a new program in. Flushed with success I went to add the accelerometer MCU to the SPI bus as well. Of course there was a problem: all my remaining Mega32's were non-responsive. I had messed up the fuse bits some way or another.

I got KJohn's STK500 up and running and recovered two previously toasted chips via high-voltage parallel programming. This was my second try at this and I was most pleased to succeed.

I added the new MCU behind another set of resistors and tried to program it live. Initially I couldn't. So I raised my resistors up to a few thousand and live programming worked. Then I realized that the other MCU was powered down. Trying again with both MCUs powered up I found the programming cycle got stuck real early in the cycle: during the initial read. Usually I get some error msg form AVR Studio, but in this configuration it just hangs.

I don't have a solution but its not a huge deal since I am using Eddy's Mega32 board and each has an independent power supply. Its a snap to just yank the battery cable on one of them. Still it would be really nice to figure out a circuit that would let me program with both live and both on the SPI bus. I'll just live with for now.

Next session I want to see if I can get some data out of the Accelerometer MCU. Should be interesting going back and forth between two bodies of code to try to get them to talk to one another!

Tilt Compensated Compass

So, as I posted earlier that the magnetic field here in Wisconsin is mostly straight down into the ground. Normal procedure with a 3-axis magnetometer seems to be: use a multi-axis accelerometer to get the pitch and roll angles of the compass, correct the detected 3D vector, then toss out the Z-component and compute the angle difference between the projected sensed vector and the front of the sensor. However, since most of the field is down, the projection seems to me like it tosses out a bunch of resolution. I'm going to try to write down what I think might be an alternative technique that won't trash the resolution by avoiding a projection operation. (Or at least waiting to project until most of the magnitude is not in the direction of projection).

I first want to define the heading plane in 3D space. This plane is normal to gravity and due north is right along its axis. (X or Y. Doesn't matter.) When the robot/compass is heading due north the sensed magnetic vector points sharply down from the plane, northwards and just a touch west. I'll call this magnetic north. Magnetic North's direction is related to due north's by a pitch angle and yaw angle. If you remove the pitch and then the yaw from magnetic north you then have a vector that is in the direction of due north in the heading plane. Let's remember these rotation operations as unpitch magnetic north and unyaw magnetic north.

In general, when the robot is out and about it is pitched and rolled verses the gravity vector and it is yawed versus the magnetic north vector. The idea here is to rotate the sensed magnetic vector into the heading plane where a meaningful angle calculation can occur between the rotated vector and the due north vector. So if we take our sensed vector and unroll the roll detected by the accelerometer, unpitch the pitch detected by the accelerometer, then unpitch magnetic north and finally unyaw magnetic north the resulting vector ought to be in the heading plane and a simple trig operation can be performed to get the robot heading.

In practice it the result won't be in the plane, but it will be close enough to not worry about the Z-component. One reason it won't be quite in the is that getting the exact value of magnetic north is not all that easy. For the time being I will probably use the USGS predicted magnetic north.

Anyway, this was my effort to type up my thinking on this whole 3-axis tilt compensated digital compass thing. Hopefully it makes sense. Hopefully I can make it work in code.

RoboGames 2006

Readers 'n' stuff. Weird. I didn't want to post about RoboGames a couple of posts ago simply because I wanted to talk about the magnetometer. I forgot to come back and post about the games. I'll try to make up for it now:

So in June I went to San Francisco to play in the RoboGames. I brought Felix, my new RoboNova and Uno, the vernerable old mini-sumo. As you can see above Felix won 2nd place in the Robo-One Demonstration contest! (Uno got his ass kicked.. he is now retired.) Matt Bauer was kind enough to make a video of Felix's performance. Thanks Matt!

Anyway, RoboGames was quite interesting. Boy howdy its a big event. I'll bet there were 200 or 300 people in the building at once at some points. Anyway, I had never seen combat robots (RC) in person. They are actually quite something to watch. They make one hell of a racket and the noise really pulls on your rubber necker strings. You feel what the spectators in Rome must have felt at the coliseum.

Nonetheless, the most fascinating contests, the ones that I still think about after the contest is over, were the autonomous navigation contests: RoboMagellan and Trinity FireFighting. The whole magnetometer thing below is all about RoboMagellan. I had never actually seen a Fire Fighting Contest. I had heard about them, but they didn't register as being very cool to me. Once I actually saw one and saw that it was really all about indoor robot localization, I became pretty interested. It would be a great opportunity to implement the 2-D-webcam-laser-range-finder concept that I saw at the SRS website and have been itching to do ever since.

The other majorly cool thing about RoboGames were the winner awards. Rather than give prizes as we have done in ChiBots, RoboGames gives electronic medals like the one you see pictured above. I LOVE MY MEDAL! I like it better than any prize I have ever won. At this month's ChiBots meeting I asked the members if they would like to drop prizes and switch over to something like the RoboGames medals. They heartily agreed! So, now we are in the process of designing an electronic medal that is specific to ChiBots. Compared to the Combots logo, our logo is pretty expensive to make so we'll just have to wait and see what it finally looks like, but I'm excited about it!

Anyway, overall I had a blast at RoboGames 2006! There is a pretty good chance I will return next year.

High Latitude Fun

So I looked some more at the data the magnetometer was giving me. For a while I thought that the X, Y and Z axis might not be aligned the way I thought they were or in the most logical way. The reason I thought that was that the Z-axis was registering some 4 times higher than X or Y. I knew it wasn't a calibration issue because I could re-orient the device that the large reading would move. I figured the large reading HAD to be due north. NOPE! The larger reading on Z was exactly what it said it was: a big magnetic field straight DOWN. WTF, I thought? Localized field? I took the device outside and there was no change.

Finally, after some looking I happened upon the USGS National geomagnetic Program website. They actually have models of the Earth's magnetic field. There is this applet that lets you select a model (they update every five years) a latitude and longitude and the current time. It then dumps out the predicted X, Y, and Z field strengths. Sure enough, the predicted value in Z was 52000 nT down and only 18ooo nT north. I had no idea the Earth's magnetic field tilted so early.

Its good to have confirmation of my readings. It was kind of a eureka moment when I ran that modeling applet. However, after that died down I realized that it kinda sucks a little in that much of the field strength is in a direction I can't use for navigation. Wait. Or is it? Hmmm. Thinking in a post is probably not good. However, just this moment it occurs to me that on the basis of the model I know which direction the Earth magnetic vector is suppose to point. That vector has a simple relationship (two rotation operations) with the "North" direction. That should fact should be usable and allow me to maintain my measurement resolution. I'm having trouble coughing up a sentence that expresses my thinking so I'll stop trying and post it later.

One Day I'll Be a Real hobbyist

Did some more work at long last. (Oh yeah, went to RoboGames 2006, got 2nd place in Robo-One demonstration but I'm not gonna talk about it). Anyway, I can now talk to my stupid 3-axis magnetometer over the SPI bus. The AVRLib doesn't seem to work so great. I keep dropping back to the examples in the Atmel docs, which work great. The data itself is a bit confusing, but I think that is because the axes may not be align the way I think they should be. I think the x-axis is vertical on the PCB board. Its hard to be sure by using a magnet because the field is so misshapen that it could actually be going a different direction from one sensor to the next. I'll have to figure out how to do a good job testing that.