I recently ran across this short (13:15) video tutorial describing the process and math of figuring out your position and orientation from an IMU. It was a quick overview at just the right level of detail to connect a lot of the different concepts that I have been thinking about for the rover project.
For the rover, simply getting orientation information out of an AHRS algorithm isn't going to be enough. I also need acceleration values (in the inertial frame) with gravity subtracted out, to be able to plug into the Kalman filter. In essence, since the rover doesn't have wheel encoders, I'm using the IMU's acceleration to help do dead reckoning.
If you put that video together with an AHRS algorithm like Madgwick or Mahoney, and then take a look at the coordinate transformation sections in the rather famous book "The Global Positioning System & Inertial Navigation," you'll get a pretty good overview of how my robot will know where it is and where it's pointing.
I have this SparkFun GP-20U7 GPS Receiver. It seems to work pretty well. I'm changing around my approach to the autonomous robot, and now I need access to the PPS (Pulse-Per-Second) functionality of the unit. The PPS pad isn't broken out on this device - it's under a pile of red goop you have to scrape off, and is actually part of an unpopulated LED circuit. It's not immediately clear (to me, anyway) how to wire it up to a microcontroller to get the PPS signal.
I've referenced this blog post, which noted that "PPS is open-drain so a pull-up is required. If the LED is installed it is the pull-up."
I think that means the following hastily-drawn diagram applies:
At any rate, I was able to verify that the correct solder pad does some kind of pulse every second (when the device has a fix) with my worlds-cheapest-ebay-kit-oscilloscope. I don't really want to populate the LED/resistors (I don't have the SMD parts), but I believe I can just connect that "left" solder pad to a microcontroller input with an internal pull-up resistor and set an interrupt and be good to go. I'm leaving this blog here for reference since there isn't much about this device online for electronics newbies like me.
(Side note: PPS only pulses when the GPS has a good fix. This makes sense in retrospect, but it's a pain if you have to haul your junk to an open window on the second floor, for example, just to figure out which pad to use. Hypothetically, that is.)
A very after-the-fact robot update from late 2016: GPS works. This is perhaps more awesome than it sounds.
First, if you want a good rant about how GPS communication is terrible, check out this article. It's a magnificent rant about how you never really get your true state or know what time a particular state refers to with GPS, due to a pretty nonstandard standard (NMEA), which itself was due to the "N" in "NMEA" standing for "Nautical." Boats just don't need the same data as the rest of us, it turns out.
Other fine folks have attempted to solve this problem, and one approach is a GPS/NMEA processing daemon for Linux called GPSD. This monitors the serial communication, processes it to standardize vendor differences and sentence-order differences, and then makes it all available via UDP. Very cool, you can poll this when you want it. If you want to be notified as soon as new data comes in, I think you may still be out of luck, however. I'm anticipating my GPS error range will be more than my timing error range, so it should not matter too much. In my robot, GPS is not designed to be a precision sensor (yet).
But GPS isn't just terrible, it's also awesome. I have code that runs on my robot pi to listen to the GPS, and convert that lat/lng info into a local x/y plane, and then run a Kalman filter on it, and push each successive state out to the telemetry web application (also served by the robot) over a Redis backplane. Eventually this will host a maps view of the current estimated position, error ranges, etc.
Next steps are to read from the Inertial Measurement Unit (IMU) and do sensor fusion to integrate that with the GPS data (in progress), which has its own set of fun challenges. Stay tuned.
My autonomous robot project will be based around an old toy Radioshack RC car I had as a kid. This thing was pretty good, however. It had an adjustable (proportional) throttle and steering, instead of the cheaper and more-common "all or nothing" approach. The motor looked pretty beefy and I had an RC battery and charger for it, so I thought things would be pretty smooth sailing.
The battery was old and needed to be replaced. No problem, Amazon to the rescue.
The RC control circuit board is too confusing for me to re-use any of it. Oh well, no big deal, I'll get a motor driver board.
The steering servo has 6 wires. Modern servos have 3 wires - Vcc, Ground, and a PWM signal for the rotation target. The 6-wire version is apparently an old-style "brainless" servo, so you have to handle the control and feedback (via potentiometer) yourself. Oh, and did I mention it's not a standard size? And that the rather nice, intricate steering mechanics that attach to it won't mount to a standard servo without modification? Well, that's true.
There are two different ways to solve this problem, and I think which one you choose is indicative of what kind of engineer you are (or should be). You can modify the hardware and mechanical linkage and just swap in a new, modern servo, or you can take the old servo apart, figure out the wiring, put it back together, cut the wires, cannibalize a modern servo for the control circuitry, and (assuming the motor requirements and potentiometer resistance are the same) wire the old servo up to the new circuit. The mechanical engineer modifies the hardware and puts a new servo it, while the electrical engineer keeps the mechanics the same but swaps out the electronics. While it does seem like more work, I went with the EE solution, because I am definitely NOT a mechanical engineer.
Now I just need to pick out a compatible motor driver. But what are my motor requirements? I don't know - it's not like it has a datasheet or part number. To find out, I cut one of the wires running to the motor and measured the current on my multimeter. It is important to measure the current under load, and at a stall, as well as looking for any spikes in current (I think). Under no load, my motor pulls about 1 amp, but under normal driving, I expect around 3 amps, and under a stall, it pulls about 7 amps. So I think that means I need a very beefy motor driver. This may not save me all that much money in the long run.
And that's as far as I got tonight. I'll post more about the overall goals and project plan in a few days... Oh, I guess I did learn one more thing:
I really need to clean my desk.