Results 1 to 6 of 6

Thread: The Limitations of an Arduino

  1. #1
    Join Date
    Nov 2012
    Manchester, United Kingdom
    Rep Power

    The Limitations of an Arduino

    Hey all,

    I'm planning to build a quadruped for my final university project, and I'm trying to decide what controller to use.

    I've used Arduino before, and I know one of the limitations is that there can only be one main loop in the code.

    I was wondering, is this a big limitation for robotics? All the trossen robotics walkers use the Arbotix, does it matter that it can't multithread?



  2. #2

    Re: The Limitations of an Arduino

    Can we get some more details about what you want your crawler to do? We're very happy with the performance we get out of the ArbotiX for all of our crawlers. When dealing with embedded programming, you have to think in a different way then when your programming a machine with multi-threading, but you can do really do a lot with this relatively simple hardware.

    I would recommend you take a look at our crawler code

    You might also take a look at NUKE, the software that was used to generate the IK engine for the crawler

    That's not to say that you couldn't do some impressive things with a multi-core/multi-threading. If you need to do anything with vision processing or other high data density sensors, you may need a different setup.

  3. #3

    Re: The Limitations of an Arduino

    You have to select your parts based on requirements.
    What communication protocol are you using to talk to the servos?
    What are the requirements for that protocol?
    What communication protocol (if any) are you using to talk to the controller from a remote end?
    What are the requirements for that protocol?
    What sensors are you using?
    What are the requirements for those sensors?

    What matters the most is precision in timing (Does a microsecond matter? Does a millisecond delay matter?) and frequency of updates (is it once per second, a hundred times per second, thousands of times per second?)

    Then you map this to the known capabilities of your microcontroller. For example, if you're using hobby PWM servos, with microsecond resolution, then you need to disable interrupts for two milliseconds every twenty milliseconds to generate a stable PWM control. This means that a serial port that runs faster than 4800 baud may cause dropped bytes while interrupts are off, so if your remote control needs higher bandwidth than that, the two methods are not compatible.
    If that's the case, you have to change one of the methods: use a slower remote control, or drive your PWM using timer interrupts instead of busy polling, which means less precision in the PWM control (+/- 10 microseconds or more.) Or you have to choose a hardware device with a deeper serial port buffer.

    (As an aside: This is one reason I love the I2C bus for communications; it has its own built-in flow control so each side of the conversation can handle things on its own schedule.)

    If you're using serial controlled servos (Dynamixel, Herkulex, etc) then instead you need to look at the serial port interface -- if you're using a regular Arduino, it only has one hardware serial port, so any remote control would have to be over software serial, which has its own limitations you need to research. An Arduino Mega has four hardware serial ports.

    Finally, the Arduino environment introduces its own overhead. The milliseconds and microseconds timers take interrupts every so often; various libraries/modules use interrupts that take up significant processing time; the digitalRead()/digitalWrite() functions introduce significant CPU overhead in the timing of setting output pin states. Depending on your timing requirements, you may want to write "raw" AVR C code using avr-gcc and avr-libc, rather than use the Arduino libraries.

    But it all starts with a clear characterization of all the requirements, and mapping those to the capabilities of your hardware.

  4. #4
    Join Date
    Nov 2012
    Manchester, United Kingdom
    Rep Power

    Re: The Limitations of an Arduino

    Thanks for both your responses!

    I want the crawler to do local obstacle avoidance as well as mapping out a room (using an ultrasonic sensor or a LIDAR).

    I'll be using Dynamixels, an IMU that uses I2C (for orientation angles), non-serial ultrasonic sensors and an XBEE.

    I think you're right, the arduino is capable of doing that so I'm probably overcomplicating things!

  5. #5

    Re: The Limitations of an Arduino

    "I've used Arduino before, and I know one of the limitations is that there can only be one main loop in the code."

    Yes, but... you can still handle many tasks seemingly in parallel. Here's how.

    The technique I used in my 20mph, 3rd place Sparkfun AVC rover, Data Bus, was to run non-critical logging and UI code in a loop in main() but to run time-critical stuff in a timer interrupt handler. Peripherals were interrupt driven (more on this later).

    The interrupt handler ran at a rate of 100Hz and would collect sensor data, compute pose estimate (heading & position), compute target heading, adjust controls (steering, throttle), and generate and queue up log data. But suppose you only want to update the controls at 10Hz. To do so, implement if-then blocks that run code every 10th call to the handler. In fact, that's what I did.

    You can find the interrupt handler here:

    Another simpler technique that I have used (also on Data Bus in a prior revision) is this: in your main loop, to check the value of millis() and run sections of code at specific intervals. I've done this using modulus, but there are other ways.

    A more complicated technique that I have not tried is to use a Real Time Operating System (RTOS). With it you create tasks and the RTOS runs these tasks at specified intervals. I plan to migrate to an RTOS in the near future.

    Also of note, utilizing hardware peripherals gives you some level of parallelism. The I2C or UART hardware can be writing a byte out to the wires while the MCU is doing something else, and can generate interrupts when something interesting happens.

    So for example I have my wheel encoders tied to two pins generating interrupts. Interrupt handlers simply count encoder ticks. GPS data is sent via UART and an interrupt handler for the UART captures data and decodes it.

    One must think carefully about the timing. How long does it take to service an interrupt. How long does it take to run all your tasks or interrupt handlers. Is there enough time left over for anything else? Will one interrupt override another and is that ok or not?
    Last edited by shimniok; 10-02-2013 at 05:28 PM.

  6. #6

    Re: The Limitations of an Arduino

    IMO, the AVR is ever so slightly too small to really benefit from an RTOS. Running everything through polling in the main loop is simplest, and interrupts is something I only use when really needed these days.
    On larger MCUs, an RTOS, and good discipline around interrupts, can be very helpful, and on "full size" processors, interrupts are a total necessity.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Arduino Lib Help!.
    By brian25 in forum Software and Programming
    Replies: 5
    Last Post: 09-04-2013, 09:25 AM
  2. Question(s) Arduino- xbee -xbee-arduino - stepper motors
    By Icemonkey in forum Arbotix, Microcontrollers, Arduino
    Replies: 7
    Last Post: 06-04-2012, 12:35 PM
  3. About arduino
    By gdavenport75 in forum Arbotix, Microcontrollers, Arduino
    Replies: 2
    Last Post: 11-17-2011, 12:55 PM
  4. Dynamixel Limitations?
    By RoboTy in forum DYNAMIXEL & Robot Actuators
    Replies: 2
    Last Post: 11-30-2010, 08:40 PM
  5. PVision library for Arduino (Pixart/Wiimote to Arduino)
    By shobley in forum Robot Computers
    Replies: 1
    Last Post: 03-01-2009, 05:07 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts