AVR Freaks

I thought about the Raspberry PI as well. It has more peripherals than would ever be needed, but it is quite inexpensive and would certainly do the job. Smartphones too ( or even, potentially, a very small tablet ) could be interesting. I've yet to give any of those the thought they deserve. The Iteaduino Plus looks very interesting too. I especially like the "core" module that they have there. It still pushes the size constraints somewhat, but it is, potentially, a bucketload of processing capability and it has the advantage of being swappable to new hardware easily.

The more I look at the problem, the more it seems like a ready made processing module is the way to go. Something that runs full Linux would be even better as development could be the same as their more normal PC based assignments.

External CAN would certainly not be an issue. In the grand scheme of things, CAN is not all that fast to begin with and we are not using any particularly fancy controller features. It's just got to exchange some fairly simply frames. We're moving toward CAN more for the noise resilience than for speed ( the current robots are using fairly extended I2C buses... yes, there are issues! I did warn them. ).

What I have convinced people to do, for now at least, is to develop the algorithms to a more complete point on a PC before deciding on a final on-board hardware configuration. The sizing is somewhat flexible, but 100mm x 72mm would certainly be stretching it beyond the breaking point ( one new robot design is about 150mm x 80mm x 40mm aside from its wheels, this has to hold the motors, motor drivers, batteries, mapping board, and other sundry sensors ).

I am almost tempted to go back to my first thought which was to build up a ChipKit compatible board with extra memory attached or, better yet perhaps, an Arduino Due clone using one of the SAM3x devices that has an EBI. It would limit map storage to a couple orders of magnitude less than the real target, but that should be sufficient for a first run to develop the basic algorithms and, intriguingly, it would allow the team to stay with the same development environment they are used to, which would speed the ramp-up time on the project. Later, something like a Cortex-A9 SOM or something could be substituted when the capabilities of the less ambitions board were exceeded. Until then, it would be easier to learn and use less power ( not a major issue at the moment, but you never know ).

While it is true that necessity is the mother of invention, data is data. It can be compressed( sometimes ) but it must be stored somehow. There are some amazing things that a plain Arduino can do -- there are simply some it cannot. Already the robots are navigating quite well within the confines of doing so without the ability to permanently store an extended map. The area that should be stored ( ideally ) is around 1km x 1km with a resolution of <= 0.1m. Using a uniform grid ( roughly 10^8 points, minimum 800Mb ) for the occupancy map, that's a huge memory for smaller embedded devices. Using a quadtree, it is much more approachable -- smaller by, perhaps, two orders of magnitude; but an Arduino, stock, just can't handle it.

Martin Jay McKee

I have tended to lean away from using an SD card as a swap space mostly because I dislike the idea of writing it continuously during operation. But, honestly, given the fact that there is only need for ~128MB, it would be easy to install an SD card an order of magnitude larger size, and the built-in wear leveling algorithms... it may just make sense. Doing it that way, it would be pretty easy to get away with something like the LPC11C series. It would be a bit short on SRAM, but it would be doable. If not, moving up to a larger device in the PIC32 range ( which has the advantage of remaining ChipKit compatible ), or careful selection of an Atmel SAM3 ( for Arduino Due compatiblity ), would be a noticeable improvement in processing capabilities without going over board either.

Were it simply me implementing things, I wouldn't use any floating point, I'd do it all fixed point. Given that it will NOT be me doing much of the code, however, I would expect that there will be plenty of floating point usage. Still, it is fairly slow ( as I've said ), so I don't believe there is a need for hardware floating-point support.

The other constraint that I do have to remain aware of ( and tends to reduce my list of choices ) is the need for two I2C controllers. This requirement comes about more from logistical requirements than from electrical and is a result the use of many devices that have the same addresses. By partitioning the busses, it is possible to reduce those issues. It is possible that one of the busses could be a master only bus and be guaranteed to be in a single-master environment, in which case, as software I2C would be perfectly sufficient -- I'm still awaiting confirmation however.

Martin Jay McKee