Tuesday, April 3, 2012

AVC: Initial Data Logging

Data Bus prepares for a nighttime logging mission
After all these many months Data Bus finally logged some real world data! What excitement! Two weeks away from the big demo! Eek!

Why'd I wait so long to run the robot in the real world? I wanted to take my time understanding the problem better than I did last time so I would be, hopefully, less surprised by the results and closer to a working solution.

Here are the results of three separate runs, driving the robot around slowly outside the house AND two runs at Sparkfun!

GPS
Data Bus is now running the new Venus6 GPS with a patch antenna on the roof on top of a ground plane. I drove the Bus along the curbs of the street for a reference point. The plot is relatively accurate in shape to the path I took. It's a bit offset. The GPS had a very good fix when I started.


I was picking up something from one of my fellow roboticists and found myself a stone's throw from Sparkfun so I figured why not give it a go. Here's a plot of two runs. The red plot I'll explain in a sec but the green plot is the one driving around the building.


Overall it looks surprisingly good. The worst inaccuracy is on the west side, the "urban canyon". The robot actually followed a fairly straight path relatively close to the curb. The east side path is relatively straight but seems shifted west a few feet from reality.

Gyro
Here's the gyro plot from driving around in figure eights outside the house. I think this looks good. Not a lot of noise. Seems like plausible output.


The plot below is from integrating the raw output from another run, driving a rectangular pattern in the street. I didn't scale the gyro raw data to degrees per second, so the integrated raw gyro data is only proportional to heading.


The shape looks plausible, at least. Starting out in one direction, going across the street, then slowly turning right, then driving straight for awhile down the street, driving right again coming back across the street, then turning back and driving straight back up the street to the start.

I'll have to scale the data to deg/sec then compare to the GPS heading. Also, it looks like there's a little bit of drift. Won't know until I analyze further. I also need to calibrate the gyros. I've been putting that off.

Magnetometer
I ran the raw 2D magnetometer values through a solver to find the best scale and offset values. Then I plotted the corrected X and Y values from the magnetometer. The following looks sort of like a circle, but a bit on the noisy side. Except...


...look at the lower right corner. Doesn't it look like two separate lines? Uh oh.

Another thing to look at is magnitude across various headings. If offset and scale calibration are correct, then the magnitude of the magnetic vector should be uniform at all headings. That is, plotting magnitude of the magnetic vector versus X (or Y) should  resemble a straight, albeit noisy, line.


The plots I got seemed to have around 10 degrees of noise, much more than I expected. Too noisy to make out any line at all.

Maybe the street tilt plus body lean is playing in here? At Sparkfun, I drove the vehicle slowly in large clockwise and counter-clockwise circles to eliminate tilt as the source of error and to try and isolate the cause of any noise. That's the red track plot above and below.


Here's the plot of the 2d magnetometer X-Y plot after going through the solver.


It looks kind of messy. What is going on here? It almost looks like there's different circles appearing.

Perhaps current is playing in. I plotted magnitude error versus  current and came up with this amorphous blob. Suggesting that current isn't related to magnitude error.


What if I plot magnitude error versus position? Could the magnetic field differ from one area to the next? I plotted error magnitude versus latitude and longitude. Though it's hard to make out in a 2d representation, here, when you move the plot around interactively, it seems clear that error is related to position.


Since I was driving in a circle, position and heading are related. So is error just related to heading? Could be. Here's a plot of GPS heading and magnitude error. Your thoughts?

The final verification would come from driving the vehicle around in random directions and mapping out the magnetic field vector magnitude at each position. More importantly, will continuous compass calibration help improve heading accuracy, or should I ditch the compass entirely?

Encoders
Here's a plot of speed computed from the encoders. I'm running the computation at 50Hz. The scale error is due to one plot in mph and the other in m/s. Even correcting for that the encoder and gps speed differ by  more than 10%. Time to recheck the odometer calibration.


More obvious is the wicked encoder quantization error. The high update rate and low speed are at fault. I will try updating speed calculations less often and see if that doesn't improve resolution a bit.

I may try dithering and filtering. I'm curious to see how that will work in real life. But really distance is the key for position estimation. Encoders measure that directly. I'll look at that separately.

Also of interest is that the GPS data lags the encoder data by about 1 second. I saw this last year with the SiRF III chip. I wonder if loading the high dynamics version of the firmware will reduce the lag.

Conclusion
Well, in contrast to last time, I actually feel better having logged, plotted, and analyzed data. Sure, there are problems but they seem familiar and understandable, and I'm pretty sure I can make improvements.

There's more analysis to do, position estimation and heading code to prototype then implement on the robot, and a slew of other things in the next two weeks.

For once, though, I feel like maybe, just maybe, I can pull this off.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.