jBot's IMU Odometry

An expanded HTML version of jBot's IMU Odometry paper is now available online at:
<http://geology.heroy.smu.edu/~dpa-www/robo/Encoder/imu_odo/>
which includes images, software, and videos of the robot in action. Many thanks to the folks who took the time to read the original rough draft and gave me feedback on errors, typos, and ways to improve the paper.
best regards, dpa
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"dpa"

I've been watching jBot for a while, mainly because I'm also developing an R/C based AGV. I enjoy the videos the most. Great work!
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Padu,
thanks.
I'm having some trouble with the HTML rendering for IE browsers, so for a temporary workaround for IE users there is a Windows friendly version of the article at:
<http://geology.heroy.smu.edu/~dpa-www/robo/Encoder/imu_odo/index_IE.htm>
Hope to have this straightened out soon. Any other feedback welcome.
What sort of vehicle are you working on?
best, dpa
Padu wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"dpa"

I'm working on an autonomous rover based on the e-maxx. I'm just about to start creating my own IMU, so I will digest your page with more time later.
By the way, at least with IE7, both links look exactly the same.
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Cool! E-MAXX parts are excellent and seem just made for robot builders. Also they seem to be pretty readily available. jBot started it's life as a wrecked E-MAXX.
Good luck with your IMU project. Do you think you might do a writeup?
I believe the IE problem is now fixed, I learned something today about HTML formatting.
best, dpa
Padu wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"dpa"

Thanks!
I have to confess that I was never a huge fan of statistics, but two events contributed to steer me to a statistical approach dealing with robotics (especially IMU). One is one class I took last semester on speech and speaker recognition. I believe things like the EM algorithm or GMMs/HMMs can help in robotics too. And the second was the victory of Stanford University on the DARPA GC. Sebastian Thrun (the team leader) highly believe on the statistical approach for robotics. I got his latest book and I'll try to apply some concepts from the book into my IMU. Because the project is for my master's thesis, I'll have to write anyway, so it is very probable that I'll write a web version of it.
Cheers
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

events
can
University
my
I'll
You will have a lot of people asking for your paper!!!
Wayne

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
dpa wrote:

Hi David, I am also working on a GPS plus object avoidance 4 wheeled drive robot. I bought the 4WD3 base unit from Lynxmotion. I added a scorpion motor controller and a 28pin Basic Atom Pro for my micro. I have got the GPS nav part pretty much nailed, but only to one waypoint at a time. I still have yet to figure out how to navigate a route with more than one waypoint. The NMEA seems to only spit out the bearing to the last waypoint in the chain of waypoints so my robot always heads straight for it, by-passing the rest of the route. My GPS unit is a Garmin legend and using the course and bearing info from GPRMC and GPRMB NMEA sentences I can calculate and alter course towards the waypoint. The basic Atom can't do the math needed to calculate bearing and distance from the Lat and Long of two points, so I rely on course and bearing to waypoint info from the above NMEA output to navigate. I though of using a 2 data transceivers so the robot could send me it's Lat & Long... to a small pocket computer (Psion 5mx). The Psion could do the math required and send back to the robot course and distance from any second Lat and Long point. Obstacle avoidance... I'm just at the beginning of. First I was using two IR detectors to turn if an object got in the way. This was ok, but crude and IR is unreliable in bright sunlight. I got a lot of false triggers. Now after reading up a bit on your web page, I think I may use a "ping" sensor on a rotating servo. My idea is when the robot detects an object in it's path, it will stop, look around (or more precisely ping around) and look for the most open path before it proceeds. When it drives far enough (which can be adjusted) forward, it will again turn towards the waypoint. If it encounters the object (new or the same one), it will repeat the ping function. I would consider this the core of the nav routines... more sophistocation can be added later as I learn.
Please be kind with comments, one must consider, I am self taught with not official education in electronics... I have only a meager BA in business (-: Electronics has been and continues to be just a hobby since childhood.
Thanks for your inspirational web site and projects.
Richard
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Richard,
Sounds like a neat project. I just now looked up the 4WD3 base and it looks like and excellent place to begin. I don;t know much about the Basic Atom, but you might be right about the need for more processing horsepower.
However, might as well ring out what you have before jumping to another hardware/software environment.
For the waypoint navigation problems, jBot actually transforms GPS coordinates into it's own local reference frame, so it only uses the NMEA GPMRC data to compare its calculated position to the measured one, and does its own waypoint navigation.
I know that Garmin has its own proprietary binary interface in addition to the NMEA strings, and I bet that is how you tell it which waypoint to seek, just like you can do from the user interface. Now, how to find that out? I gathered up a bunch of links on the Garmin interface a couple of years ago, maybe some of these have some idea of how to tell the device which waypoint to seek:
This one is called "gamin-utils" www.openbsd.org/3.9_packages/mips64/garmin-utils-2.2.tgz-long.html
This one says "A program to communicate with Garmin GPS recievers" linux.maruhn.com/sec/gd2.html
This one is called "A python Interface to Garmin GPS Equipment" pygarmin.sourceforge.net/packages.php
Don't know if any of that is useful, but maybe a good starting point.
The obstacle avoidance is a stickier problem. Are you using a subsumption style control architecture? jBot does basically what you are describing, but without stopping to scan. The four SONARs cover about 15 degrees each, so collectively the array covers about 60 degrees in front of the robot. I initially had planned to use 6 sonars for 90 degrees coverage, but it turns out for a variety of reasons to be easier to use 4 than more than four.
But basically jBot drives straight toward a waypoint until its sensors see something, at which point it turns toward the whichever side is longer, same as you are describing. However, since it does not actually scan, the sonar essentially push it around any interving objects because the sonar behavior has higher priority than the waypoint navigation, which is "subsumed" whenever any of the sonars get a detection.
Seems like you can do the same thing, although I really think it is simpler to use a fixed sonar array (might need another Basci Atom to run it) than to scan with a servo --- just my prejudice.
hope this is helpful, best luck with your robot, dpa
Couldbeflying wrote

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.