AX-12 circuit diagram?

[StuartL]

Has anyone reverse engineered the AX-12 hardware yet? I'm not averse to doing it but I'd rather not spend a few evenings figuring it out if there's a circuit diagram or port map kicking around somewhere...

[i-Bot]

This was what I found out. Please let me know if you find any errors and I will update it.

http://robosavvy.com/Builders/i-Bot/AX12.pdf

[StuartL]

That's fantastic, thank you! I presume, from the degree of documentation, that you're reasonably confident in it?

[Chris.H]

Hi, StuartL, I-bots circuits seem nearly ok.---Fets upside down and back to front. Q1 should be Q3 etc... Don't think this will bother you if you're writing software. The uP interface is ok. Do any of you know the crystal/resonator frequency of the AX12+? I'm sure I could work it out from the baud rate dividers but.....my other half wants to go out!!

[i-Bot]

Thx, I will update the FET part. I was surprised there was no current or voltage measurement near the motor. I don't think I missed any traces.

I measured the clock at 16MHz

[i-Bot]

I made the corrections to the FET part identified by Chris.H
http://robosavvy.com/Builders/i-Bot/AX12.pdf

[Chris.H]

Hi i-Bot,
That looks right now!. Have you done the AX-S1?

[limor]

Thx, I will update the FET part. I was surprised there was no current or voltage measurement near the motor. I don't think I missed any traces.

that is surprising!

Can you please clarify what all the attached pins in the diagram are doing?
PB1 - ?
PB2 - ?
PB3 - ISP interface - MOSI
PB4 - ISP interface - MISO
PB5 - ISP interface - SCK
PC0 - ?
PC2 - ?
PC3 - Battery voltage measurement
PD0 - RX
PD1 - TX
PD2 - controls RX gate ?
PD3 - ? (gnd)
PD4 - ?
PD6 - controls the RX gate ?
PD7 - controls the TX gate ?

btw: The AX12 return, in my experience, about about 7 changes/second for current measurement and speed measurement compared to 400 changes/second for position measurement.

[i-Bot]

For the pins

PB1 - PWM output to motor
PB2 - PWM output to motor
PB3 - ISP interface - MOSI
PB4 - ISP interface - MISO
PB5 - ISP interface - SCK
PC0 - Voltage from position potentiometer
PC2 - Voltage from temperature measurement
PC3 - Battery voltage measurement
PD0 - Serial RX data
PD1 - Serial TX data
PD2 - LED on/off
PD3 - ? this is a pad R21 on the board but appears unused
PD4 - ? (gnd)this is pad R21 on the board but appears unused
PD6 - Serial RX enable
PD7 - Serial TX enable

We have seen from the Hitec servos that the current does not actually have to be measured. Knowing the angular velocity, supply voltage, and the applied PWM it can be calculated.

Does the current reported by the AX12 change with battery supply voltage ?

note: there is a schematic error related to PD3 and PD4. Above table is correct. I will update schematic to show R21 as a not fitted resistor and swap the pins

[Chris.H]

Hey how do you upload stuff to this BB? I'll try this...should answer a few questions
http://robosavvy.com/Builders/Chris.H/AX12Motor.pdf
http://robosavvy.com/Builders/Chris.H/AX12Processor.pdf
http://robosavvy.com/Builders/Chris.H/CM5.pdf

[limor]

Thanks to i-Bot for clarifying the pin setup and to Chris for uploading the detailed schematics of the motor circuit and the cpu circuit. It does clear things and allows reprogramming the firmware.

If i understand correctly, the schematics imply that there is no current measurement and there is no way to control the maximum torque by limiting the current. Basically all the functionality of the AX12 is given purely by sequencing of clockwise/counterclockwise pulses.

If i find the time i would love to reprogram the AX12 and write a protocol to support high speed closed-loop control: continuously receive a target position and speed and return the current position and any other sensor data. This in order to relay computation to a powerful CPU like a gumstix or even to a remote PC instead of limiting the functionality to what the Atmega8 can take. BTW: I dont recall if someone looked at whether the servo firmware upgrade files are just the hex file output of GCC or are they encoded or prefixed in some way before being sent to the AX12 bootloader using the MotionEditor/BehaviourControl menu option.

We have seen from the Hitec servos that the current does not actually have to be measured. Knowing the angular velocity, supply voltage, and the applied PWM it can be calculated.

You don't really know angular velocity. all you know is the POT output which is position. so the first derivative gives velocity and the second, acceleration. Current is an interesting parameter to measure because it gives an indication of external torque applied on the shaft of the servo. When the servo is blocked, the current consumption spikes otherwise there is a "typical" current function related to internal friction of the servo, the structure inertial of the robot and rotating shaft. So deducting current consumption (ie: external torque) is not a simple matter.

[StuartL]

We now have reprogramming capability for the AX-12 and CM-5 bootloaders. The only thing outstanding before we actually wipe the servo (we've already done the CM-5) is to try and get a copy of the bootloader that's installed in the servo as standard. We know that it's a cut down version of the one in the CM-5 but it seems to share the servo bus with the servo data, it also runs at a mixture of 57k6 and 1M baud.

We've got packet dumps of a servo reflash (which Robotis seem to have made deliberately awkward) and we have the 'real' AX-12 binary image (not the ROM file Robotis hand out, which we're still trying to figure out the format of).

As soon as we can get the bootloader image (and hence as soon as we know we can recover the servo if we have to) we'll start playing. Expect some new servo code this year.

Features will definitely include:

- Backwards compatibility.
- Much faster bus protocol, same bus speed but more efficient protocol.
- PID control.
- Over-the-wire flashing/upgrades.

And, of course, anything else we think of in the mean time.

[i-Bot]

It seems a shame to wipe out the existing loader, and may make users more cautious to try your new software.

Do you know enough about the download protocol to get a small aplication program into the AX12 ? LPM usually works from an application looking at the bootloader area. This is what I did with the Robonova C3024 and then dumped out the bootloader code to the serial port.

Can you share the start of the packet dump of the download ? I assume it starts at 1M to make the jump into the loader, then probably at 57.6K for the loader.

I was going to do this for the Robobuilder controller, but it turns out this uses a standard bootloader product. Also there is no messing around of the data.

[StuartL]

It seems a shame to wipe out the existing loader, and may make users more cautious to try your new software.

That's fair enough, we're only redoing the bootloaders to allow better stability of flashing over the air, right now loss of data due to wireless interference corrupts the data and the existing bootloader can't always recover from it. By using a packetised upload protocol we can flash the CM-5 and servos over unreliable communications media.

Do you know enough about the download protocol to get a small aplication program into the AX12 ? LPM usually works from an application looking at the bootloader area. This is what I did with the Robonova C3024 and then dumped out the bootloader code to the serial port.

That's exactly what we're planning to do next To achieve this we either need to reverse engineer the .rom file format (which is very strange) or replicate the flash protocol the CM-5 uses. Due to bus sniffing we do think we've got the latter one but it requires testing, and testing means risking it

Can you share the start of the packet dump of the download ? I assume it starts at 1M to make the jump into the loader, then probably at 57.6K for the loader.

Yes, certainly. However before I share it I want to make sure it's right, and that means replicating its behaviour and understanding the process.

I was going to do this for the Robobuilder controller, but it turns out this uses a standard bootloader product. Also there is no messing around of the data.

Yes, the more we look in detail at the bootloaders the more we wish Robotis had given us the source so we could fix some of the problems. While we could use an industry standard bootloader I haven't yet had a look at any and we've pretty much written one with the app the CM-5 currently runs, converting it to a bootloader is just a case of cutting out some features and optimising for size and stability.

[billyzelsnack]

This is great. I may just have to change my plans.

I was going to add several extra pieces of hardware to lower latency of messing with so many servos at once. Each piece would handle a small number of servos exactly how I want and I would grab the data from my hardware instead of the servos directly.

If I can reprogram the servos then I might be able to get the performance I want without extra hardware.

Awesome! Please keep us up on your progress.