cm-510 toss mode
cm-510 toss mode
by Lothar
Wed Mar 21, 2012 5:43 pm
Hello,
I have a problem with the toss mode of my cm-510. I wrote a program (Delphi) that sends commands via comport and USBDynamixel in a closed loop to the cm-510 in toss mode. It sends about 5 commands per second. It works fine for about 10 seconds, but then the cm-510 suddenly stops and doesn't react on any command, so I have to power off the cm-510.
In Ascii Mode everything works fine, the problem occurs only in toss mode.
has anybody a solution ?
I have a problem with the toss mode of my cm-510. I wrote a program (Delphi) that sends commands via comport and USBDynamixel in a closed loop to the cm-510 in toss mode. It sends about 5 commands per second. It works fine for about 10 seconds, but then the cm-510 suddenly stops and doesn't react on any command, so I have to power off the cm-510.
In Ascii Mode everything works fine, the problem occurs only in toss mode.
has anybody a solution ?
by PedroR
Thu Mar 22, 2012 1:44 pm
Hi Lothar
It is possible that you become out of sync with the robot. This is very unlikely (I imagine the Robotis firmware is very Robust) but it may be a possibility.
As a side note, can you point us to some more resources on CM-510 toss mode? I've heard a lot about it but we haven't tried it ourselves yet...
Do you know how deeply documented it is?
Regards
Pedro.
It is possible that you become out of sync with the robot. This is very unlikely (I imagine the Robotis firmware is very Robust) but it may be a possibility.
As a side note, can you point us to some more resources on CM-510 toss mode? I've heard a lot about it but we haven't tried it ourselves yet...
Do you know how deeply documented it is?
Regards
Pedro.
by Fritzoid
Thu Mar 22, 2012 6:39 pm
Here's my poorly formatted but annotated version of what the code would look like if some anonymous person had written it in (dis)assembler.
The comments may or may not express the intention of the programmer.
As you can see there's not much to it.
- Code: Select all
TossMode:
cbi PORTC, 2 ; 50E9 9842 Turn on Rxd LED
cbi PORTC, 1 ; 50EA 9841 Turn on Txd LED
ldi r16, 0xE9 ; 50EB EE09
ldi r17, 0x00 ; 50EC E010
rcall SendString2PC ; 50ED D2A0 Display "Toss Mode\n" message
TossLoop:
lds r16, 0x0EC5 ; 50EE 9100 0EC5
lds r17, 0x0EC4 ; 50F0 9110 0EC4
cp r16, r17 ; 50F2 1701 Any PC input ?
breq TossServoIn ; 50F3 F0C9 No, check for dynamixel input
cbi PORTE, 3 ; 50F4 9873
sbi PORTE, 2 ; 50F5 9A72 Set dynamixel bus for output
TossPCIn:
lds r16, 0x0EC5 ; 50F6 9100 0EC5
lds r17, 0x0EC4 ; 50F8 9110 0EC4
cp r16, r17 ; 50FA 1701 More input to read ?
breq TossWait ; 50FB F051 No, then go wait for a response
call GetPCByte ; 50FC 940E 10EC Get next byte from PC
call SendByte2Dxl ; 50FE 940E 0F99 Transmit byte on dynamixel bus
lds r16, UCSR0A ; 5100 9100 00C0
ori r16, 0x40 ; 5102 6400 Enable transmitter
sts UCSR0A, r16 ; 5103 9300 00C0
rjmp TossPCin ; 5105 CFF0
TossWait
lds r16, UCSR0A ; 5106 9100 00C0
mov r17, r16 ; 5108 2F10 Wait for last byte to be sent
sbrs r17, 6 ; 5109 FF16
rjmp TossWait ; 510A CFFB
cbi PORTE, 2 ; 510B 9872 Set dynamixel bus to input
sbi PORTE, 3 ; 510C 9A73
TossServoIn:
lds r16, 0x0AD1 ; 510D 9100 0AD1
lds r17, 0x0AD0 ; 510F 9110 0AD0
cp r16, r17 ; 5111 1701 Anything received from servos ?
breq TossLoop ; 5112 F2D9 No, go check PC side again
lds r16, 0x0AD1 ; 5113 9100 0AD1
mov r17, r16 ; 5115 2F10
inc r17 ; 5116 9513 Increment dynamixel buffer index
sts 0x0AD1, r17 ; 5117 9310 0AD1
ldi r17, 0x00 ; 5119 E010
movw ZH:ZL, r17:r16 ; 511A 01F8
subi ZL, 0x14 ; 511B 51E4 Calculate buffer address
sbci ZH, 0xF8 ; 511C 4FF8
ld r16, Z ; 511D 8100 Load byte from dynamixel buffer
call SendByte2PC ; 511E 940E 0FA1 Send byte to PC
rjmp TossLoop ; 5120 CFCD Loop around for PC or dynamixel input
The comments may or may not express the intention of the programmer.
As you can see there's not much to it.
by siempre.aprendiendo
Thu Mar 22, 2012 7:18 pm
You are great, Fritzoid 
As far as I know it's a very simple "feature": what you write to the serial port of the CM-5/CM-510 is sent to the Dynamixel bus, and all what is received from the Dynamixel is sent back to the serial port. You just need to use the Dynamixel protocol commands to send orders.
There is another simple "feature", MON (I think) for monitoring the Dynamixel traffic from the serial port.
As far as I know it's a very simple "feature": what you write to the serial port of the CM-5/CM-510 is sent to the Dynamixel bus, and all what is received from the Dynamixel is sent back to the serial port. You just need to use the Dynamixel protocol commands to send orders.
There is another simple "feature", MON (I think) for monitoring the Dynamixel traffic from the serial port.
by Fritzoid
Thu Mar 22, 2012 7:48 pm
There are two different monitor commands. One in the application and another in the bootloader. Each is slightly different.
Monitor is definitely a cool command but my favorite is RUN which allows you to single step through your running task code on the CM-510.
You can also use the H command to transmit hexadecimal commands to the dynamixel bus outside of toss mode. That means you can stay in manage mode with all the other commands still available. This is useful because once you get into toss mode there's no way back. The H command should not be confused with the HEX command which toggles hexadecimal vs. decimal command translation.
Monitor is definitely a cool command but my favorite is RUN which allows you to single step through your running task code on the CM-510.
You can also use the H command to transmit hexadecimal commands to the dynamixel bus outside of toss mode. That means you can stay in manage mode with all the other commands still available. This is useful because once you get into toss mode there's no way back. The H command should not be confused with the HEX command which toggles hexadecimal vs. decimal command translation.
by Lothar
Thu Mar 22, 2012 9:22 pm
Hi PedroR,
I think it might be a synchronization problem, too. First I just sended a sync write command with the positions of 14 actuators (AX12). You have to use the broadcast ID with the syncwrite, so the cm-510 doesn't response to the syncwrite. It ran very fast, about 30 times per second, but the actuators didn't move. After that I slowed the loop down by a timer to 5 times per second. Now the actuators moved perfect, but after about ten seconds they suddenly stopped. Next I tried to send a sync write followed by a read command forcing the cm-510 to reply. That also worked fine, but after ten seconds stop ! Seen from the comport side everything seems to be ok. The comport tells me the send buffer is correct sended, but after ten seconds there ar no more recieved bytes. I can not explicitely change the direction of the comport, I only can check if the sendbuffer is empty and if there are bytes i have to read.
resources : in robotis terminal (or hyperterminal or by a program in C,delphi or something like that) you enter 'toss' + return (#13). After that you are in the toss mode. From now you have to send commands as described in the robotis e-manual (Dynamixel->Communication->Instruction/Status Packet. Fritzoid is right saying there is no way back except powering off the cm-510. For example 0xFF means you don't send two characters with the value of 'F', you instead have to send a byte with value 255 decimal. Normally this is not possible with the robotis terminal. I hope this is what you wanted to know !
Regards Lothar
I think it might be a synchronization problem, too. First I just sended a sync write command with the positions of 14 actuators (AX12). You have to use the broadcast ID with the syncwrite, so the cm-510 doesn't response to the syncwrite. It ran very fast, about 30 times per second, but the actuators didn't move. After that I slowed the loop down by a timer to 5 times per second. Now the actuators moved perfect, but after about ten seconds they suddenly stopped. Next I tried to send a sync write followed by a read command forcing the cm-510 to reply. That also worked fine, but after ten seconds stop ! Seen from the comport side everything seems to be ok. The comport tells me the send buffer is correct sended, but after ten seconds there ar no more recieved bytes. I can not explicitely change the direction of the comport, I only can check if the sendbuffer is empty and if there are bytes i have to read.
resources : in robotis terminal (or hyperterminal or by a program in C,delphi or something like that) you enter 'toss' + return (#13). After that you are in the toss mode. From now you have to send commands as described in the robotis e-manual (Dynamixel->Communication->Instruction/Status Packet. Fritzoid is right saying there is no way back except powering off the cm-510. For example 0xFF means you don't send two characters with the value of 'F', you instead have to send a byte with value 255 decimal. Normally this is not possible with the robotis terminal. I hope this is what you wanted to know !
Regards Lothar
by Lothar
Thu Mar 22, 2012 9:58 pm
Hi Fritzoid,
I read your "anonymus" assembler code and more or less I understand what it means. I speculate I am sending to fast to the cm-510 in toss mode, but I don't know how to detect it. In the PC side I use Delphi and the communication functions as described in the Microsoft MSDN Library. The function "write file" returns a field "BytesWritten" indicating me the complete SendBuffer is written. The cm-510 seems not to refuse to read the bytes I send.
Can you shortly describe how to use the H command ? I already tested the HEX command, but it is as slow as the ascii mode and also limited to 60 characters per command.
Regards Lothar
I read your "anonymus" assembler code and more or less I understand what it means. I speculate I am sending to fast to the cm-510 in toss mode, but I don't know how to detect it. In the PC side I use Delphi and the communication functions as described in the Microsoft MSDN Library. The function "write file" returns a field "BytesWritten" indicating me the complete SendBuffer is written. The cm-510 seems not to refuse to read the bytes I send.
Can you shortly describe how to use the H command ? I already tested the HEX command, but it is as slow as the ascii mode and also limited to 60 characters per command.
Regards Lothar
by PedroR
Fri Mar 23, 2012 11:52 am
Hi Lothar
As a suggestion, I would place a small timeout between each sequence of commands.
For example: if you want to send a command that is - for example - 8 bytes long I would send it all at once and then put a "sleep" for a few miliseconds before sending another command.
In addition when sending our hypothetical 8 byte instruction, the efficient way to do it is to put all the bytes in a Byte Array and then send the Array at once (instead of sending the bytes one at a time).
I would imagine that because the Dynamixel bus is Half Duplex and the firmware needs to switch the direction of the communication, it gets a sequence of bytes and when it "sees" a pause, it assumes he's received the full command and relays it to the bus.
I am not sure if this is how it works though! just a thought and a suggestion.
From experience with controllers of other robots, we've learned the following:
1- adding a small pause between sending commands (usually 50ms~200ms) sometimes helps
2- reading back all the responses after sending a command is also important to get good results (even if you don't care about the return value )
(if you use 2) then the timeout in 1) is usually not needed)
Regards
Pedro
As a suggestion, I would place a small timeout between each sequence of commands.
For example: if you want to send a command that is - for example - 8 bytes long I would send it all at once and then put a "sleep" for a few miliseconds before sending another command.
In addition when sending our hypothetical 8 byte instruction, the efficient way to do it is to put all the bytes in a Byte Array and then send the Array at once (instead of sending the bytes one at a time).
I would imagine that because the Dynamixel bus is Half Duplex and the firmware needs to switch the direction of the communication, it gets a sequence of bytes and when it "sees" a pause, it assumes he's received the full command and relays it to the bus.
I am not sure if this is how it works though! just a thought and a suggestion.
From experience with controllers of other robots, we've learned the following:
1- adding a small pause between sending commands (usually 50ms~200ms) sometimes helps
2- reading back all the responses after sending a command is also important to get good results (even if you don't care about the return value )
(if you use 2) then the timeout in 1) is usually not needed)
Regards
Pedro
by Fritzoid
Fri Mar 23, 2012 12:17 pm
Lothar,
The timing is toss mode is more critical than in command mode (Ascii mode). In command mode the new line character serves to separate one statement from the next. In toss mode it is the user's responsibility to make sure that enough time exists between packets for all the bytes to be transmitted and for a possible response to be received. For a long syncswrite packet this can be a millisecond or more to transmit with no response expected.
It's also important that all the bytes in a packet be received by the dynamixels in a timely manner. Once the servo firmware starts receiving the bytes in a packet it sets a time-out value. If a new byte doesn't arrive within a certain time (can't recall the exact number) the packet is thrown out. This means that the controller must get all the bytes of a packet in a timely manner as well. The serial driver cannot afford to break the packet up into pieces.
To analyze this, and similar problems, you're gonna need to see what's going on at a lower level than C++. First you need to verify that the packets are being sent to the controller without breaks. For this you should use a serial port monitor. If the packets from the PC look good and the timing is OK then the next step is to monitor the data flow on the dynamixel bus. You can do this with your USB2Dynamixel in TTL mode.
Happy hunting!
The timing is toss mode is more critical than in command mode (Ascii mode). In command mode the new line character serves to separate one statement from the next. In toss mode it is the user's responsibility to make sure that enough time exists between packets for all the bytes to be transmitted and for a possible response to be received. For a long syncswrite packet this can be a millisecond or more to transmit with no response expected.
It's also important that all the bytes in a packet be received by the dynamixels in a timely manner. Once the servo firmware starts receiving the bytes in a packet it sets a time-out value. If a new byte doesn't arrive within a certain time (can't recall the exact number) the packet is thrown out. This means that the controller must get all the bytes of a packet in a timely manner as well. The serial driver cannot afford to break the packet up into pieces.
To analyze this, and similar problems, you're gonna need to see what's going on at a lower level than C++. First you need to verify that the packets are being sent to the controller without breaks. For this you should use a serial port monitor. If the packets from the PC look good and the timing is OK then the next step is to monitor the data flow on the dynamixel bus. You can do this with your USB2Dynamixel in TTL mode.
Happy hunting!
by Compadre
Fri Mar 23, 2012 3:02 pm
This make sense to me because i had been working for a while with matlab and bioloid in toss mode.
I calculate some walking routine (parametrized cartesian trayectories for pelvis and feet -> IK), generate a file with angles (in webots format .motion) and then i was sending this by serial port with cm-5 in toss mode.
[
http://www.youtube.com/watch?v=a6_-0hppdNQ
http://www.youtube.com/watch?v=yYA1SL4XqGo
http://somim.org.mx/conference_proceedi ... 12_562.pdf
]
Thing is is that 2 out 3 times the walking was stopped during execution...
and com and toss mode had to be reseted before new trial
We never tried to add a small delay or something
!
As said Toss mode is not well documented and i think this extarct of asm code can be usefull for future works...
I calculate some walking routine (parametrized cartesian trayectories for pelvis and feet -> IK), generate a file with angles (in webots format .motion) and then i was sending this by serial port with cm-5 in toss mode.
[
http://www.youtube.com/watch?v=a6_-0hppdNQ
http://www.youtube.com/watch?v=yYA1SL4XqGo
http://somim.org.mx/conference_proceedi ... 12_562.pdf
]
Thing is is that 2 out 3 times the walking was stopped during execution...
and com and toss mode had to be reseted before new trial
We never tried to add a small delay or something
!
As said Toss mode is not well documented and i think this extarct of asm code can be usefull for future works...
by siempre.aprendiendo
Fri Mar 23, 2012 3:38 pm
In this first video you can see the Toss Mode used with an BT<->serial port controlled from the PC.
In this second video you can see an special toss mode that also implemets querying CM-510 ports as Dynamixel commands from the PDA
If I remember well I add about 25ms for the first with the BT connection and about 8-10 ms for the second with the PDA.
phpBB [media]
In this second video you can see an special toss mode that also implemets querying CM-510 ports as Dynamixel commands from the PDA
phpBB [media]
If I remember well I add about 25ms for the first with the BT connection and about 8-10 ms for the second with the PDA.
by siempre.aprendiendo
Fri Mar 23, 2012 9:44 pm
Hope Fritzoid could help us to learn how to use these features
I have been playing a little with "H" command:
ID:15 to POS:459 with the RoboPlus Terminal:
BTW: I think that this really worths a new thread
I have been playing a little with "H" command:
ID:15 to POS:459 with the RoboPlus Terminal:
- Code: Select all
{[CID:200(0XC8)]} hex
HEXA DISPLAY MODE
{[CID:200(0XC8)]} H FF FF 0F 05 03 1E CB 01 FE
->[Dynamixel]:FF FF 0F 05 03 1E CB 01 FE
<-[Dynamixel]:FF FF 0F 02 00 EE LEN:006(0X06)
{[CID:200(0XC8)]}
BTW: I think that this really worths a new thread
by Lothar
Sat Mar 24, 2012 8:27 am
Hello,
thanks to all people who answered to my topic !
I already tested some of your suggestions and I will keep on testing the others. But so far no success. After inserting small pauses the loop ran for a longer time, but after a while it stopped too. Inserting longer pauses in toss mode I loose the advantage in time over the command mode. May be I ruefully go back to the command mode.
regards Lothar
thanks to all people who answered to my topic !
I already tested some of your suggestions and I will keep on testing the others. But so far no success. After inserting small pauses the loop ran for a longer time, but after a while it stopped too. Inserting longer pauses in toss mode I loose the advantage in time over the command mode. May be I ruefully go back to the command mode.
regards Lothar