Interfacing Dynamixel Motors using C based usb2dynamixel sdk

Recently, I got my hands onto a Bioloid Kit ( yes the small humanoid robot from http://www.trossenrobotics.com/bioloid-comprehensive-robot-kit.aspx ). The kit consists of about 18 amazing AX-12 dynamixel in addition to the other lego-like plastics and a CM-510 controller.

In this post, I'll talk you through interfacing the AX-12 series motor directly to a computer via a usb2dynamixel dongle using the usb2dynamixel's C sdk. So, whats the big deal about dynamixel motors?

Dynamixel motors are similar to traditional servo motors as they both are position-based motors. ie. you can specify the absolute angle the motors have to turn to instead of the more traditional velocity based motors where you specify the angular velocity. But, that's where their similarities end.

The dynamixel motors allow far greater control over how the motors move with approx 50 variables to play with from the more obvious goal frames to max allowable torque, moving speed, present load, present temperature, etc. For more info checkout the specifications pdf

http://www.robosavvy.com/RoboSavvyPages/Support/Bioloid/AX-12(english).pdf

These dynamixel motors can be manipulated from a computer directly using a usb2dynamixel dongle (comes along with the kit).

For linux and windows there exists a C based usb2dynamixel sdk that allows communication with the device. Here's the link to download page

http://support.robotis.com/en/software/dynamixel_sdk/usb2dynamixel/usb2dxl_linux.htm

Before you click the link above and close the tab to this blog let me warn you - "Interfacing the dynamixel motor is not that straight forward as it may seem". I ran into a lot of trouble ignoring the web and trusting my stupid instincts (hey wait a sec, don't be a saint. I bet u've done the same and that's landed you on my blog).

Lets get to the usb2dynamixel dongle interfaced first. This interfacing is independent of the motors. On my ubuntu 10.10 (64-bit) the interfacing worked out of the box. Just lsusb in your terminal and you should see the device detected. This is it. If you run the sample Read-Write example on the usb2dynamixel sdk, it should read success on detecting the dongle. There have been some issues on this front on other OSes (speed of usb driver will have to be changed to work @ 1Mbps through recompilation of the drivers).

Next, lets work out the wiring of the AX-12 motor. The AX-12 motors can be daisy chained (google it for more info). So, multiple motors can be connected through a single dongle. For sake of simplicity of wiring we shall use only one motor for now. Connect the AX-12 via the TTL slot (3-pin socket - specific for AX-12 series). Make sure u select the TTL using the 3-way switch.

Then, you need to power up the motors. This was a source of trouble for me. These motors draw upto 900 mA of current, hence you cannot power them through the usb dongle. Each motor has two 3-pin sockets. One of them will be used to connect to the dongle. The other can be used to power the motor.

I used the 12 V battery that came along with the kit. You could use anything from a 6 V to a 12 V to power up the motors. Then read the info on page 9 in the following pdf

http://www.crustcrawler.com/electronics/USB2Dynamixel/docs/ConnectingAX12toUSB2Dynamixel_Rev0.1.pdf

by John Raffensperger. It contains the pin connections required to power the motor. On powering up the motors, the red LED on the AX-12 should blink and then go off. Make sure you spend some time figuring the cablework to connect the motor to power supply in a neat fashion.

This concludes the wiring of the motor. The motor is now ready to be controlled via the Read-Write example in the sdk. You, however, need to recompile the code after changing the DEFAULT ID in the ReadWrite.c file from "1" to that of the motor connected.

On execution, the motor should turn through 300 degrees. Thats it.

In the next post, I will submit a simple ROS driver module that shall allow control any number AX-12 (daisy chained of course) through ROS services.

A web architecture for ROS

Lately, I have been working on a new architecture for shifting ROS onto the web. Its critical that this problem is given due diligence.

Before I jump into the solution to this problem, lets list out what we expect from this architecture.

1. We want to access to the robot from anywhere over the internet. 
2. Critical maintenance of the robot should be possible from a remote site.
3. Easy intuitive user interface which is also easy to develop and debug
4. Consistency in the UI.
5. Minimum latency overhead on the server side to transfer data to and from the ros sub-system.
6. Freedom to use any server-side programming language.
7. As software development becomes very complex for a robot, distributed development should be facilitated. ie. minimum interdependencies b/w the various teams developing the features.
8. Granulate the server side like ROS nodes and facilitate the inter-communication b/w each of those nodes.

Problem 1:
        Set up a web server on the internet that listens to get requests and somehow publishes relevant data to the ROS sub-system. If the web server is on the same local network then publishing is rather easy. The solution which addresses this problem may use CGI.

        Setup ROS on the web server. We will be creating ros packages on the webserver that shall process GET requests from the webserver and communicate with the robot like any other node communicating over multiple manchines. For more info on setting up ROS over the network refer to the following documentation:

                 http://www.ros.org/wiki/ROS/Tutorials/MultipleMachines

        Simple apache configuration can setup the webserver for CGI.

Problem 2:
        A simple ssh to the robot is sufficient in case the robot is visible over the internet. Otherwise, make a simple web based terminal, that forwards all input characters and executes it on the robot. Use ssh keys for security.

Problem 3:
       There are many front end UI toolkits like yui, gwt that can address this problem. I have chosen GWT ( Google Web Toolkit ). GWT sdk is an amalgamation of GWT compiler (which compiles java code to javascript) and AppEngine that runs java servlets on the cloud. You can ignore the latter as we intend on using CGI as our server side programming technology.

          One thing we need to understand about GWT is that it is only a client side technology, that can be connected to any server side technology like servlets, php, CGI, etc.

          I initially thought of using AppEngine on the server side (as it comes default with the SDK) to create servlets and communicate to the ROS subsystem directly from the servlet. AppEngine is a java based server programming technology that is meant for the cloud. Although there is a rosjava package that allows creation of java packages that can communicate with ROS, its useless in this context as google programmers have enforces a security protocol on the api that blocks JNI (used in rosjava). I even tried creating a socket network b/w the servlet and a backend stub that would communicate with ROS on its behalf. But even sockets are blocked. You can see the faq of AppEngine for more info.

          So, that leaves us with a CGI based server side programming technology. I used ajax requests to communicate to the CGI code.

          In GWT, the front-end UI is written in java and then compiled to javascript. So, debugging is a breeze. Also, the use of GWT Composites ensures a high degree of abstraction required for the distributed development.

Problem 4:
       The usage of GWT ensures consistency in the UI. Since, modules have their views as independent GWT composites they do not have a code dependency on other modules.

Problem 5:
       Usage of a same ROS node as a CGI node means that no more additional hops have to take place before the communicating to the ros subsystem. However, the latency in communication with the end-user is a point of concern. This is frankly outside our scope.

Problem 6:
        The CGI based server side technology means a host of languages are supported. However, only C and python are currently supported by ROS. That's a restriction.

Problem 7 & 8 :
        ROS nodes on the server side ensure that we can use messages to communicate between nodes on the server effectively sharing processing. These nodes may behave like services and create a pseudo service oriented architecture.

         For eg: A login node may have its own private DB that stores login info of all clients. Every other node may make use of this login service to authenticate the user.

Sample Scenario:
        Lets consider a sample scenario, of addition of a new module on a robot -- Flickr node. This node takes pictures from the robot camera and uploads onto a flickr site.

         For this, we shall create a flickr node on the robot that subscribes to the webcam driver and also subscribes to a "CaptureAndUpload" topic. The "CaptureAndUpload" topic gets a message when a remote user over the web wants a pic to tbe taken. In the callback function, for the "CaptureAndUpload" topic we shall use the flickcurl library to actually upload to flickr.

          For the client side UI we shall intuitively create a GWT module which has a Composite (containing a GWT button). We shall write a simple onClick handler for this button, that shall send an XMLHTTPRequest to a server side CGI node to take a pic. All this is written in java (or a pure GUI designer - Window Builder) and debugged and then finally compiled to javascript.

          On the webserver, the ROS+CGI node on receiving a request publishes on the "CaptureAndUpload" topic to take a pic.

          This shows a sample scenario where a development team can develop and end-end solution to the requirement of a flickr node without any knowledge of the rest of the modules on the web server.

This model has been tested to work.

ROS web interface

ROS comes with implementations of a lot of complex algorithms something that the entire open source community is grateful about. In ROS terminology, these are known as stacks.

Lately, the people @ willowgarage have been investigating pushing the user interface access of the PR2 to the web. For this, they have come out with the rosweb interface stack.

                    


Rosweb interface installation is a quite simple. Follow the instructions from

                                     http://www.ros.org/wiki/webui

There's one problem with the rosweb interface. Its still under active development. The preview that i have downloaded doesn't quite do anything. Moreover, i haven't yet got their samples to work as well. It connects to the roscore and i can see some info about the roscore from the web but that's it.

The serverside programming is done using cgi. So, loads of languages are supported. However the api sdk released as part of rosweb interface which includes the webui restricts itself to C and python. The ui is handled by a template system called clearsilver ( hence, the presensce of .cs files ) whose api is only in C and python. Thats perhaps the cause of the restrictions.

Also, the people @ Willowgarage have not yet openly discussed the architecture they wish to be put in place, especially when they want to answer to the problem of scalability ( incase they want to give access to multiple robots from a remote locations ).

Overall, I'm not quite impressed with the current release, as I've haven't got to make any use of this stack.

So, that got me thinking and I have decided to come up with my own version of the ROS web interface, one that goes a long way from just being an interface to a robot to explaining an overall web architecture for robots.

ROS - webcam support

This is for all those opencv fans, who plan to use ROS. ROS believes in a distributed architecture. This is great from a software developer's perspective as feature development can be precisely segmented.

So, how does this model affect poor opencv developers who use unsharable hardware like a webcam. Traditionally, all opencv developers test their image/ video processing codes as separate projects for each feature. This surely helps when you have to split certain complex investigations between diverse teams. Once, investigations prove successful, the gruesome task of integration pops in.

In ROS terms, this would mean separate ROS packages for investigation of each feature. However, during integration running them as separate nodes on the same physical machine would require hardware like webcams to be shared across each node. Attempting to access the webcam through standard opencv functions would be -- "Success" for one node, "Resource busy error" for others.

So, that's where intelligent people @ ROS decided to come up with usbcam driver nodes to publish camera frames using the ROS, so all that each feature node has to do is to subscribe to this driver's topic and each node will be able to get the same camera's feed.

What's the flipside? Different opencv feature nodes cannot modify crucial properties of the camera like capture resolution, framerate,.... There is one driver which is launched with a specific property set and thats it. All nodes have to abide by the set property ( Take what you get ).

There are several such webcam drivers in ROS. Some of them get installed as the camera_drivers stack. Those are mostly the advanced drivers that are mostly used in the PR2. For poor souls like me, who can't afford the PR2 to get live feed, there's the bosch driver packages (just google it) that comes with the usb_cam driver. This allows connectivity with most popular webcams (Anything that works with your google chat, yahoo chat, ....)

In 64 bit ubuntu 10.04 i had some problems compiling the usb_cam drivers. Some minor bugs that can be cleared by just literally doing what the error messages ask you to do. Any issues with the compilation, jst post it in the comments section.

That's it, in the ROS world where everything is distributed... make sure you don't access unsharable hardware without a driver. If none exist, write a simple node that broadcasts minimally processed data from the hardware (that's your driver).

Robot Operating System - Installation

This is my latest play tool. I've been working with ROS for about 2 months now. Heard about this great meta-operating system (as it is called by its creators) from a friend @ work.

Installation of this massive library was rather uneventful (thank god!!!) on my Ubuntu 10.04 machine (back then). Just followed the ros wiki site blindly.

                  http://www.ros.org/wiki/cturtle/Installation/Ubuntu

I recommend usage of the ppa for all future package management through the Software Center.

ROS has got by far the best support for this os. So, i truly recommend usage of Ubuntu 10.04.

My ROS installation however ran into few problems when i upgraded to the latest Ubuntu 10.10. ROS.org doesn't as of yet support this OS if upgraded from 10.04 (ROS installation may break on upgrade) . However, i've found their latest build on their svn repo to support it (OOOohoooo) !!!. If installed using the svn repo, u will however not have any support from the ubuntu software center w.r.t the ros package management (pretty obvious stuff).

Introductory Post

There's a lot to blog about in this world, but, in this blog I'll be investigating several software libraries that I've come across during either during my work hours or just as hobby investigations. 

My areas of interest include computer vision, augmented reality, robotics.

I hope these blog entries will benefit all those software developers who have killed most of their precious time fixing broken installations of new libraries.