Fast enough for pathfining (robot)?


i am quite new in using microcontrollers and my first project (arduino, just simple do something when the user hits the button) is done.

I am interested in building a simple robot, that would be able to navigate in my flat.
In my job i am a .net developer so it would be great to use a microcontroller with the .net micro framework on it. But i am a bit skeptikal if the interpreted c# is fast enough to execute some navigation / pathfinding algorithms on it. Or would it be better to just write c(++) code, that is not interpreted?

Thank you for your advice,

Welcome to the forum!

It should be possible. I think somebody did something similar before. For sure there is a code to balance a two wheeler robot which is a similar complexity.

Architect would be much more knowledgeable than me on this, for sure, but for pathfinding itself, I think there’s plenty of processing power, especially in a board like the Raptor.

2-wheel balancing needs to make very fine adjustments many times a second (both reading sensors, and adjusting servos) so if someone has gotten that to work, then pathfinding (which, it seems to me, needs an order of magnitude less processing power) should be a piece of cake.

There -was- a “line following” type of gadgeteer module available awhile ago, that was used with even the slower boards:

It was fast enough to prevent bots from going off tables, supposedly, so I am assuming some people got that to work. (it is discontinued now though)

If you are looking for pathfinding along the lines of mapping an area in decent resolution with distance sensors, and object avoidance navigation that remembers where obstacles are, you’ll probably need a board with more ram, like the raptor, to store where you sense objects, and encoders on your wheels to determine more accurately where you are, and maybe a compass module for confirming direction, but it should all be very doable in C# with the gadgeteer boards, and I am sure many people have done it.

I’m actually working on something similar. It hasnt been speed or ram or processing power that have been my issues. Its been getting parts to get my Vex Mecanum wheels to mount nicely on some decent motors, lol.

1 Like

Actually @ taylorza did both. Here is his line follower:

Yeah, but taylorza is a genius. I was thinking that even normal people could do it too.

Pathfinding is more difficult than line following. I’m not sure there’d be enough processing power to do realtime mapping and route planning, but if you already had a map (or plenty of time to create one) and you could tolerate stops to plan routes in the event that it took a while, then there shouldn’t be any problem.


thank you very much for your answers!

I think line following and a balancing robot have some needs in processor power, but more like “fast reaction” to input signals.

That’s the point. It would be okay if the robot needs some time to generate the map and find the fastes / shortest way. But it would be interesting, how much faster the same logic written in c on the same hardware would be. If the calculation needs 1 second in c and 20 seconds in c# with .net mf, it would be better to learn some c. :wink:
If it is just a factor of 1.5 or something, i would love to stay with c#.

Do anyone have experience about this?

Thank you!

I’m sure a Raptor would handle it without too much trouble, but it obviously depends upon the exact algorithm used. You can probably split it into at least 2 threads. One could do the basic fast level control while the other could do a slower time course control/route guidance.

An interesting idea I found while Googling ‘pathfinding robot’ was to use an optical mouse to track horizontal displacement. Easy peasy with GHI USB Host.

@ Daniel7 - Welcome to the group.

1 Like

Hah! That’s brilliant! Did it say anything that you can do to increase the range (how high the sensor can be above a surface?)

Wow… use a logitech mouse/keyboard dongle in a USB Host module, and you could use a mouse sensor for movement, and also send commands using a wireless keyboard for remote control. Awesome. +1

This, + using an old CD ROM Drive for Motors, and you can build a real cheap robot :wink:

I think there were a few problems. Such as focal distance, bumps and surface.

Thank you very much for your input, ideas and your nice welcome messages. :slight_smile:

Nice find with the optical mouse. :dance:

Due to my speed issue: I think i should give it a try.

I have a question to the board styles: For example the raptor mainboard: Can i use the pins, that are combined to the 10 pin special gadgeteer connector as normal seperate input / output pins, too? Or are these pins blocked for this purpose?


@ Daniel7 - Yes, you can use them as GPIO.

@ Daniel7 - As @ Architect notes, you can usually use a given pin as GPIO, as long as it’s marked as GPIO capable. Some are also able to act as interrupt pins. You can read up on the pinouts for various socket types at:

Ah, very good. Thanks!

I think i will order a fez hydra. A local distributor has them in stock. :dance:
It should do the job for me.


I would recommend the G120 based Cobra2 over the Hydra in my opinion. It’s better supported by GHI.


As FEZ Hydra has been released as open source, some of the features found in other GHI Electronics’ products are not available. The following are not supported:
SPI display configuration
Non-blocking Signal Generator
Play PCM audio
Bitmap convert to file
RLP ELF file parsing
RTC Alarm
InField Update
Startup Logo
SD card detection
WiFi RS9110
USB host
USB client
Passing bitmaps to RLP
Bitmap get and set internal buffer
UART handshaking[/quote]

Oh, that’s interesting.
I am not sure if these restrictions are relevant for my project.

Cobra II: Thats the board layout i like most, but i am unsure if the ram is large enough to store a larger map.

Edit: Ooops. I mixed up the cobra with the cerbuino. :smiley:
Of course the ram of the cobra ii would be large enough.

Order(s) of magnitude, unfortunately. C# is interpreted on NETMF devices (for now, at least :)) so it’s much slower.

@ Daniel7 - a cashed native JITted method gives 4x performance improvement vs managed version of the same method according to this discussion:

A native C implementation will be significantly faster even.