AX-12's and RX-64's on the same communications string.

[sap1975]

Hi Bren

Thanks for sharing. But although it sounds like a neat trick it still lands in between the two worlds of either two separate busses of a single bus running the lot.

Having thought it over and considered all the great input from you guys i’m leaning towards going for a “media” converter. Just running the RS485 port of a USB2Dynamixel and then converting to TTL non dif. for the AX-12’s. It should be a similarly simple circuit to yours Bren and once again Maxim comes in handy. As Robtis themselves describe in the RX-64 manual i should be able to achieve what i want using a MAX485 line driver.

As an alternative i might just go ahead and buy a CM700 once they release it.

Once again… Thanks for sharing and making me feel quite welcome here .

/Stig.

[arekku]

Hi Bren

Thanks for sharing. But although it sounds like a neat trick it still lands in between the two worlds of either two separate busses of a single bus running the lot.

Having thought it over and considered all the great input from you guys i’m leaning towards going for a “media” converter. Just running the RS485 port of a USB2Dynamixel and then converting to TTL non dif. for the AX-12’s. It should be a similarly simple circuit to yours Bren and once again Maxim comes in handy. As Robtis themselves describe in the RX-64 manual i should be able to achieve what i want using a MAX485 line driver.

As an alternative i might just go ahead and buy a CM700 once they release it.

Once again… Thanks for sharing and making me feel quite welcome here .

/Stig.

That is not going to work, been there done that.

You will end up with 1 line that is driven by 2 drivers.

Your best option would be to use 2 separate busses.

[Bullit]

The cm-2+ manual has much of the schematic in it
http://www.tribotix.info/Downloads/Robotis/CM-2+/CM2PLUS(English).pdf

[arekku]

Actually I've changed my mind. You should be able to have a common bus. The solution I'm thinking of will however require 2 UARTS and some other misc stuff.


TTL -> Uart -> Uart -> RS485

If you look in the cm-2 manual they have 2 separate busses that they switch between.

[sap1975]

Sorry i haven’t replied earlier but work has been crazy busy. (happens from time to time)
Arekku… I’m glad you changed you mind. You had me worried there for a while .

So far i was planning on implementing it as sketched out below.

USB2DYN ____ _____ |RX-64|_____|RX-64|
RS485. ____\_____ | |_____| |
\ \
\ \|Line |__|Diff to |___|AX-12|____|AX-12|
\ |Driver|__|non Diff| | |____| |

(formatting mesed with the sketch. if it's not clear let me know ill draw it up properly)

I do know that a star configuration is not within RS-485 standard but on the other hand i have a line driver which should take care of the termination issue if one exists on the AX-12’s. And TTL non diff. can't really be observed as being standard either. Communications wise it shouldn't make any difference as far as i can tell since its based on a "broadcast" type comm. protocol basically not all that different from ethernet.

Any thoughts???

Cheers
/Stig.

[i-Bot]

Both of the buses are bidirectional. The RX bus is differential 485 levels and the AX bus is single ended TTL levels.

I see no easy way to have a simplee device to translate the bus without access to the direction signal which is internal to the USB2Dynamixel or the controller.

The method from Arekku should work, but needs a fair bit of intelligence between the UART.

I did look at maybe detecting the difference between driven high and disabled states on the AX bus, but the levels vary quite a lot with different loads. I also looked at an alternative where if I detected a low start on the AX bus but not the RX bus it would trigger a monostable for a character period to enable the 485 driver onto the RS bus. Problem there is it is baud rate dependant.

I hope someone has some more ideas for this.

[sap1975]

Hmm… i see your point. Thanks for pointing it out since i obviously didn’t catch that.
This is odd.
It actually seems like the easy way to do this would be to either build a RS232 to RS485 converter and grab the direction signal from there or maybe try to grab the direction signal from the USB2Dynamixel (that is if i’m lucky enough that there’s a pin)
I think i’m getting to the point where i should just get the servos and the fiddle around with it trying different approaches or maybe just use two separate ports.
It’s funny when it’s what you expect to be the smallest of problems that turn out to be the biggest headace.

[tah1]

...
It’s funny when it’s what you expect to be the smallest of problems that turn out to be the biggest headace.

We have a similar but different issue - which is that neither the AX12 nor the Robobuilder wCK servos LABELS the status bytes that are sent back from multi-bussed servos. As there is also no strong spec as to exactly WHEN such status bytes are returned, the only safe way to drive many bussed servos is to wait for [command send - servo-process - command bytes return] all to complete, BEFORE sending any other command to any (other) servo. This massively slows down the potential servo control bandwidth when there are many (e.g. 20-40) on the same bus.
Your problem is slightly different - the bus types are more or less but not quite compatible so bussing the DIFFERENT types of servos is near impossible, related to the send-receive coordination problem.
The SOLUTION we are currently engineering is to build a 40+ channel UART inside a small FPGA with one connection to a controller (e.g. a PC via high-speed RS232, or USB], and 40+ parallel completely independent serial ports each to connect to just one servo. By including suitable I/O logic inside the FPGA we hope to be able to program the format of each servo connector separately, so that one FPGA can concurrently handle at least these three types of servos simultaneously, and allow completely asynchronous control of them - all status bytes returned by the servos will be port#-labelled by the FPGA before returning them to the controller, so that the controller can multitask fully. No waiting for operation completion is required before further commands are sent to the same or other servos. And all status is identifiable no matter what order it is returned in.
Is such a device useful to you guys, or more generally? If so we make it available as a small dev-board in the future.
t

[Bullit]

Sounds like it defeats the purpose of daisy chaining. PWM servo controllers have worked this way for a long time but require a lot of wires.

What I fail to understand is why people feel the need to poll all the servos (20-40) at such a high rate and why people seem to think the micro in the servo can actually provide valuable data at that rate. What data are people interested in? You realize that depending on the servo it needs to keep the PWM drive to the motor up to date as well. Personally I'd like to push more intelligence down to the servo so it wouldn't need to be updated so often/ Its called distributed processing
I'd also like to see better sensors in the servos.

I do agree it would be handy to have an id in the response for clarity.

I don't see 40 UARTs being of value. It may be advantageous for a humanoid to split into 4 or 5 UARTs one for each appendage. This wouldn't add extra wires and being smarter about which servos need to be polled for information solves a lot of the problems people seem to have.

Just my 2₵

[sap1975]

Hi Guy’s

So… I’ve been studying and i think i finally nailed it and got an additional bonus at the same time.
Anyways i dove into all the Robotis schematics i could find and it turns out that both the CM-2+ and the CM-5 use a pretty standard interface to the “servo control” lines including a physical pin on the actual uProcessor controlling the direction of communications.
The intelligence needed for the converter is provided directly on the uProcessor so a mod of say a CM-5 to run both AX-12’s and RX/DX series servos is actually as simple as adding a MAX485 to the box itself right next to the TTL lines using the same control and off you go.
When i first started looking at the Robotis stuff for my project i figured i would go for a CM-5 just to get things started. Easy control software and all that and now it seems i can do just that. This is great news to me.

Tha1: I obviously don’t know what the precise application for you “controller” is but from my point of view it seems like complicating the h… out of things. If you need that kind of control there’s no way around it but for my application for instance it’s shooting sparrows with canons. (never mind it’s a Danish saying) Having the return signals ID tagged would be great but the speed doesn’t really seem necessary.

Once again. Thanks guy’s for all your input.

Cheers
/Stig.

[tah1]

[quote="Bullit"]... why people feel the need to poll all the servos (20-40) at such a high rate and why people seem to think the micro in the servo can actually provide valuable data at that rate. What data are people interested in?
... Personally I'd like to push more intelligence down to the servo so it wouldn't need to be updated so often/ Its called distributed processing
I'd also like to see better sensors in the servos.

I do agree it would be handy to have an id in the response for clarity.

I don't see 40 UARTs being of value. It may be advantageous for a humanoid to split into 4 or 5 UARTs one for each appendage. This wouldn't add extra wires and being smarter about which servos need to be polled for information solves a lot of the problems people seem to have.
...

Well! We're designing limbs with 28DOF hands, plus several more for the forearms and shoulders. Hence the high # of servos per region.

Also we're using force feedback to more precisely control the servos (with 10bit precision) in tasks such as picking up objects. So we need to constantly request load-current (~torq) from the servos DURING A MOVE as well as finding out where the servo has actually got to (usually not where the position requests, because of external objects interfering with the movement), so the data rate to each servo is high during every single movement.

Finally, yes indeed, it would be MUCH better if the servos did more of this internally, but at present they don't, and as far as we know there is as yet no information published allowing recoding of the internal servo microprocessors (which is what is really needed - e.g. we could then get each servo to id-label its status bytes).

For problems projects of this sort, the lcoalised multi-port UART is a simple and cheap solution, and if they're cheap enough, they can be used wherever needed, and still keep the wiring tolerably compact.

best wishes
t

[arekku]

Hi Guy’s

So… I’ve been studying and i think i finally nailed it and got an additional bonus at the same time.
Anyways i dove into all the Robotis schematics i could find and it turns out that both the CM-2+ and the CM-5 use a pretty standard interface to the “servo control” lines including a physical pin on the actual uProcessor controlling the direction of communications.
The intelligence needed for the converter is provided directly on the uProcessor so a mod of say a CM-5 to run both AX-12’s and RX/DX series servos is actually as simple as adding a MAX485 to the box itself right next to the TTL lines using the same control and off you go.
When i first started looking at the Robotis stuff for my project i figured i would go for a CM-5 just to get things started. Easy control software and all that and now it seems i can do just that. This is great news to me.

Tha1: I obviously don’t know what the precise application for you “controller” is but from my point of view it seems like complicating the h… out of things. If you need that kind of control there’s no way around it but for my application for instance it’s shooting sparrows with canons. (never mind it’s a Danish saying) Having the return signals ID tagged would be great but the speed doesn’t really seem necessary.

Once again. Thanks guy’s for all your input.

Cheers
/Stig.

That will only work when you send data. When you wish to receive data you'll have two drivers working on the same wire.

[arekku]

I've tried the above circuit, it'll not work due to IC2B being driver by two drivers.

This circuit *might* work. I haven't tested it as I am comfortable with using 2 separate busses (twice the througput!). Would advise against it but feel free to try and building it.

[sap1975]

Hi Guys
Sorry it took so long but i ran into power supply and delivery issues.
But now i got my servos (thanks for the speedy delivery), i built my power supply and i received my MAX485’s

Bottom line…
Yes you can run both AX-12’s and RX-64’s on the same line. I decided i would start out with a conversion of the CM5 since it would get me started fairly quickly and thanks to petej (i think) a complete schematic exists.
I added a MAX485 to the CM5 by soldering a bunch of wires directly to the 74HC126 VDD, Ground, TX enable to be more specific. The “signal” was picked up from pin 3 of one of the TTL level outputs and on the other side i connected Ground, D+ and D- to the JST connector.
Basically that’s it. It’s actually a fairly easy conversion and a simple breakout board should be pretty easy to make.

One of the cool things about this solution is that it integrates the RX-64’s into the Motion Editor software making it hugely easy to combine the “known” stuff with the more powerful servos.

I’ll draw up a schematic and post it in a couple of days if anyone’s interested.

Arekku: I know it’s not an inline solution but it will do for now.

Anyways… That’s it for now.

[i-Bot]

Pleased to hear you have success to implement this.

Could you post schematic because I am still confused how you combine the receive paths from the MAX485 and the HC125 to the ATMega ? They are both totem pole outputs so cannot be joined like shown in the circuit above with a common enable. Do you use a diode or to combine them ? If so how do you ensure the RS485 bus stays in the idle state (resistors) ?.