Let's Make Robots!

Arduino Fio, I2C, GPS and motor issues

Anyone else using one? It is sort of an odd choice for robotics, but I got one for a project that it didn't work out for. The built in xBee support doesn't work with the 900 Pro. It's a power problem - it has too little. But I am powering it with 6v to its VIN from a BEC, so it was simple enough to daisy chain a couple of diodes from the BEC to a breadboard to give me 5v that I can power components with. I have a GPS and compass on the breadboard. I currently have Bluetooth on the hardware serial line and I am controlling a motor with ESC and a servo for steering my RC truck chassis.

Autonomous use of reverse?


I am curious if anyone is using it on a wheeled robot for normal navigation (not just backing away when running in to something). I am referring to ones that don't drive wheels independently; your standard rc car conversion or similar. I am implementing functions for it, but currently only in "traditional rc" mode. In autonomous mode, I would go in a circle to get 5 feet behind me. I think I am answering my own question; I am not sure how I will get to a point less directly to the side less than 2 turning radii away. Hmmm....

recommend a good ESC/motor for high efficiency 7.2v vehicle?

I bought an RC truck chassis which has "Trinity T-Tech Modified Motor for Tamiya, Duratrax Blast Reversing ESC" (verbiage from listing; the motor and ESC are labeled as such). It is a strong and fast setup. But it goes through batteries like water in the shower. I am thinking about replacing the motor and/or ESC if I can get reasonable speed an power and a much longer battery life. It goes faster than I really need to for most robotics anyway. I am suspicious that the ESC is the culprit.

433 MHz RF device compatibility


I wonder if these 2 devices would likely work together. 

RFM22B-S2 SMD Wireless Transceiver

sku: WRL-10153

Improving GPS accuracy by using a pair


I can't take credit for this idea; a neighbor did a project for a local utility involving RF meter reading and he used 2 GPS units in the vehicle.

Good algorithm for when to trust GPS speed and course?

In my testing so far, GPS modules that are locked in do a much better job in motion than sitting still. If I ride a bike down the street with a GPS, it will capture my route almost perfectly until I stop and then it gets "fidgety" and will jump around. Some modules do a better job of staying nearly fixed, but  I haven't had any that were perfect. The location data is still reasonably valid, but the implied motion throws off the speed and course reporting drastically. I need to come up with an algorithm to know when to ignore it but I need to start using it as soon as it is valid.

very cheap GPS

I posted this as a comment on the cheap FTDI cable idea and it occurs to me that a lot of folks who might be interested will miss it there...

Adjusting for air/water current

First a terminology question:

What do you call the direction a boat/plane is pointed?

Yeah it is a silly nit, but I am documenting a design and people will pick nits. A simple example is a boat crossing a river. For simplicity, consider the river flowing from N to S and boat crossing from W to E. So the bearing/heading is E. But if point the boat due E you will go SE, so you have to point the boat NE. When I learned to kayak, this was called ferrying and the angle was referred to as "set", but I hate using such an overloaded term.