# Microcontroller/cpu for fast trigonometry in robot?

This concerns hardware that does weighs little, because a (fat cat sized, 6 legs with 3 DOF) walking robot should carry it around. Because of that walking it'll need to do a lot of trigonometry (using matrix math or not i'm not sure yet) and this is where this question comes from.

PIC, Arduino or cheap AVR is not fast enough to calculate everything 100/second and keep things like inertia and obstacle avoidance in mind, or even bruteforce paths/gaits.

• Plan A is to carry the brain on the robot. Be it microprocessor, micro ITX, nettop or other; what is efficient hardware to do trigonometry / matrix math fast?

I searched online and expected to find out about AVR, x86, or ARM microcontrollers specialized in this but no luck there.

• Plan B is to have a x86 machine connected via WiFi to do the heavy lifting. Great for prototyping also, but i'd like this to migrate to plan A eventually when the hardware miniaturizes. But even then, what desktop CPU can do trigonometry the fastest?

• Plan C is to distribute the load and have one power efficient microcontroller/core for each leg, although that is not the best solution for many reasons i like the extend-ability of it.

I have not decided on the language and/or library used yet, but prefer Pascal and C++.

(suggestions for more suitable tags welcome, i am new here)

• floating point math is not a must. You can always build sine (or any other function) tables, put them into the flash of an AVR and interpolate between the values with fixed point calculations. This might be fast enough for your needs. – Christoph Mar 13 '13 at 8:50
• Rather than doing lost of heavy maths in realtime, a common solution is to pre-calculate tables of values & then look up the answer. The idea of distributing the work between multiple CPU's is also good, for example one powerful master CPU and then one processor per leg. – John U Mar 13 '13 at 9:31
• You might also consider asking this kind of question on the Robotics Stackexchange site. – Rocketmagnet Mar 13 '13 at 10:44
• Plan B will do the calculation pretty fast, but communication over WiFi will most probably kill the performance gain. Did you consider using an Android phone connected via usb? It's a lot more computing power without lag of wifi – stefan Mar 13 '13 at 14:44
• A STM32F4 board with Floating Point Unit seems to be sufficient for your application. It has 128k SRAM with 64k CCM. It can runs at 168MHz. A 32-bit floating point multiplication only takes 1 CPU cycle.. – richieqianle Jun 16 '14 at 3:33

## 8 Answers

It does not sound like your application is really all that compute intensive. A dsPIC, for example, can execute 400 k instruction for each one of your iterations. That's a lot. It will be useful, however, to have good low level I/O capability, PWM generators, timers, and the like.

Sine and cosine is really not that hard to do in a integer machine like a dsPIC. I have done it a few time myself. The trick is to pick the right representation for angles. Radians may be nice from a theoretical point of view, but is inconvenient computationally. Degress are artificial and just silly. Use the full range of whatever your machine-sized integer is to represent one full rotation. For example, on a dsPIC, which is a 16 bit processor, one full rotation is 65536 counts, which is way more accuracy and resolution than you need to control a robot or that you can measure anyway.

One advantage of this representation is that all the wrapping happens automatically just due to how unsigned integer adds and subtracts work. Another significant advantage is that this representation lends itself particularly well to using lookup tables for sine and cosine. You only need to store 1/4 cycle. The top two bits of the angle tell you which quadrant you are in, which tells you whether to index into the table forwards or backwards, and whether to negate the result or not. The next N lower bits are used to index into the table, with the table having 2N segments (2N+1 points). Note that indexing into the table backwards is then just complementing the table index bits.

You can give the table enough points so that picking the nearest answer is good enough. For example, if the table has 1024 segments, then sine and cosine will be computed to the nearest 1/4096 of a circle. That's going to be plenty for controlling a robot. If you want more accuracy, you can either make the table bigger or use the remaining lower bits of the angle to linearly interpolate between adjacent table entries.

Anyway, the point is it seems your requirements for this processor don't match up with the stated problem. I'd probably use a dsPIC33F. It is certainly small, light weight, and much more power efficient than a full blown general purpose computing process like a x86 on a single board computer.

• I was always under the impression that a PIC was to slow for even just the inverse kinematics, but i might need to reconsider. Is it possible to do inverse kinematics for 6legs of 3DOF at least 100/second? Thats 6x3x100 inverse kinematics just to get the live leg movements. Anyhow i need the inverse kinematics to happen on the same platform as the algorithm runs, so that i don't have to reimplement these parts twice. The algorithm would be more demanding, and certainly wont be able to run on a PIC or Arduino-isch board. – Barry Staes Mar 13 '13 at 15:36

You're going to deal with a lot of input signals. You don't necessarily need a CPU with a high throughput; a lot of signals can be processed in parallel. This is typical DSP territory. Of course, you do want general CPU functionality as well. This is no problem. There are plenty of CPU's with integrated DSP's.

A typical chip design for such applications is a Cortex-M4. This comes with an integrated DSP, and -M4F versions also have a FPU. This might not be necessary, trigonometry can easily be done in fixed-point math.

• Would matrix math have an edge on the Cortex-M4F? (in case i venture there, prototyping) – Barry Staes Mar 13 '13 at 15:18
• Just to be a little pedantic - The Cortex-M4 processor core does not have an integrated DSP, it has a degree of DSP capability incorporated into its main processor core. The DSP extensions are the addition of multiply/accumulate instructions which facilitate typical DSP functions such as filtering and transforms. – uɐɪ Mar 13 '13 at 15:31

A few remarks:

1. You don't need to process the trigonometry operations on the same CPU that executes the obstacle avoidance. You can split the tasks between two microcontrollers and use a communication protocol to make them talk.

2. For an experiment I've implemented an AHRS algorithm with a Kalman filter in an ARM Cortex M0 microcontroller (it was an STM32, don't remember exactly the rest but I think it was 32 MHz), and using fixed point math I could run it at about 40 samples/second. With a faster controller you should be able to carry it easily, and of course you can try the FPGA or DSP way.

3. I'd say that the control of the legs is not CPU-intensive and you can control all the legs together, maybe separately from the trigonometry and obstacle avoidance operations (see 1)

• Servos are controlled serial via controller or dynamixel bus, so thats basically ofloaded already. The problem is the software needs to do way more inverse kinematics calculations than just required for the live pose/gait. – Barry Staes Mar 13 '13 at 15:22

Trigonometry is tricky, but there are shortcuts. If you are light on processing power, consider the CORDIC algorithm.

It's basically a table of values for [for example] sine. The angles can be in degrees, radians, whatever you like. The point is, the SINE of these values are 1/2 (0.5), 1/4 (0.25), 1/8, 1/16..... to whatever fraction of a degree your robot can use.

Input your angle, subtract the first table value, set your result to first result (0.5). If, by subracting, your angle became negative, then ADD the next value (and subtract 0.25). Otherwise, continue subtracting angles and adding results.

When you get to the end of the table, all you have done is add & subtract yet you're mighty close. There's a final "fiddle factor" to multiply by.

The accuracy [and speed] of the result depends on the size [and resolution] of the lookup table.

• CORDIC looks nice but i'll only use it if it makes the robot faster (thats a requirement). – Barry Staes Mar 13 '13 at 15:25

You may consider using a Raspberry Pi board that runs a general purpose GNU/Linux system. The Raspberry Pi has several GPIO pins that can be used to connect robot servos or extension-boards.

http://www.youtube.com/watch?v=RuYLTudcOaM

The model A Raspberry Pi can do up to 24 GFLOP's of general purpose floating point compute using its GPU using OpenGL ES 2 while remaining under 2.5W power-budget.

http://elinux.org/RPi_Hardware

Example: a battery powered robot setup implemented using the Raspberry Pi.

http://www.homofaciens.de/technics-robots-R3-construction_en_navion.htm

Example 2: a 6 legged robot controlled by a raspberry pi:

http://www.youtube.com/watch?v=Yhv43H5Omfc

Example 3: a self balancing 2 wheel inverted pendulum robot controlled by a raspberry pi:

http://www.youtube.com/watch?v=n-noFwc23y0

For legged robot you can create some predefined leg moving sequences and "play them". Real-time obstacle avoidance can be done with light fuzzy logic implementation where everything is again in table format and all you need to do is to pick the right value from it and use it for defuzzyfication process.

Everything can be done in C on somehow faster processor like ARM7. I have tried it on AVR and failed, after spending a lot of time on transforming everything to fixed point arithmetics.

• Playing gait animations is exactly what i dont want. The algorithm i want to implement figures out what to do with its legs on its own, and that algorithm is why i need fast trigonometry. I lacked to make that clear in my question however. And seeing that so many chime in on this i'd be a wast to edit the question. I'll ask and be more specific, in due time. – Barry Staes Mar 14 '13 at 10:08
• In that case i would go for the servo leg system. Each leg has its own controller. Agent based approach. – Gossamer Mar 14 '13 at 14:56

Texas Instruments Stellaris platform has a floating point unit on board by default. Not sure if the 80MHz clocked ARM controller is fast enough for your application, but a LaunchPad development board is pretty cheap: http://www.ti.com/ww/en/launchpad/stellaris_head.html

It is programmable through USB, free toolchains are available for at least Windows and Linux, measures about 4 × 6 cm and has 30+ GPIO pins (if I counted correctly).

You can embed x86 power pc CPU board into your robotic application with the help of AVR to control the drives of the robot as an interfacing card. The fastest and cheapest solution of your problem. But yes you have to mess a lot of coding into x86 architecture, but fortunately you can grasp lot of coding from open source OS codes. (If your mechanical construction can bear this weight)

• "x86" and "power pc" are two entirely different (and at least at some points in history) competing architectures. – Chris Stratton Mar 13 '13 at 15:09