Can Roboard 110 work with serial servos from Kondo?

[ks_khr3]

Hi, I have a Kondo KHR3 and am looking to expand its capabilities. I read that the Roboard product can drive Kondo servos but by default I take this to be true for the older & non-serial servos. Has anyone tried to use Roboard with the KHR3 and more specifically the serial servos used in the KHR3?

Thank you very much for your help. All the best

[chrisvo]

Hi again. With regards to directly driving the serial Kondo servos, the RoBoard has a UART which is all you really need; you may need to supplement it with some additional circuitry (the multi-drop serial bus) to provide a place for your servos to plug in. The specification for the Kondo protocol is here:
http://kondo-robot.com/sys/wp-content/u ... ndv1R1.pdf

You could also use the RoBoard in conjunction with the RCB-4 if you use this library:
http://bitbucket.org/vo/libkondo4
Essentially you hook up the RoBoard via UART and change all the USB stuff to UART send/recv. You might need to invert and level shift the serial signal as Kondo appears to be using inverted 5V logic.

[limor]

Hi Chrisvo

Thank you for sharing your code !

Also, do you have a translation of the ICS3 protocol ?

Does your code also allow direct communications with the servo bus (like Bioloid's usb2dynamixel) ?

is there a module that allows direct comunications from a PC via USB to the Kondo servo bus ?

is there maybe a repeater mode on RCB4 that mirrors back/forth the packages from the PC to the servos via the RCB4 (so no usb2dynamixel is required) ?

[chrisvo]

Also, do you have a translation of the ICS3 protocol ?

No, but Google Translate works pretty well on it. It's a pretty small protocol.

Does your code also allow direct communications with the servo bus (like Bioloid's usb2dynamixel) ? is there maybe a repeater mode on RCB4 that mirrors back/forth the packages from the PC to the servos via the RCB4 (so no usb2dynamixel is required) ?

Yes. I recently found out the command to get the RCB-4 to forward ICS packets directly to the servos, so using libkondo4, you can tell the RCB-4 to send an ICS packet, like to query servo positions (and all other servo data, like temperature, speed, stretch, etc), and set servo positions (including free position and trim position). The entire capability of ICS protocol is available this way. However, the RCB-4 is still needed. For many people this is a reasonable requirement because after all, you need some kind of circuitry to route power and manage the serial traffic, and the RCB-4 is designed to do that.

However, I would eventually like to communicate directly with the servos without the RCB-4 in the middle. For example, in my application. I require minimum latency for feedback control. The RCB-4 takes up extra space, power, and weight on the robot. To do this, I'd still need some additional circuitry, for example, to break out a serial bus from something like the RoBoard and provide power to the servos. I don't imagine that it is hard, but I have never done that before and my hardware skills are useless...

I wish Kondo had their detailed specs up like Robotis. Having to reverse engineer everything to get my robot to do cool stuff is tiresome. Robotis has everything laid out from electrical characteristics and protocol specs down to tips and suggestions for people doing custom stuff. In English.

[chrisvo]

By the way, I managed to move some Kondo servos the other day.

I am using ICS 3.0 serial protocol through an FTDI USB-to-UART chip (FT4232H) and a half-duplex circuit (74HC126/74HC04, similar to the setup recommended by Robotis for AX series servos). Just crossing TX/RX as shown in the RB-110 Hardware Guide might work, but there's variety of forum talk about how that's possibly not a good idea...

I think I'll have the C library for ICS 3.0 uploaded in about 1 week.

It should work on any Linux based board, including the RoBoard. In fact, the RB-110 has a FT2232H on-board which drives the two high-speed UARTs, so with a little extra circuitry you should be able to command servos. I might later make a few "USB2Kondo" boards which like the USB2Dynamixel will offer the ability to control and program Kondo ICS servos directly through the USB port...

[i-Bot]

The C library is looking good.

I put up the schematic of the interface I did for the Dynamixels in case it helps. It does the direction control and also the 3.3 to 5 V conversion, so device types (AHC, AHCT) do matter.

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

I am interested for you to maybe try the setting of the latency timer to 0. You may have to modify ftdi.c to accomodate this. Latency 0 works on the high speed devices and sets the latency to 125us. This initially worked quite well for me under linux, but was a failure under XP due to too many incoming empty mesages.

[chrisvo]

i-Bot:

Nice! Thanks for the schematic! I am wondering a few things though since I'm not very electronics-savvy - why do you use the 1N4148 diodes and 47R resistor at the half-duplex output?

[i-Bot]

The diodes and resistor are the same as used on the Robotis CM-5 interface and provide some protection against nasties on the signal linem like shorting the line to the battery voltage or noise spikes from motor.
Looking at it now, if I had designed that part, I would have the diodes at the other end of the 47R resistor.

[chrisvo]

I ask because I have a problem when trying to communicate with the Kondo servos:

Circuit:


Oscilloscope:


Top half: Capture of 1 packet of TX/RX conversation between FT4232 and Kondo servo.
CH1 (yellow) is probing the half-duplex line (going to the servo). That's where the "6" is on the schematic.
CH2 (blue) is probing the RX line (going to the FT4232). That's where the "RX" is on the schematic.

Bottom half: Zoomed-in version of the selected window from the top-half.

The problem is that voltage dip you can see on CH2, which is causing the FT4232 to erroneously read extra bytes at the beginning of the return packet, because it sometimes dips just below the switching threshold. I'm not sure yet what to do in my circuit to fix the problem....

[i-Bot]

The 10K pullups R6 and R7 in my schematic, hold the level high, when the receiver is disabled. You might add these otherwise it is floating. They are often omitted in AVR designs, because they can be enabled by software on the chip itself..

[chrisvo]

Ah yes, that slipped my mind, adding the pullup works perfectly. I haven't yet experimented with the latency 0 setting, because I've been messing with several other projects.

I did manage to finish the lower level details of the ICS protocol in the C library (e.g. set position, free, trim; read data; reprogram eeprom and id), now I'm adding another layer that handles some motion primitives (e.g. go to pose with linear/quadratic interpolation, manage servos including use of multiple SIO channels for one robot). After some clean up and documentation I will post the first part soon.

[veltrop]

Hi chrisvo,

I would like to bitbang the ICS2.0 protocol over the Roboard GPIO/PWM for communicating with KRS-788 and KRS-4024 servos. The purpose is to dynamically change the strech/speed etc during a motion routine.

From what I can tell in the RoBoIO source, this is how the TCH functionality is implemented, so it should be possible.

I think the lower level details part of your ICS C library would be very helpful to get me going on this. Would you mind sharing at least that part now? Please!

If I get this working, then you all could probably extend it to control Kondo serial servos over the Roboard GPIO/PWM ports.

[veltrop]

Sorry, nevermind

I was wrong about how the TCH(teach) function is implemented in rcservo.cpp, the servo responds to a specific PWM signal, it has nothing to do with the ICS protocol.

But using the servo headers GPIO as bitbanged ICS ports could still be a nice feature!

It looks like what I need is to learn how the RCB-3 tells the Kondo servos to enter their 3 different stretch/speed profiles. That is a feature the Roboard does not do currently. Looks like a bit of a digression from the OP I'll start a new thread on that if I find anything interesting with my oscilloscope...

[i-Bot]

Best as you say to start a new thread, so as not to confuse the ICs 2.0 and ICS 3 protocols.

I do recall seeing the ICS2.0 protocol described and it appeared very similar to the PWM for the Hitec HMI protocol. Since Roboard can do the Hitec, might well do the ICS 2.0 too with a bit of tuning