Robotic Navigation

Hey all,
I am involved with the Robocup Junior program and I just have a few questions for uall.
First, we are looking to replace or improve our compass system so that we
have more accurate readings on our heading. At the current time we have 2 problems with the current compass (CMPS03). First is the magnetic interference that occurs at points around the field. Second is the fact that it works off an i2c interface and we use an MIT Handyboard which does not have i2c. This means we have had a convertor from i2c to analog voltages built for us, but it isnt very good (gives 70 points of differentiation roughly) which is far from what we desire.
We have seen the vector2x compass which looks better suited for our needs but due to limited time and money we would rather come up with a better solution using the CMPS03. Anyone have any ideas on how to better use this compass with the handyboard?
Second question. If we chose to scrap the compass to avoid the interference issue, is there any other sort of sensor that would be able to let us set a point (that we would call north...the goal that we are aiming for) and be able to tell where it is facing in relation to that point and rotate back toward it? We have looked at gyro's and some other systems but have not found anything that fully suits wat we need yet. It isnt really possible to use encoders on the wheel as we have an omni directional drive system which makes it hard to measure the direction that we have been driving in, so dead reckoning isnt really an option as far as I can see. Any ideas on this would be good.
If anyone has a good method of distance measuring I would also be interested. Again, we are using SRF08 ultrasonic modules but due to the i2c interface we have them hooked up to the convertor as well. We have found that ultrasonic readings are not very constant (tend to waver a bit) and are also not as accurate as we would hope. If anyone has a method that does not emit infra-red light (against the rules) I would be very interested to hear it. We have looked at a colour sensor to find where we are in relation to our goalie which would be coloured brightly, and also in relation to the grey opposing goal, but the colour sensors are too expensive for our use.
Has anyone had experience making a mumetal shield? We were looking at this solution to prevent some magentic interference getting to our compass from the floor.
Thanks for your help
Jeff
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
If you can give me a hand bit banging the i2c on the Handyboard I would be very greatful, I just don't know where to start!!
TIA

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Where abouts can I learn about all of the different big banging commands, all the hex addresses for the ports, etc etc? I think this would help alot with the problems that we are having!
TIA
Jeff

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Fr335tyl3r" <fr335tyl3r> wrote in message

The bit banging commands would depend on what language and development environment you were using. In assembly, LDAA, LDAB, STAA, STAB with OR's and AND's to manipulate the bits. There are other instructions which are fancier, but that's the basics. As a wild guess, I suppose you might be using Interactive C. I haven't so I can't be much help.
Well, on HC11, the ports are in a 64-register block. Unfortunately this can be moved. If it isn't moved, left at the default address, it's at $1000. If it is moved, say like by my Max-FORTH, then it would be at $B000.
You can get detailed information on port addresses from the Motorola literature on HC11. I can tell you, for instance, that PORTA will be at $1000 (or $B000 in MaxFORTH).
If you don't mind me asking, why the Handi board, specifically? Got some code to start with? or other motivations?
-- Randy M. Dumse www.newmicros.com Caution: Objects in mirror are more confused than they appear.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
We started using the handyboard a while ago cause I found the code fairly easy to write and we needed to get something up and running quickly. Overtime we have added in bits and pieces to the system and are now realising the limitations of the handyboard. I looked at the Basic2p Stamp yesterday and it seemed to be able to do pretty much everything the handyboard can do and a bit more but unfortunettly we dont realli have the time to change our design at this late stage (we have a robotics competition coming up in about 5 weeks)
Possibly for next years competition we will be changing to something like a Stamp or another processor. I guess the main reason that we chose handyboard was that it was very easy to get started with (no circuits to build) and I already knew how to program very well in C so it wasnt a challenge at all to get the programming out of the way. If we had more time, I would have really liked to change to a stamp so that I culd have developed all of my own circuits and it would have felt a lot more fulfilling to get it all working perfectly, but this is wat we have to work with at the moment, and are just trying to get this system onto its feet.
Does anyone know how easy it is to emulate i2c on an SPI connection as we have an SPI interface available on the handyboard but we havent used it before and are not 100% sure how to make this communicate with the i2c devices?
TIA
Jeff

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.