Robot Arm II - phase 2

Phase two of the construction of the robot arm will follow on from the initial research stage, phase 1. Here are the results of the testing and investigation I have undertaken.

There were a few key areas that I wanted to investigate:-
Host controller
Software for host controller
Hardware Interface methods
Hardware driver electronics
Calculations of servo torques and motor suitability

Host Controller
I was investigating the use of a Gumstix board for controlling the hardware, and acting as both an independant controlller, and a slave controller. I also investigated using a cypress FX2 chip as a bridge interface, but this did not work out too well. After discounting the FX2 for it's speed constraints, I was left with the Gumstix. I believe the gumstix is the best tool for the job, as I noted in phase 1 it has a lot of IO capabilities.

What I learned about gumstix:-
The platform is very flexible, being based on Linux. The Gum is very fast, and can easily handle multiple interface methods simultaneously. There is lots of space to play with on this platform. It's as good (if not better) than a PC.
After writing the interface API for the servos (detailed below) I wrote a simple ethernet to I2C wrapper. This enabled me to control the virtual robot in real time with a simple KDE interface. The platform still has enough power available to do the IK and state machine calculations.

Software for host controller
The host controller (gumstix) runs a standard Linux OS based on busybox tools. This enabled the simple creation of an API and a wrapper. Once the API was in place to control the servos, I was able to write a simple TCP/IP server. This server has all of the features exported through either "function_name param1 param2" of a binary mode which enables faster communication.

Hardware Interface methods
Although I2C is used to control the servos, there is the possibility of using I2C as an input method too. This would make the Gumstix host a full I2C passthrough/translator.

As stated above I have addedd TCP/IP functionality into the code, allowing for internet communication.

This mode is not enabled yet,, but I have made provisions for the serial input. The interpreter library will handle and parse the same information as the TCP library, but will fill in fake descriptor information.

Hardware Drivers
The main system is running off of the OpenServo platform. as previously noted, the OpenServo allows great flexibility in the system, and allows most of the hard CPU work to be distributed to a smaller controller.
The small end effectors of the robot arm are using stock OpenServo 2x boards (my version from CVS) and the larger motors are using a driver of my own design. You can see the schematics and PCB's for these driver boards.
This board has a dual I2C selector, and also a BCD display. This is useful to toggle between all of the registers in the OpenServo, and display their states.
These boards can be connected together independantly using a cable, or to the bus board driver.

To power the whole rig I has created a very high current regulator FET board. There are 2x 5v regulated outputs from this board, although they are not entirely isolated. One of the outputs can supply in the range of 5A peak, and is used for the MCU power, and there is an additional 15-20A output for general purpose use (I was going to use it for the end effectors, but the induced noise is unbearable). This board has it's own onboard MCU to manage all aspects of the current regulation, chip temperatures, and current flow. This board does not connect into the busboard's ISA slots, but to the general power sockets on there.

Latency is a big issue here. I have to be very careful at every stage in the design that I do not introduce any latency. If there is a large latency i the system, I would be looking at potentially old data, and with the speeds that this is capable of, we are talking about a danger factor of 10.

Here are the segments where latency is, and how I have tried to minimise it.


Latency between the servos and controller are the major issue. Is there are multiple position corrections that need to be made, the bus can become swamped pretty quickly. As each read/write request is processed, the controller blocks. This means large reads can cause problems.

In my OpenServo API library I have created functions to calculate the most efficient means of getting the data requested from the servo. There are now indirect reading functions that will return (possibly old) data that is not important to the system at that point. These help the I2C bus from blocking for too long.

Controller to host latency is very minor. The only real issue here is how long the controller takes to interpret and parse the information. This has been reduced by using a binary interpreter. It's quick.


Main Content: 



You should seriously consider using emc2 as your controller. Although it is most known for it's real time control of stepper motors and servos it is much more powerful than that. And could *very* easily be adapted for open servos as well. The benefit of using emc2 is that it already uses the realtime api (either of the two available), it already has IK integrated, and it was developed to be adaptable to any machine control application.

Yesterday I modified my CNC driver config to add a 20$ xbox-style controller as a CNC jogger. Pretty easy, you can modify the main-loop programming in many ways to accomplish it. It was already done before, so almost a simple drop in, but I wanted a different button layout than the author, so learned a lot about emc2 under the hood. Joystick CNC control is so much better than using the keyboard...and is --so cool--!!!

Emc2 is basically a real-time hardware virtual-machine that knows nothing of the particular control application. You can code real-time loops yourself, load other user modules, link up these modules tieing inputs and outputs. In fact, someone made an Eagle schematics to Emc2 control file (hal file) to make it simpler to do so, but the text coding is easy enough for me. The "halrun" and "halcmd" command starts the hal daemon ready for input. You also have many tools that are like o-scopes, multimeters, and debuggers to help see what's going on.

There is an emc2 sample included that controls a robotic arm. Use gocde to control your robot's effector position, or through the hal daemon you can set the XYZ params directly.

Making a custom black-box module that communicates with the network or other device is simple like the openservos is easy. You can use C for user or (emc2-)kernel mode modules or python for user-space modules. (Here kernel modules refer to the emc2 realtime kernel, not the linux kernel.) The control application is built up of many modules that give you low level or high level access to all the hardware parameters/values and the user interface (if you use one).

The Axis (the UI) program simply communicates with the emc2 kernel like a python user mode module and is written in python. Using the interface is optional. I might in the future have a small box that runs linux without a screen, and the interface is viewed remotely over the network. The machine would still have digital read out controls.

I am also thinking about how emc2 (maybe customized/branched) would make a great start to the cubOS (projectborg) project as the IO layer for linux based devices since it is so configurable.

An interesting idea, and one

An interesting idea, and one I did briefly consider a few years back. At that time EMC was very young and didn't do what I needed. Time to revisit, expecially as they have examples.

My CNC machine is EMC2 powered, so I know enough about EMC to operate. Now it is time to check out what is going on under the hood!

Since I wrote the article, I went with OROCOS. It still provides the RTAI functionality, but is geared towards a more abstract approach to robotics applications. I posted my thoughts on OROCOS to the project borg forum, so I won't repoeat too much here. Simply: It is flexible, nice and fairly easy to use and now has good documentation. My only concern is how heavy it is. The codebase is pretty large (EMC2 is too) and tends to eat resources because of the task queue nature of the program.
I would still be more tempted to use something like OROCOS than EMC2, but let me look into the inner workings of EMC2 before I get back to you on that one ;)


Also, you should check out the Atmel AVR32AP NGW100 eval kit. It has a pretty fast 32bit processor that runs Linux with busybox tools. I just got one to make a glorified tape recorder (looks like a tape recorder but records to mp3/aac/speex on an SD card) and has network auto ftp-sync capability.

I just went through kernel hell trying to get buildroot setup and compiling my own kernel for the device. Would be the same deal as with the gumstix probably. My understanding of how buildroot works was the problem, but it works good now.

Yeah, I actually have one of

Yeah, I actually have one of them already. It is a very nice piece of kit but a little too large for my liking. My new toy is a Beagleboard. Smaller, faster, etc etc.

I see your AVR and raise you an ARM :)