Robo Magellan

SteveWoodrough

Below is a functional description / specification for my project. The first three items are included in the current program version shown in the link below. The remaining items are future functions that I intend to add once I get a handle on starting methods in cogs as described in the link below.

• Support the use of hobby grade servos and speed controllers.
• Support an LCD display to display real time data of selected information depending upon the mode of the program. There will be multiple screen displays depending upon the operation performed. The LCD screen displayed at startup will be different than the display during compass calibration which will be different than the LCD displayed while traversing to a way point, etc.
• Support the monitoring of actual motor speed via the Hall Effect sensor “Cruise_Control” so that the bot speed is some what constant over grass or pavement
Future Functionality
• Support the ability to determine distance traveled via the Hall effect sensor.
• Support collision avoidance via PING sensor.
• Support the use on an onboard compass module and its calibration at program start.
• Support the use of GPS to determine location, speed, heading, etc.
• Support un-tethered programming and real time monitoring of selected program variables. This is to be accomplished using VP and the Blue Tooth radio at some point. My use of the term “real time” may not be precise in engineering terms but its close enough for my purposes.
• Support the use of an SD card reader to store and retrieve way point data.
• Support the use of a 4x4 keypad to enter data as required.

Right now the project consists of an RC truck platform and the code is in the early development stages with the indiviual components connected to a development board. Once I get the code to a more work able level I will post.

My original questions and thread posts are at the link below:

http://forums.parallax.com/showthread.php?144024-Program-Architecture-Best-Practices-with-Multiple-Objects-and-Cogs

Steve

erco

Huge project! Baby steps... Good luck and please keep us posted.

prof_braino

More info is at the Chibots's "SRS Robomagenllan" page

http://www.chibots.org/?q=node/435

This one is by Chicago. Anybody else doing this competition these days?

SteveWoodrough

It surely is. It's really as assembly of a bunch of smaller projects. I've learned how to do each of the functional requirements outlined in the spec. The trick is in gathering them all together in an integrated system. Being an ME type makes it all the more of a challenge. Getting a lot of good foundational support from the seniors like Mike Green, Tracy Allen, and others. I cannot thank them enough for their time and support. See thread link in the original post. I'll post some pictures when I return home to Chicago.
Regards,
Steve

erco

SteveWoodrough wrote: »

It surely is. It's really as assembly of a bunch of smaller projects. I've learned how to do each of the functional requirements outlined in the spec. The trick is in gathering them all together in an integrated system.

Agreed, getting all the plates spinning simultaneously and in sync is a big systems challenge. Any one piece of the puzzle might be easily understood, but trying to get everything work together seamlessly can be, well, trying.

Rick Brooks

Steve,
This is what I am using.
Rick Brooks

shimniok

Great project! Looking forward to reading updates. I don't know if any of this will help, but... I am mid-40's and put together an autonomous rover that was the hardest technical thing I've ever done and between that and the last several years of doing robotics, it's been a firehose of learning.

With the rover, I took a systems engineering approach to my build and it was helpful to keep all the many issues, ideas, parts, and pieces somewhat orderly. I found it helpful to draft a "functional architecture" which abstracted some of the design details.

That is, categorize the various functionality to help keep it all straight. E.g., "navigation" abstracts compasses, encoders, navigation algorithms. "Odometry" abstracts hall effect sensors or wheel encoders, etc. "UI" abstracts LCD display and any input buttons. I mention this because such an effort is really R&D with a lot of R then re-D, then more R, then more re-D.

For example, you may assume you want a hall effect sensor only to find that it doesn't work quite like you thought and you want optical. Or you decide to ditch odometry and just use GPS, or just use optical flow, or... ??? Having a way to keep track of all the design ideas, design options, etc., was very helpful for me.

I used a variety of informal means of keeping all these things documented. Freemind (mind mapping tool) helped to sort of structure the hierarchy of categories. I also used OpenOffice to write a document in outline format for similar purpose. Whatever works to keep it all straight.

Another thing I've found helpful is to start thinking in the time scale of the robot and very carefully considering timing of everything. How often do sensors update. How often do the various code loops run. An example: if some control loop runs at, say 100hz, and it commands a change to a steering servo... and that servo swings 60° in 0.19sec, how many loops before the brain starts to see any kind of change in direction?

One last thing that I found important was to take a sort of Wright Brothers approach and break the problem down and thoroughly understand and test each problem. Like, understanding (through mathematical calculations) just how much heading error results from using a 2d compass in a 3d world with the robot tilted at various angles and in various directions. That kind of thing.

I hope this is of help in some way. More info on my rover, Data Bus, here: http://www.bot-thoughts.com/2011/05/data-bus-nickle-tour.html

SteveWoodrough

Rick and Michael,
Thank You. Rick, you gave a presentation at Chibots a year or two ago, that was a real inspiration to me. The idea was running loose in my head but your work proved that it was practical and do able even w/o CCD vision. As work progresses, I will be reaching out for you.
Regards
Steve

Rick Brooks

Steve,
Post your questions and I'll keep and eye on this thread.
All of my code came from the forum and OBEX and I hope that I documented it all good enough to trace it back to the original posting.
Rick

SteveWoodrough

Here is my latest update on my Magellan Bot project. Attached is a video showing the bot running in the field behind my house.

Still a few more features to add, but progress is being made. I'll post code and drawings once I get things in a more presentable form.

Best Regards,
Steve

http://www.youtube.com/watch?v=ft1SFeAYVuI

erco

Congrats, it's working great. Looks like a really challenging but rewarding project. One day!

Hanno

Tremendous Steve!
It's actually quite a challenge to create the hardware/software to drive at a consistent speed/heading over grass/snow - you make it look super easy!
I love the ME touches of handles and "clothes hangers". Did you have any issues getting accurate compass readings while it bounces around?
I've attached some sun and warmth from here- beautiful beach day!
H

SteveWoodrough

Thank You. I'm pretty happy with the results so far. I'm not a programmer, so this is the culimination of A LOT of study the past few years along with MANY trials and even more errors.

The hooks are used to hang the bot from a sling so that it can be rotated flat to calibrate the compass. A few loops about 4' long and I can pick up the bot and flat spin it easily.

The compass has worked pretty well so far, and I only make the heading hold accurate to within 10 degrees or so. Less time spent hunting back and forth for the EXACT azimuth. The trickiest part so far was the set of If statements needed to hold a course around 0 degrees. A little right is 5 degrees, a little left is 355. Typical error logic will not work. The solution I came up with will be in the posted code.

The PID was straight from Hanno's 12Blocks. Just a few lines of code, but its ccompact and easy to use. The Hall effect sensor works great at detecting the set screws in the plastic servo wheel. I chose this method over encoders, for it's simplicty. I have about a 1 cm resolution which as far as I can tell is enough.

The next hurdle is determining how to get from one way GPS point to another. Soon!

Steve

rwgast_logicdesign

This looks really cool and your doing some stuff i didnt realize was possible if i understand right. In the video the bot starts out and then goes in a circle around the snow and then onward doing the next thing. From what i understand your just preprogramming way points and using the gps to navigate? Whats amazing me is GPS can have up to 30 meters of error, so how do you use a GPS to do something like go around the snow? That seems like a pretty dead on type of task! Is it a bit of a lucky draw does the bot ever go way off the mark excpected due to GPS error? I mean around the snow seems pretty tight like your within 6 inches or so of accuracy.. Have you tested this in doors, if so does it work as well?

SteveWoodrough

Right now the bot is NOT using GPS for navigation. It is done solely on dead reckoning based on the compass sensor and the Hall effect sensor for motor / bot positioning. I think I got a bit lucky when the bot turned at my feet!

Anyway, there is a heading hold routine that always attempts to steer to a particular azimuth. The heading hold routine only maintains an accuracy of about 10 degrees (arbitrary) to avoid excessive hunting. There is also a PID routine(cruise control) that keeps the wheels turning at a constant speed , more or less. The PID gets it's info from the Hall effect sensor. The same Hall effect sensor also provides the pulse count for dead reckoning. To turn a circle, I just keep changing the heading hold azimuth through a " repeat index from 0 to 359 step 1 " loop.

The Hall effect sensor is set up with a magnet in "gear tooth" mode. It's described in the data sheet. For "gear teeth" I put a bunch of itty bitty (4x40x1/8) set screws in a servo wheel and attached to the trucks transmission clutch. Not real pretty, but darned effective.

WHAT I DO NEED help with right now is a simple reliable routine that takes the current GPS position and the desired GPS position, and calculates the required heading and distance between the two.

If anyone can provide some guidance, I would apreciate it.

Best Regards,
Steve

erco

You're starting to get me interested in making one of these, Steve. Must resist buying gps!

shimniok

Nice work! Looks like it is navigating fairly reliably which is impressive given the terrain and given it's only using compass and (I presume?) odometry.

I can help you with the lat/lon code. Take a look at this C++ object I put together for my Data Bus robot. It has several member functions that might be useful. You can calculate bearing/distance from one point to the next. You can calculate a new point given a bearing and distance travelled.

https://mbed.org/users/shimniok/code/GeoPosition/

Translating this to Spin wouldn't be too hard as it's really just math wrapped by a C++ class. Let me know if I can help further.

This is the code I was using in 2011 through to a month or so before the 2012 AVC. I then converted the approach.

Instead of using lat/lon, I converted my waypoints and gps reported position to cartesian coordinates. Then I did all the bearing/distance calcs with simple trig, rather than the Haversine formula used in the object linked above. The main reason was calculation performance for my custom sensor fusion. I'd be glad to provide more detail if you are interested.

rwgast_logicdesign

Very very impressive, im also building a robot, I decided to go at this from scratch which im starting to regret as I dont own a whole lot of tools these days. But its moving along the power system and mechanical stuff is coming togather so ive been looking in to odometery alot as getting the thing to drive in a straight line is uno numero on the list! This bot is very cool it shows me how well I can get around the yard using a compass and encoders only, Im hoping I can do as good of a job as you. Would you have any issues posting all your source code? I know your basically using obex objects along with your own stuff and 12 blocks code, it would be nice to look at how you pulled it all togather. I must be crazy, ive been coding for along time but this is also my first real project as far as electronics goes!

Ttailspin

Right now the bot is NOT using GPS for navigation. It is done solely on dead reckoning based on the compass sensor and the Hall effect sensor for motor / bot positioning.

Your new video is great, Dead reckoning is cool, and is not as easy as it looks..
However, could we get some better coverage of the set screws embedded into the wheel system?
Where ever did those come from? Did you build that? or did you git those at the gitten place? kin i git some too?
seriosly, the whole assembly looked very slick, at least from the .01 seconds of video.
I mean that I really like them, and would like to steal see more of them.:thumb::thumb:

Very cool project, Thanks for sharing.

-Tommy

rwgast_logicdesign

What kind of RC truck are you using? Was it affordable like <= 100, the chasis looks like one of the higher end RC cars

SteveWoodrough

The truck chassis is a Traxxas Rampage. Picked it up a few years back. Had to put in a new motor and speed controller dessigned for slower speed running. I've probably got about $200 in RC parts which is cheap. I've attached a few pictures of the "encoder". It's very simple. Start with a servo wheel, I used a Futaba. Get a bag of 4x40x1/8 set screws from hobby shop or hardware store. Drill holes and screw in the screws from the opposite side where the Hall Effect sensor will be placed. That puts more steel closer to the sensor. Make sure the screws stay somewhat flat and do not protrude past the plane of the wheel on the sensor side. Bolt onto something that rotates and you are all set. Next you need to mount the sensor and magnet to some fixed point on the bot that stays in the same position as the encoder, regardless of suspension motion.

Regards,
Steve

Ttailspin

Thanks for that Steve, To me, this is a revalation(or a duh moment), I have been trying to think up an easy to use jig that would cut
perfectly spaced slots in a disk, and here the whole time I coulda been using a jig I allready have that will drill evenly spaced holes..

This forum is awesome, Keep up the good work.:thumb:


-Tommy

rwgast_logicdesign

Im curious what was your motivation for using screws and a hall sensor for the encoder? It seems like most people just use an optical system as encoder wheels are easy to print and reflective sensors are 70 cents or so. Im sorry if i missed ot but is your encoder single channel or quadrature. I have one motor i need to add a home brew encoder too and your method looks fairly rugged, very awesome!

Its true RC stuff is way exspensive, originally i thought about buying alot of my stuff at the rc shop but it was just to much, especially for plastics. It looks like your using the same truck ive been thinking about its about 100 but just has an awesome suspension for the price and an ugly body.

SteveWoodrough

I orginally used an IR sensor looking a black and white tick marks on a wheel. Just like Andy taught in the Basic Stamp. Well that works great on the bench but no worky outside with the sun out! Funniest dogone thing you ever saw was me chasing an RC truck going full blast through the back yard since the IR sensor was blinded by the sun! Anyway, encoders seemed too expensive, and just another bearing to wear out on race day. This is simple, non contact, robust (enough). It could be made quadrature, if I added another sensor, but as I think about it, my screws may not be postioned that evenly and are too tightly spaced. I could get out of whack too easily. Point is, it could be made to do quadrature, just take a bit of effort.

halfblinddado

I am working on a "proof" of concept" and have cobbled together a program that gets a heading from GPS coordinates, compares it against the current compass heading and then steers the robot toward the second set of coordinates. Everything is working as I expected except the GPS takes longer than a second to refresh. This is a problem because by the time I get the new heading the robot has turned (for at least one second) to a new heading. This causes the robot to constantly correct (spinning in a circle, swinging left and right). Every once in awhile the compass and the GPS align at the right time and the robot moves forward.

I believe this is referred to as " hunting". I can't get the GPS to refresh any faster so the only solution I can think of is to stop the robot, take a reading, turn the robot then move forward again. I'm interested to know how others handle this.

Rick Brooks

halfblinddado,
Use the compass to steer the robot, not the GPS.
The compass can update very quickly. The steering with compass control loop should be about 20 to 50 msec. In the steering control loop, compare the present compass reading with the previous GPS heading and correct the steering.
That way the steering will be updated 10 to 50 times a second while the GPS will update the destination direction every second.
Rick Brooks

shimniok

halfblinddado wrote: »

Everything is working as I expected except the GPS takes longer than a second to refresh. This is a problem because by the time I get the new heading the robot has turned (for at least one second) to a new heading. This causes the robot to constantly correct (spinning in a circle, swinging left and right). Every once in awhile the compass and the GPS align at the right time and the robot moves forward.

I ran into this exactly problem back in mid-2012. http://www.bot-thoughts.com/2012/05/avc-whats-wrong-with-data-bus.html

In fact, the GPS is likely providing you old data. The two GPS units I've used provided data 1 second old. Even the Venus running at 10Hz still provided 1-second-old data.

The short answer is, steer off your compass, yes. But if you plan to fuse position/heading data, I believe you have to deal with this lag.

I compensated for the lag as described in detail here: http://www.bot-thoughts.com/2012/07/avc-heading-and-position-estimation.html

The short summary is, lag the "new" data to match the lagged data, fuse it, then use the error to correct the new data, then make a control decision (steering)

LMK if I can provide more / better explanation

SteveWoodrough

Successfully did multi point navigation with GPS today. Whoo Hoo, see attached video.

https://www.youtube.com/watch?v=M8u0VsNM0II


Thank you to everyone for your help and support. An extra thank you to Rick Brooks for his sharing and a super extra thank you to Mr. Phil Pilgrim for this little code gem.

http://forums.parallax.com/showthread.php/122260-Quick-and-dirty-four-quadrant-integer-only-arctangent-in-Spin?highlight=atan2

There is still a bit more to do, but functionally I am done.

Regards
Steve

erco

Great progress Steve, thanks for the update. Congrats!

SteveWoodrough

Attached is a drawing and the current version of the code. Hope it can help someone else.
Regards,
Steve

erco

Steve, you made it all sound so fun that I just ordered my GPS module (Parallax #28505) to get into the RoboMagellan game.