A note on tan(x)

So jumping way ahead of myself here, but I thought I'd write a practical note on trig functions on a microblaze. There are tons of notes and source codes out there, so I'll keep it to just the high level ideas.

The problems:

1. Including math.h and tan(x) into your code takes about 14KB of code space. When your total is 64KB, this is a problem.

2. Running tan(x) 90 times takes about 10 seconds on a microblaze. That is, each angle calculation takes about 100ms, or to populate a look up table at the start of your program will take a long time, even for just 1 degree resolution.

My solution:

I wrote a java program that wrote a look up table for me. I decided on 1 degree resolution, and had the program output me a list of array values complete with assignment statements and semicolons. In the end I could copy and paste this into my c code:

tanLUT[1] = 0.0174

tanLUT[2] = 0.0349

...

Next I wrote a function in C that took my ratio (opposite over adjacent) and did a binary search on the LUT, comparing my ratio to the LUT values. While a more sophisticated search would be necessary for a larger table, it was fine for mine (especially since tan is monotonically increasing over the range 1-89 degrees).

Finally, to save on calculation time, I decided to use fixed point representation for all my numbers. To do so, I multiplied my LUT values by 1000, and my ratio by 1000. This meant I could use integer calculations which are much faster than floating point calculations with almost no extra effort.

Huge savings in both code space and access time, and it took me less than an hour to implement (fairly junior programming skills).

Other solutions:

A quick look on the net will give you some more ideas of how to implement trig functions on an embedded platform. Your decision will depend on the necessary accuracy and speed requirements

- Polynomial approximation. Can be single, or multiple polynomials over the range

- Huge LUT computed at run time

- LUT with linear or polynomial interpolation

The system

Now time to introduce the overall system. Surprisingly I am including a diagram that I drew before I even started writing hardware, and it is still valid.

System Block Diagram

The FPGA is a Virtex 2P, on a Xilinx University eval board. Most of our peripherals are standard (memory, pushbuttons, LEDs, UART) but we also have a custom core which is a controller for the ADC we are using. External to the eval board we have a 6 legged robot with 18 servo motors controlled by an SSC32 servo controller. This communicates with our board via RS232.

We have analog Sharp IR distance sensors, which connect to the ADC128s102. This ADC runs between 8 and 16 MHz (12.5MHz is currently a nice division of our system clock), and has 8 channels. Our custom controller is responsible for providing a clock, clocking select bits in and data bits out, as well as providing a Chip Select signal to control the device's operation.

Robots need love too.

The idea here is to take a 6 legged robot and make it climb slopes. An FPGA will interface to the robot controller (SSC-32, off the shelf robot) using RS232. Additional IR distance sensors will be added to the robot and mounted on a servo-motor. This allows them to rotate and locate objects.

The robot will scan the area, locate a ramp, move to an appropriate position and climb the ramp. The IR sensors will help it locate the ramp, and the FPGA will generate movement trajectories to move the robot to the ramp and climb up.

The FPGA has both a hardware and a software component. The IR sensors are connected to an external ADC, which clocks select lines in and data out at between 8 and 16 MHz. This is convenient because we can get up to 8 channels of data onto the FPGA using only 4 pins. We send it a clock signal, enable signal and serial select lines, and it feeds us 12 bits of digital data representing the current IR sensor output voltage. The data is filtered using a low pass (moving average) hardware filter, and then sent via FSL (Fast Simplex Link) back to the Microblaze processor.

Our software is responsible for controlling the robot. We store off-line generated trajectory tables for standard movements (rotate 10 degrees, move 3 cm etc.) in DDR memory, and then retrieve them when necessary. The required movements are determined by the data retrieved from the sensors. The sensors can scan the area, locate the angle of a nearby ramp and determine the distance to that ramp. This provides the required information for the trajectories to be generated.

The Why

Its simple really. There are 2 reasons.

Reason 1: Here I am, 2 weeks from the end of my FPGA project class and I know that I have to write a final report. And, as all school projects go (for me anyway), most of the work will be done in these next 2 weeks. So I'll document it all, share it with the world, and save myself time later when I am writing the final report.

Reason 2: VHDL takes a long time to synthesize. What better use of that time than to check the news and write blog posts about my robots!