Sasquatch Robot Controller powered by Arduino

[BornaE]

The Atmega2560 should be able to handle anything robot related thrown at it short of video processing. We used one this past summer for the sparkfun AVC.

video here.
This involved:

• bringing in the info from a GPS and a gyro.
• Doing all control loops for autonomous navigation.
• Tunable parameters over a wireless link.
• Send telemetry information over the wireless link for debugging

However, beware that the Arduino does not support double precision math. Everything is done single precision floating point.

[Ether]

Originally Posted by BornaE

However, beware that the Arduino does not support double precision math. Everything is done single precision floating point.

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

[BornaE]

Originally Posted by Ether

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

The problem is you can define a variable as double and it is stored in memory as a double however the math is done as single precision. No warnings from the compiler or anything that would tell you this is happening.

Main reason this was an issue was that I was using doubles to do GPS lat/longitude calculations and it was being rounded/truncated which was causing accuracy issue.
To fix this, I stored the GPS lat/long x 10^7 as a 32 bit integer and take the difference with integer math and do the rest in floating point.

Another place this may be useful is gyro integration and the offset. However single precision works fine.

[apalrd]

Originally Posted by BornaE

The problem is you can define a variable as double and it is stored in memory as a double however the math is done as single precision. No warnings from the compiler or anything that would tell you this is happening.

This is really really common in embedded systems.

The compiler allows a Double because it's a valid, common type, but converts it to Float because it can't do Double math in hardware. I'm not actually sure that the Arduino's processor is doing any float math in hardware, so the single Float you ended up using could have been a software float (I'm not sure).

Usually it's in the SW toolchain documentation, and fairly easy to miss.

As for the gyro, it's probably much more efficient to do the math as a signed int or long and stay in ADC counts as long as possible. Unit conversion (especially divides) are usually very expensive operations on embedded systems, so they usually make up units to use signed or unsigned integer math in whatever units are convenient. This leads to heavy use of ADC counts as real units, percent as a signed char (127 being 100%), and angles as 'brads' (0-255 for a circle of 360 degrees). Also, for precision, many algorithms for embedded systems focus on using the less expensive bit shift rather than divides.

All of this cRio programming has made everyone really lazy with their math. It also seems to make it OK to add tons of layers of abstraction with no care about efficiency. It makes me sad to see relatively simple robot code running at only 50hz or so (realistically slow for a control loop) use the entire processor, without thinking about vision.