Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

Controling AX12 from Linux through FTDI shorting RX and TX

Bioloid robot kit from Korean company Robotis; CM5 controller block, AX12 servos..
4 postsPage 1 of 1
4 postsPage 1 of 1

Controling AX12 from Linux through FTDI shorting RX and TX

Post by limor » Wed Jun 22, 2011 7:46 pm

Post by limor
Wed Jun 22, 2011 7:46 pm

We did a little experiment today and managed to get a PC to control the AX12 servos using a 3.3V FTDI board by shorting the RX and TX pins.
We wanted to check that AX12 servos respond to 3.3V signal.

The conclusion is that this trick does work and allows for a very cheap and simple for PC - AX12 communications. The only thing to notice is that when sending out a packet from the PC, it will be read back on the PC since the TX and RX are shorted.

Used a great package to test this called tekkotsu.org from Carnegie Mellon which includes also a useful tool called dynamixel_util

<pre>

gato@gato-laptop:/usr/local/Tekkotsu/tools/dynamixel_util$ ./dynamixel_util
Usage: ./dynamixel_util [options] set (ALL|<src_id>) <dest_id>
./dynamixel_util [options] scan [<id>|<range> ...]
./dynamixel_util [options] perf [sync] [save <file>] (<id>|range ...)
./dynamixel_util [options] baud (rate | divisor) <x>
./dynamixel_util [options] read <id> [ <start> <end> ]
./dynamixel_util [options] write (ALL|<id>|<range> ...) <addr>=<value>[ <value> ...]
./dynamixel_util [options] move (ALL|<id>|<range>) <pos> [<speed>]
./dynamixel_util [options] relax (ALL|<id>|<range> ...)
./dynamixel_util [options] conf

set: change the ID value of specified servo(s) to <dest_id>. If ALL is
specified as the source, the command will be broadcast, and affect
all connected servos. Otherwise a single servo can be specified to
reassign its ID without affecting any others which may be connected.

scan: the program will attempt to ping each of the specified servos,
where each argument is an ID or an inclusive range 'm-n'. If no
arguments are specified, it will scan the entire valid range (0-253).

perf: Benchmark performance testing, attempts to read and write from
specified servo(s) as quickly as possible until enter is pressed
or stdin is closed, then reports statistics.
If the 'sync' option is specified, a sync_write command will be used
instead of writing to each servo individually.
The 'save' option will cause raw sample data to be saved to the
specified file. The first line will be cycle end times, second line
will be read latencies, and third line will be write latencies.

baud: Sets the baud rate or divisor to the specified value for all
connected servos. Baud rates must be within 3% of a divisor,
as defined by: RATE = 2000000 / (DIVISOR + 1)

read: Dump all registers for the specified servo, optionally specifying
beginning and ending register addresses (inclusive).

write:Stores a value at the specified address for each of specified servos.
If multiple values are provided, they will be written to subsequent
registers.

move: Send a position command to specified servo(s). If the position
argument is negative or has a leading '+', it will be interpreted
as relative to the center of motion; otherwise absolute CCW position.

relax:Sends a torque disable command to specified servos.

conf: displays the current configuration settings and then exits

OPTIONS
-r,--read <file> Reads configuration settings from <file>
-w,--write <file> Writes final configuration settings to <file>
(If <file> is 'default', saves at path below)
-c,--comm <commport> Choose a comm port (defaults to SerialCommPort)
<key>=<value> Assigns a new value to a configuration setting
(overrides any settings read from file)

The setting file will store the comm port type. If you specify a new
type with --comm, it will overwrite the previously read settings with
the defaults for the new comm type.

Default configuration settings are read from:
~/.dynamixel_util.plist

COMMPORTS
Available comm ports are:
ExecutableCommPort FileSystemCommPort NetworkCommPort RedirectionCommPort SerialCommPort
gato@gato-laptop:/usr/local/Tekkotsu/tools/dynamixel_util$
</pre>
We did a little experiment today and managed to get a PC to control the AX12 servos using a 3.3V FTDI board by shorting the RX and TX pins.
We wanted to check that AX12 servos respond to 3.3V signal.

The conclusion is that this trick does work and allows for a very cheap and simple for PC - AX12 communications. The only thing to notice is that when sending out a packet from the PC, it will be read back on the PC since the TX and RX are shorted.

Used a great package to test this called tekkotsu.org from Carnegie Mellon which includes also a useful tool called dynamixel_util

<pre>

gato@gato-laptop:/usr/local/Tekkotsu/tools/dynamixel_util$ ./dynamixel_util
Usage: ./dynamixel_util [options] set (ALL|<src_id>) <dest_id>
./dynamixel_util [options] scan [<id>|<range> ...]
./dynamixel_util [options] perf [sync] [save <file>] (<id>|range ...)
./dynamixel_util [options] baud (rate | divisor) <x>
./dynamixel_util [options] read <id> [ <start> <end> ]
./dynamixel_util [options] write (ALL|<id>|<range> ...) <addr>=<value>[ <value> ...]
./dynamixel_util [options] move (ALL|<id>|<range>) <pos> [<speed>]
./dynamixel_util [options] relax (ALL|<id>|<range> ...)
./dynamixel_util [options] conf

set: change the ID value of specified servo(s) to <dest_id>. If ALL is
specified as the source, the command will be broadcast, and affect
all connected servos. Otherwise a single servo can be specified to
reassign its ID without affecting any others which may be connected.

scan: the program will attempt to ping each of the specified servos,
where each argument is an ID or an inclusive range 'm-n'. If no
arguments are specified, it will scan the entire valid range (0-253).

perf: Benchmark performance testing, attempts to read and write from
specified servo(s) as quickly as possible until enter is pressed
or stdin is closed, then reports statistics.
If the 'sync' option is specified, a sync_write command will be used
instead of writing to each servo individually.
The 'save' option will cause raw sample data to be saved to the
specified file. The first line will be cycle end times, second line
will be read latencies, and third line will be write latencies.

baud: Sets the baud rate or divisor to the specified value for all
connected servos. Baud rates must be within 3% of a divisor,
as defined by: RATE = 2000000 / (DIVISOR + 1)

read: Dump all registers for the specified servo, optionally specifying
beginning and ending register addresses (inclusive).

write:Stores a value at the specified address for each of specified servos.
If multiple values are provided, they will be written to subsequent
registers.

move: Send a position command to specified servo(s). If the position
argument is negative or has a leading '+', it will be interpreted
as relative to the center of motion; otherwise absolute CCW position.

relax:Sends a torque disable command to specified servos.

conf: displays the current configuration settings and then exits

OPTIONS
-r,--read <file> Reads configuration settings from <file>
-w,--write <file> Writes final configuration settings to <file>
(If <file> is 'default', saves at path below)
-c,--comm <commport> Choose a comm port (defaults to SerialCommPort)
<key>=<value> Assigns a new value to a configuration setting
(overrides any settings read from file)

The setting file will store the comm port type. If you specify a new
type with --comm, it will overwrite the previously read settings with
the defaults for the new comm type.

Default configuration settings are read from:
~/.dynamixel_util.plist

COMMPORTS
Available comm ports are:
ExecutableCommPort FileSystemCommPort NetworkCommPort RedirectionCommPort SerialCommPort
gato@gato-laptop:/usr/local/Tekkotsu/tools/dynamixel_util$
</pre>
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by i-Bot » Wed Jun 22, 2011 11:09 pm

Post by i-Bot
Wed Jun 22, 2011 11:09 pm

While this may work under some conditions, I see 3 problems which may lead to unpredictable behavior:

1) the FTDI Tx output is totem pole so the servo Tx will be driving against the 3.3V output from the FTDI when the servo replies. The servo will most likely win, but with much reduced voltage margin and larger current spikes.

2) the servo drives its output levels to +5V, which is outside the max input level of the FTDI 3.3V board. This should not cause damage due to the series resistor in the servo, but it will make noise on the 3.3V supply on the FTDI as the protection diode lifts it.

3) The FTDI output at 3.3V does not meet the high level input voltage specification of the HC receiver in the servo. So more noise prone.
While this may work under some conditions, I see 3 problems which may lead to unpredictable behavior:

1) the FTDI Tx output is totem pole so the servo Tx will be driving against the 3.3V output from the FTDI when the servo replies. The servo will most likely win, but with much reduced voltage margin and larger current spikes.

2) the servo drives its output levels to +5V, which is outside the max input level of the FTDI 3.3V board. This should not cause damage due to the series resistor in the servo, but it will make noise on the 3.3V supply on the FTDI as the protection diode lifts it.

3) The FTDI output at 3.3V does not meet the high level input voltage specification of the HC receiver in the servo. So more noise prone.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by limor » Fri Jun 24, 2011 1:08 pm

Post by limor
Fri Jun 24, 2011 1:08 pm

Thanks!
Points well taken.
So if the FTDI is for 5V there should not be any issues?
Thanks!
Points well taken.
So if the FTDI is for 5V there should not be any issues?
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by i-Bot » Fri Jun 24, 2011 1:50 pm

Post by i-Bot
Fri Jun 24, 2011 1:50 pm

The 5V FTDI resolves my points 2 and 3.

For the TX output a tristate driver is always best, but many of the low cost FTDI cables and boards do no bring out the TXDEN pin to control the direction. If you can get access to the TXDEN, then an HC126 (DIP) or an NC7WZ241(SMT) can be used as a tristate driver/receiver. This also stops the receiver getting the transmit stream back.

If you cannot get acces to TXDEN, then a diode on the output from TX followed by a pullup to 5V is a pretty good alternative, except maybe for long cables with fast baud rates.

Watch out that some cables and board have 3.3V logic levels, but 5V Vcc output.

Most of the Robotis utilities which talk direct to servos require an FTDI based serial converter and will not work with other USB serial chips. The other serial chips work fine wth Robotis software which talks to CM5/510.
The 5V FTDI resolves my points 2 and 3.

For the TX output a tristate driver is always best, but many of the low cost FTDI cables and boards do no bring out the TXDEN pin to control the direction. If you can get access to the TXDEN, then an HC126 (DIP) or an NC7WZ241(SMT) can be used as a tristate driver/receiver. This also stops the receiver getting the transmit stream back.

If you cannot get acces to TXDEN, then a diode on the output from TX followed by a pullup to 5V is a pretty good alternative, except maybe for long cables with fast baud rates.

Watch out that some cables and board have 3.3V logic levels, but 5V Vcc output.

Most of the Robotis utilities which talk direct to servos require an FTDI based serial converter and will not work with other USB serial chips. The other serial chips work fine wth Robotis software which talks to CM5/510.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am


4 postsPage 1 of 1
4 postsPage 1 of 1