How can we read a number of dynamixels in a single go?

[rikkov]

Hi,

The doubt I have is ...can we read a number of dynamixels(Rx-28/64)...in a single go....do we have any options like sycn write to read data from dynamixels......presently I read dynamixels one by one...so it takes a lot of time...so can you guys suggest a faster way to me...please help me...

Thanks!!!
Rikkov

[StuartL]

Our new firmware for the AX-12 will allow a sync read. This code hasn't been implemented yet but it's not far from it.

I have NO idea if it'll port easily to the RX range...

[JonHylands]

To do something like a SYNC_READ with stock dynamixels, you need an in-between processor talking to the bus. Somelike like an ATmega128, or an ATmega162. Both have two hardware UARTs, and can talk at 1.0 Mbps.

Basically, you would talk to the ATmega with your processor, and it would talk to the bus. You would execute a SYNC_READ, which would return a set of cached values. At that point the ATmega would go and poll each device on the bus, updating its cache with the current value. Of course, you wouldn't be able to use the bus while its doing this.

For controlling a robot, the general flow would look like this:

Code: Select all

loop
   do SYNC_WRITE
   do SYNC_READ
   pause (while the ATmega is updating its cache)
end loop


The only downside to this is the read is one cycle behind, but since you're presumably running at 20-40 Hz, its not a big deal.

- Jon

[billyzelsnack]

Our new firmware for the AX-12 will allow a sync read. This code hasn't been implemented yet but it's not far from it.

Did you post somewhere how you were doing this because I'd sure like to write my own firmware for the AX-12's.

[limor]

you can set the response delay to a very small value.
this would allow you to read the servos at very high speed even doing it one by one.

another idea that has been implemented here (if i recall it was by billyzelsnack , maybe because you can't set the response delay to 0) is to play around with the response delay of the servos so that when sending on the bus say 5 consecutive READ packets designated to servo 1..5, when the last packet has been issued, servo #1 will respond, then #2 etc.

[billyzelsnack]

I think the most I was able to get away with was 4 in flight at once.

[StuartL]

Our new firmware for the AX-12 will allow a sync read. This code hasn't been implemented yet but it's not far from it.

Did you post somewhere how you were doing this because I'd sure like to write my own firmware for the AX-12's.

Which bit do you want to know how to do? Matt has spent weeks solving all of the independent issues, I spent nearly a week reverse engineering the Robotis software so that we can reflash on the fly.

We've got most of the servo functionality working. One of my to-dos over the next few weeks is to implement the token-ring SYNC READ.

One of the things we can already do is do what Jon was talking about in the CM-5. Because we're entirely interrupt driven we can already run our reads one cycle behind and we don't lose much time, but even with return delay set to '1' it takes a 50th of a second to go round all 22 servos.

[billyzelsnack]

All of it. Though it sounds like a much more elaborate process than I thought it might be. I just have a ton of ideas..

1. Ability to construct custom commands that do exactly the work that I want with the minimal of communications.

2. Setup one of the servos to do all the read/writes to the other servos on its own and let me know when it's ready for me to read/write from it for the data from all the servos.

3. Fancy stuff to constantly sync a time clock between all the servos so I can tell them to send/receive at certain semi-precise times in the future.

Are you planning on posting your hex files at some point?

Also have your tried the return delay trick. I did get quite the speedup.

[limor]

Hi StuartL,
You have mentioned this before in this thread:
http://robosavvy.com/forum/viewtopic.php?t=2673

can you please tell us about the format of the ROM file?

this would probably be the easiest way to flash the AX12 without having to replace the bootloader

[StuartL]

Ok, the ROM file format appears to be deliberately obscure. There's a header to it that I never managed to decode but I stripped it and managed to extract the data from the remainder of the file with the following source:

Code: Select all

#include <stdio>

int main(int argc, char *argv[]) {
    int xor = 0, count = 0;
    short int word;
    char c = 0;
    if (argc != 3) {
        fprintf(stderr, "Expected 2 arguments, got %d.\n", argc - 1);
        return 2;
    }
    FILE *input = fopen(argv[1], "rb");
    FILE *output = fopen(argv[2], "wb");
    if (!input) {
        fprintf(stderr, "Failed to open %s.\n", argv[1]);
        return 1;
    }
    if (!output) {
        fprintf(stderr, "Failed to open %s.\n", argv[2]);
        return 1;
    }
    while (fread(&word, sizeof(word), 1, input) >= 1) {
        c = word ^ (xor++);
        fwrite(&c, 1, 1, output);
        count++;
    }
    fclose(input);
    return 0;
}


Of course because I don't understand the header (which was removed from the input file for the above program) I don't know how to recreate it (and potentially any checksums) to appease the BCP with its flashing. We now have a flashing routine that works by the CM5 receiving the desired image over the serial port (i.e. the Zigbee in our system) and requesting retransmissions as required for corrupt segments (using our own packetised protocol). It temporarily stores this in its own flash (bear in mind that this happens in the CM5 bootloader, which is bioloid bus aware) not overwriting any bytes that haven't changed. When ready to flash the CM5 sends a digital reset packet to the desired servo and switches the bus into 57600. It then sends several '#' characters which is enough to put the servo into a MUCH reduced CM5-a-like bootloader over the half duplex bus. Because the bus is half duplex the commands are much simpler. As soon as the CM5 gets a response from the servo bootloader at 57600 it sends the load command and transmits the servo ROM from its own flash to the servo. It confirms the checksum is ok and if so reboots the servo, which then comes up at 1Mbit.

Because Matt got the above process working in less than an evening (he really is very good ) we never needed to reverse engineer the BCP file format any further.

[billyzelsnack]

If you know the header can't you just use it on top of a modified hex file and use the already exisiting Robotis AX12 update software?

[billyzelsnack]

Oh I see. I reread. The problem is that the BCP will think an updated hex file is corrupt and will abort the update.

How big is the header?

[limor]

Hi StuartL,

thats an impressive decryption of the ROM file. how did you come up with this

while (fread(&word, sizeof(word), 1, input) >= 1) {
c = word ^ (xor++);

have you managed then to use the robot terminal to upload a clean HEX into that flash area and then invoke the upload of that hex file into the servo ? if so how?

thanks

[StuartL]

We didn't try redoing a ROM file with our own data, we didn't need to because we found a better way of flashing the servos over the 1Mbit bus than using the BCP. This uses the servo digital reset and built in bootloader. If you were to write a CM-5 bridging function you could even put all of the logic in a controlling PC

The header, from memory, was 14 bytes. But then you already know this because you've looked, haven't you?

I've put a zip file containing the full 8kb servo image, the 6kb application and the 2kb bootloader on http://www.braincell.cx/~stuart/ax12-re ... yfiles.zip Note that this isn't the ROM file but the extracted binary images.

We aren't using robot terminal any more. We now have our own bootloader on the CM-5 which can flash the servos in-band and it talks to our own Linux/Windows application to avoid dependencies on the inflexible Robotis bootloaders and applications.

For now the robots are on the shelf while we prototype some new hardware based upon the ATmega164p. We've got a lot working but just managed to brick an MCU, so we're currently developing a board to unbrick MCUs. This seems harder than we expected...

[billyzelsnack]

haha. I guess it's pretty obvious how big the header is if the file is so close to 8k. Maybe I'll give a go at haxoring the header.