TellDarwin - interactive text interpreter for Darwin-OP

[limor]

http://idealab.uga.edu/Projects/Darwin/Reference.php

TellDarwin is a command interpreter for DARwIn-OP Robot running Linux (designed and tested on Ubuntu 9.10). It was written by Michael Krzyzaniak at the University of Georgia, Ideas for Creative Exploration (ICE). It allows users to send simple, intuitive requests like

Code: Select all

start walking
set eye color 0.5 0.2 1
get accelerometer
start camera
set head position 30 degrees

to the robot wirelessly from a remote computer, and have it respond as expected. The software is intended to receive requests from Max/MSP (a graphical programming language for OSX or Windows that is popular in the humanities), but also has options that allow users to send requests from the command-line locally using the robot's stdin, or remotely with netcat (nc, available for any OS) or other software that can send simple ASCII messages over TCP. These options allow users to easily write scripts that control the robot.

phpBB [media]

[i-Bot]

It is very encouraging that folk are developing for DARwIn OP so quickly using the Robotis C++ framework. Especially since they are documenting well, and making source available of their work.

This software makes a significant link of DARwIn OP to a much wider creative community in a solid and simple way.

I have some technical questions why they used the CM730 class rather than motion manager to talk to the servos. I will contact author direct, but it would be great to get involvement and discussion through the forum.

I don't have Max/MSP, but have always thought it sets the standard for this type of interactive programming. Is there any good open source alternative ?

[siempre.aprendiendo]

Great! I think DSL will be a powerful tool for programming robots. Martin Fowler published some months ago a book about DSL and have a great DSL guide online.

[krzyzani]

Hi,

Thanks for your interest in my work. Your question is insightful and critical. I appreciate your scrutiny, and I will attempt to provide a sufficient answer.

The main problem is that Robotis' CM730 class is not thread-safe, but the MotionManager detaches a thread and polls the CM730 on that thread. Therefore, while the the MotionManager is running, any attempt to communicate with the CM730 on, say, the program's main thread will bungle the stream of bytes going between the main controller and the sub-controller, resulting in some kind of crash (the state-machine usually gets stuck waiting for bytes that are not coming). Of course, if you only want to move the servos, there would be no need to communicate with CM730 on the main thread. However, if, say, you want to change the color of the eyes, then your only option is to first kill the MotionManager. Worse is that the MotionManager only polls 2 axes of the accelerometer, but not the third, nor the gyroscope, and since these components are on the CM730, they are similarly inaccessible while the MotionManager is running. Therefore, I have chosen to bypass the MotionManager entirely. Even if such problems did not exist, I do not believe that any functionality could be gained by using the MotionManager directly (as the initial draft of TellDarwin, in fact, did). Furthermore, Darwin's battery-life is lamentably short. Polling the CM730 while the robot is not doing anything seems like a waste of electricity.

I hope this makes sense. If anyone sees a better way of doing things I am always open to suggestions.

Mike

[Fritzoid]

the MotionManager only polls 2 axes of the accelerometer, but not the third, nor the gyroscope, and since these components are on the CM730, they are similarly inaccessible while the MotionManager is running

The newer version(s) of the framework include the undocumented "bulk read" function. This feature allows you to create a customized list of control table entries (either CM730 or dynamixel) that are regularly polled. See function, CM730::MakeBulkReadPacket(). The results of the latest poll can be read by an external user as a single block from the controller memory. It's fast and it's flexible.

[i-Bot]

Hi Mike,
Thanks for the reply and also the information you provided in the "Do You Have Suggestions For How Robotis Can Improve Their C++ Framework?" I hope Robotis are reading this thread. I think they want to encourage the use of the framework, so should fix any shortcomings.

I do like the concept from Robotis of using MotionManager and Motion Status to multiplex and demultiplex the access to the robot, but as you say; it needs to work.

If MotionStatus doesn't publish complete information from the Darwin OP, it is not fit for purpose. Either all information should be published, or Motion Manager improved to allow subscribers to define the information they will require and have MotionManager provide it. Such a process could use the proposal from Fritzoid to intelligently optimise the reads from the CM730 and MX28.

You say "Robotis' CM730 class is not thread-safe", yet in CM730::TxRxPacket I do see waiting on semaphores. Is this broken ?

I do find the .enables, and their exclusivity and initialisation complex in MotionManager, also poorly documented; so can see why you dropped it if you only use the walking module. Do you not plan to use Action to execute Robotis motion scripts or files ? The jump straight to servo positions seems large, unless you plan to implement the motions in Max.

I hope Robotis also take note on the battery life issue. They seem to have been especially mean on both the batteries(capacity) and charger(slow). Hopefully with open hardware someone will soon fix this.

Thx.
Richard

[i-Bot]

Also interested in your allocation of X,Y,Z axes. I think Robotis already confused the situation with this :
http://darwin-op.springnote.com/pages/7331885
which seems to swap x and Y.

I tried to use the Robotis code as the basis of this:
http://robosavvy.com/site/index.php?opt ... 1&Itemid=2
But am now concerned I may be wrong, or that I should at least say the allocation of axes is arbitrary.

Not sure if it a big issue for anyone except me. I am spacially challenged !

[krzyzani]

Yeah, by my reckoning, Robotis employs many different coordinate systems. The servos, accelerometer, gyroscope and walking module each defines an X, Y, and Z axis that does not agree with the others. TellDarwin adjusts all of this so that all of the coordinate systems agree. Here, for instance, is how I get the the accelerometer and gyroscope to agree with the servos (taken from Performer.h):

typedef enum
{
//the accelerometer is mounted sideways.
ACCEL_X = CM730::P_ACCEL_X_L,
ACCEL_Y = CM730::P_ACCEL_Z_L,
ACCEL_Z = CM730::P_ACCEL_Y_L,
}accelComponent_t;

typedef enum
{
//the Gyroscope is mounted sideways.
GYRO_X = CM730::P_GYRO_Y_L,
GYRO_Y = CM730::P_GYRO_Z_L,
GYRO_Z = CM730::P_GYRO_X_L,
}gyroComponent_t;

This does not fix everything, because the sign convention is still wacky: sometimes positive X is, say, left, and sometimes right. So, elsewhere in the code there are statements like

if((component == ACCEL_X) || (component == ACCEL_Z))
*value *= -1;

which makes the coordinate systems more consistent and, at the very least, more intuitive to me, although what is "correct" may be debatable.

Does that answer your question?

[krzyzani]

Sorry to bombard this forum. By way of at least partial answer to an earlier post: I do not plan on implementing access to action scripts in TellDarwin. TellDarwin was designed, at least to some degree, to provide an alternative to 'action scripts', because I and the professor who asked me to write the software felt that MAX would be more powerful and more intuitive for non-engineering students. Coordinating a precise series of timed events is just what MAX was designed to do, and it does it quite well.

Also, I am curious to know if anyone has successfully compiled and run TellDarwin on their robot.

[siempre.aprendiendo]

No sorry, please. It's a very interesting thread.

[i-Bot]

Thanks for taking the time to describe your design, it is of help to me and hopefully others working at the low level of the Robotis framework.

I appreciate you probably now want to move on to working with Max/MSP. It would be interesting to see some of the Darwin motions from Roboplus running under Max/MSP for comparison.

Did you think to link also to a simulation environment such as Webots ?

Also it may be useful to implement inverse kinematics for the legs and arms to allow them to be moved by a simplified set of parameters, such as those used by Roboplus or by the IK part of the Darwin Walking engine. Maybe even use this IK with a gait generator built in Max/MSP ? It may be best to do the IK in MaxMSP to allow the Gyros to be mixed into the servo angles afterwards.

[limor]

I'm amazed at the musical world of MAX where analog gyros cost $175