Go Down

Topic: SLAM on arduino and Sonar? (Read 4379 times) previous topic - next topic

teddyyyy123

apparently all SLAM algorithms are too heavy a computational load for arduino (the MCU type, not TRE), so while I'm working on my robot based on ROS , running on a full-linux, 8-core ARM board, and an expensive laser scanner, I'm trying to figure out what is the most we can do with an AVR MCU based board, and 1$ sonar rangers.


right now most of the robotic car projects based on arduino does not have much autonomy in navigation, they either have to follow printed routes, or are controlled like an RC car.

the ideal autonomy would be SLAM, so that the robot car builds a map on its own and navigates in the empty parts. but due to the complexity of the algorithm, we can't run it on an MCU.

then it comes down to kind of downgrading the desired service, maybe getting to the level of first-generation Roomba, which just tries to go in a random direction unless it detects an obstacle. I think this is what the iRobot create does. would it be possible to reach some level of higher intelligence? some level of autonomous navigation, with reduced accuracy (given the limitation of Sonar vs LiDar) , and simpler algorithm? this price range and power/form-factor range would find many good use cases such as toys.

keeper63

You say "the SLAM algorithm" - which one? There are dozens, if not more out there.

I personally think that Tiny SLAM could be implemented on an Arduino Mega 2560, with a 512K SRAM expansion board - and perhaps a SD card. At only 200 lines of C code, it shouldn't take much.

The main downside would probably be speed - all the memory in the world won't help you if your SLAM code is loping along like an asthmatic jogger. Even if you boosted the Mega to run at 20 MHz instead of 16 - that still would likely be a bottleneck. Then again, AFAIK, nobody has tried putting Tiny SLAM on an Arduino...maybe you could try it out?

Or - maybe Tiny SLAM could be divided up (not sure - I haven't looked at the code much) and split over multiple Arduino Mega boards; essentially a low resources parallel cluster, if you will (use SPI as the interconnect - or a custom parallel interface).

Despite all of this, and even though it might not be fast, it would be a great learning opportunity - you could essentially re-implement the Stanford Cart or one of the other early auto-nav robots (it would probably process the data faster compared to them, too).

Alternatively - it might be possible to implement a really scaled down SLAM algorithm, where the map is essentially a rough grid of cells, perhaps with just a few levels of probability - perhaps not super-accurate, but maybe fast to process and could likely fit on an Uno (for a small map, anyhow).

If ultimately the small form factor is the need - then there are plenty of ARM-based SOC boards out there that are more than small enough, on which Tiny SLAM or some other more complex SLAM algorithm could be run (ie - the Raspberry Pi, Banana Pi, Orange Pi, BeagleBone, Pine A64, etc).
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

PaulS

#2
Dec 16, 2015, 12:20 pm Last Edit: Dec 16, 2015, 12:20 pm by PaulS
Quote
Even if you boosted the Mega to run at 20 MHz instead of 16 - that still would likely be a bottleneck.
The Due has lots more memory and is 5 times as fast. Might be a better choice.
The art of getting good answers lies in asking good questions.

keeper63

The Due has lots more memory and is 5 times as fast. Might be a better choice.
At that point, though, you might as well move to a RasPi...

...I guess I am just biased; I think "8-bit" when I think "Arduino". It's too bad there wasn't a 16-bit Atmel microcontroller (or any such 16-bit device). I guess I just have this bias that when things move beyond a certain amount of memory, speed, and "bits" - they become something else.

Don't get me wrong - I realize that the world has moved on to 32 bit embedded controllers with gobs of RAM and speed - and that there isn't anything wrong with that, and helps allow for certain capabilities and project implementations that couldn't occur before.

...and - to a certain level, even the ATMega328 is a wonder to me, as it is (in a certain way) more powerful than my first computer (TRS-80 Color Computer) - albeit the Harvard architecture hobbles it somewhat...
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

MarkT

The future of SLAM (and many other things) will be GPU-accelerated I think, another order of magnitude
or two faster still.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

teddyyyy123

The future of SLAM (and many other things) will be GPU-accelerated I think, another order of magnitude
or two faster still.
I totally agree with you. that's why I bought the pcDuino 8 (with PowerVR GPU, which has 4 cores) for my Lidar-based project.

but I later found that that GPU computing on SOC is basically a pipe dream: not only are their GPUs flimsy compared to the expensive 1000+ core GPUs specifically designed for parallel computing, it's notoriously difficult and flaky to try to write or compile CUDA/OpenCL code, since there is basically no vendor support, and most drivers are closed source.

anyway, the point of this thread is more about exploring the achievable applications under very limited resource constraints.

keeper63

#6
Dec 22, 2015, 02:28 pm Last Edit: Dec 22, 2015, 02:30 pm by cr0sh
A couple of interesting links:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.408.5352&rep=rep1&type=pdf

http://cs.krisbeevers.com/thesis/

Both deal with something called "ratbots" and "ratbot SLAM". A "ratbot" seems to be your typical small differential drive tabletop robot chassis, with a limited number of sensors. The SLAM algorithm for such a robot seems to be tailored to work within the constraints of an ATMega microcontroller (an ATMega64). Reference in the first paper is also made to another project in which a SLAM algorithm was deployed on a M68HC11 microcontroller as well.

The ATMega64 compares well to the 2560 with an SRAM expansion.
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Go Up