Main Site Documentation

Robot controlled by domino - what should I be afraid of?


Well, I think I got the FEZ bug, so in search of cool things to do with it I decided to ressurect my 2-year old robot project. During my last attempt I tried using TI MSP430 MCU, but didn’t know enough to get the thing finished. With Domino I think I stand a chance now :slight_smile:

Before I go any further: I’m a C# programmer with a lot of experience with building/assembling circuit boards, but no EE experience whatsoever… When it comes to FEZ Domino, robotics etc, I’m a complete noob…

So, here is the idea:
The robot is driven by two stepper motors
It will have two Sharp IR distance/proximity sensors attached to a hobby servo and doint 180 degree sweeps detecting obstacles.
The brains will be on my laptop, so Domino will be responsible for driving the motors and the servo and reporting the “radar” data.

In future I’m sure I’ll find a reason to have an accelerometer, GPS, coffee maker, toaster etc. (Someone once said: if it’s worth doing, it’s definitely worth overdoing) :slight_smile:

For now I’m using SparkFun’s BlueSMIRF Blue Tooth modem via SPP profile.
The communications are working fairly reliably so far (via COM1 on FEZ) from 9600 to 115200 baud, as long as I don’t do “bursts” at less than 10ms between lines. (If I sent too much too fast I get an OutOfMemoryException, but every 10ms looks well more than enough…)
I think I will add hardware flow control too, so it should only get better.

My initial thinking is to have the controller (laptop) send commands over the serial port. Some sort of parser will parse them on the Domino and execute the appropriate functions. For example, something like MV R F 10 100 would mean move right motor forward 1 clicks at 100 clicks/second…

So, here are my questions:

  1. Are there obvious gotchas with this approach?
  2. Is there a much better way of doing serial communication?
  3. Am I reinventing a wheel?

Thank you in advance


Clearly, the first thing you need to worry about is your robot attempting to take over the world. This would be disastrous. You already have it talking to computers… next thing you know, it’s giving you orders and wiping out the human race. Whatever you do, don’t hook a toaster up - next thing you know, it’ll think it’s a Cylon!

On a more serious note, Make sure you have an opto isolator between your stepper motors and your domino. At least one forum member fried a Domino by not doing this. They are very simple to use!

Other than that, things seem to be fine. Any reason you don’t want to do more processing on the Domino?


Thank you for the tip, first of all. Opto isolator looks like a cheap insurance policy…

Honestly, I decided to do the processing on the laptop in the spirit of overengineering. In other words, I don’t know what the limits of Domino are, and I know that my Intel i5 laptop has enough horse power (plus a cool screen to draw radar images).
My copy of “Expert .NET Micro Framework” is in the mail, so I might change my mind a couple of chapters into it. It takes some time to adjust from “dual quad core” with GBs of ram to USBZee with KBs of ram :slight_smile:

In reality, once I feel more comfortable with hardware I will likely make the thing more autonomous (u-oh, next step in world dominatio), or at least have a level of abstraction, i.e. “go to x,y fast”, instead of step left motor 10 times

Thank you


Why are you so cruel ? :’(

I’m joking, of course :wink: Btw, did you receive the board ?


Hi Ycroosh
I don’t know if you are familiar with this site, but there is lots of information for your type of robot in there.
And we need more MFNET people :slight_smile:

PS. And when it comes to RAM. People are building robots with PICAXE chips and there you only got 16bytes for RAM for variables :smiley:


I am running PID controllers and things on my Domino for RWAR. There aren’t too many limits, and if you hit one you can just optimize your code down.

Unless your robot is doing image processing, you’ll be fine with the Domino.


I’m a C# dev as well. For me, coding in NETMF without LINQ, generics, etc, I am hoping it will make me more efficient in “real life”.

If you’re a C# dev already, then NETMF is very easy to transition into.


I started using C# before there was intellisense (VS.NET, 2002 version). I can live without LINQ, extension methods etc., but not having generic list and queue bugs the heck out of me :slight_smile:
On the other hand, it took my former boss 4 years to teach me not to obsess with “performance” and instead concentrate on readability, maintainability and reusability in “real life”. It look like in NETMF those aren’t nearly as important as squezing every byte or RAM and very tiick of CPU. Needless to say I can now go back to being my normal performance-obsessed self :slight_smile:

So far the thing that bugs me is the fact that FEZ Domino is a tiny device (compared to modern desktops or even phones), yet I don’t have full conrol over CPU cycles, like I would on a microcontroller. On one hand I’m really gratefull, since last time I used a MCU I failed miserably. On the other hand, I still don’t know the exact paramenter I can work within.

Thank you


I started in QBasic, then various versions of VB (I think), went to VC6 for a little while, and then to VB.NET and have settled in on C# for a while now.

The limitations are dependent on what you are trying accomplish.


I bought the Expert .NET Micro Framework just out of curiosity, it’s probably the biggest waste of space on my bookshelf (more so than old 1200 page ASP3.0 books). Make sure you read the FEZ Ebook, it’s much better.


Is the book really that bad? I’ve read the ebook, so I was looking for “the next step”.
Do you know a good resource on code optimization and more advanced toppics?

Thank you


I must admit i havent read through it all, howver it takes 47 pages to get to the point where it introduces the net mf base class library, that’s 4 chapters in. The Ebook is much more concise and fez centric. There are only 400 odd pages, of which 47 are all about the various devices and then 100 pages are about emulation… soo you’ve only really got an extra 50 pages over the ebook anyway.

Looking through the eBook there isnt really anything on optimisation. Basically, how i’ve worked out how to optimise is to have a “code tester” which runs a method 200+ times and then slowly try different things to optimise the code. It’s surprising how much of a difference some things have. I have most of my C# code running faster than the native code equivalents now. Some things in NetMF are just really slow and those things add up to hundreds of miliseconds.

I was planning to write my own NetMF book targeted at hobbyists however i don’t see myself getting time for that any time soon.



That’s the first thing I thought of when I saw this thread.

I’d just like to go on record as saying that I, for one, welcome our new FEZ-powered overlords. :slight_smile:


I think youre safe for now. The developers of the chipset made sure PWM uses one frequency, sp my mean uber-robot can only travel in a straigh line. Good luck taking over the world when you can’t turn and go at the same time :slight_smile:

On a serious note, I think “my mind has been changed for me”… I decided to use MSP430F2274 MCU to drive the motors (it has two independent times, and I have 3 on hand).
MCU will use two input pins for speed and direction via standard hobby servo “protocol”. This way I will have a level of abstraction between FEZ and stepper, ability to drive steppers via my 2.4gHz car radio (if I want to simply drive the thing around :)) or use standard car/truck as the platform in the future (I have 6+ hobby grade trucks/cars/buggis…)

I think this way I can have a real-time motor driver and FEZ dedicated to higher level processing, rather than spending CPU cycles on PWM…



Output compare can do the job?


Why would only having one frequency be a problem? Just vary the duty cycle…


The steper driver is triggered by the raising edge. Each pulse moves the stepper one click, so the duty cycle has no bearing on the motor speed.

Thank you


So set the pulse time instead… :wink: