wCK servo protocol reverse engeneering and DLL library

[PedroR]

Hi

As you may have noticed from other threads I have been working on creating DLLs to encapsulate communication with Robobuilder.

Having completed a DLL to emulate the protocol of the Remote control and creating a demo using a (PS2) joystick to control the robot, I have moved on to implementing the native wCK protocol.

Here is a screenshot of the test program I wrote:


The DLL and sample code can be downloaded here: http://robosavvy.com/Builders/PedroR/wC ... l_test.zip

There are a few known issues/limitations at this point:
1)
The library I am using to do serial communication is the well known MSCOMM.OCX from microsoft. However it can only go up to about 200kps (in the sample it is set to 115 200, the default for Robobuilder). I intend to upgrade the code to use Native Windows API to do the serial communication. This should allow much faster speeds and much lower latency.

2)
When sending the commands to the RBC, if I then call the MSCOMM.OCX to retrieve the answer too fast, it will return an Empty buffer. The code has a built in delay of 200ms to allow the buffer to fill.
Again, I expect to solve this once I replace MSCOMM with native windows API calls.

3)
The compiled (EXE) file was not running properly on my Windows Vista Machine (could not open the COM port). However, when I load the VBP file in VB6 and run the project it works fine.
I am not sure if you will encounter the same problem....

4)
Only part of the wCK protocol is implemented. I have implemented the commands to set and retrieve wCK positions, rotate 360º, set the values of the IO ports, release torque and power down/dynamic break.


Here are my interesting findings so far:
1)
The wCK modules have 3 states:
a) No torque (you can move them freely)
b) Power Down/Dynamic Break: according to the docs, the servo is powered down but it retains it's position and some torque. It's harder to move than in mode a) but it's possible to move it.
c) Position Set: the servo's are powered and it applies torque to retain it's position. In this mode it's very hard to move the servo.
[u]I was surprised to learn about mode b)[/u]

2)
The LEDs in the transparent Robobuilder are connected to digital IO ports 1 e 2 (please see page 31 of the wCK manual).
Basically you set the ports to 1 and the leds light up; then set it to 0 and they power down.
I still want to test and try with the A/D port of the servo. That's not yet implemented on the DLL.

3)
When you issue a 360º command - to make the servo rotate 360 deg - the servo actually keeps spinning.
I expected it to do 1 revolution and stop but instead it just keeps spinning until you issue a command to set position, release torque or power down/dynamic break.
It has the nice feature of maintaining a counter of how many revolutions it has done.

I believe the DLL library is quite simple to use but I appreciate your feedback. I will post some sample code bellow.

Pedro.

[PedroR]

Here is the core code for the sample I wrote (screenshot in above post).

Code: Select all

Private Sub cmdMoveWCK_Click()
    Me.txtReadPosition.Text = CStr(oRBSwck.SetPosition(CInt(Me.txtWCKNumber.Text), CInt(Me.txtTorque.Text), CInt(Me.txtTargetPos.Text)))
End Sub

Private Sub cmdPowerDownAndHold_Click()
    oRBSwck.PowerDownAndHoldAll
End Sub

Private Sub cmdReadPos_Click()
    Me.txtReadPosition.Text = CStr(oRBSwck.ReadPosition(CInt(Me.txtWCKNumber.Text)))
    Me.txtReadLoad.Text = CStr(oRBSwck.ReadLoad(CInt(Me.txtWCKNumber.Text)))
End Sub

Private Sub cmdReleaseTorque_Click()
    Me.txtReadPosition.Text = CStr(oRBSwck.ReleaseTorque(CInt(Me.txtWCKNumber.Text)))
End Sub

Private Sub cmdRotate360CCW_Click()
    Me.txtReturnCode.Text = CStr(oRBSwck.Rotation360(CInt(Me.txtWCKNumber.Text), CInt(Me.txtSpeed360.Text), rbsRDCounterClockWise))
End Sub

Private Sub cmdRotate360CW_Click()
    Me.txtReturnCode.Text = CStr(oRBSwck.Rotation360(CInt(Me.txtWCKNumber.Text), CInt(Me.txtSpeed360.Text), rbsRDClockwise))
End Sub

Private Sub cmdSetIOTo1_Click()
    Me.txtReturnCode.Text = CStr(oRBSwck.SetIOPortValues(CInt(Me.txtWCKNumber.Text), True, True))
End Sub

Private Sub cmdSetIOTo0_Click()
    Me.txtReturnCode.Text = CStr(oRBSwck.SetIOPortValues(CInt(Me.txtWCKNumber.Text), False, False))
End Sub

Private Sub Form_Load()
    Set oRBSComm = New rbsCommPort
    Set oRBSwck = New rbsWCKProtocol
   
    Set oRBSwck.RBSCommPortObject = oRBSComm
   
    With oRBSComm
        .CommPortDataBits = 8
        .CommPortParity = rbsPNone
        .CommPortSpeed = "115200"
        .CommPortStopBits = rbsSOne
    End With
   
End Sub


I think the library is quite accessible and self explanatory. If you compare the functionality exposed and the size of the code I think the library comes very accessible but I would really appreciate your feedback on future features, design suggestions, etc.

Please note, from the code, that the DLL implements methods to change the RBC into PC control mode and out of PC control mode.

[PedroR]

hi

just a quick stop to share my progress on this.

I have finally completed implementing all of the protocol functions according to the wCK manual v1.07 and will post the code in the next fews days as I need to do further testing and profiling.

I also added two additional functions:
- Ping - to check if a servo is connected (by supplying its ID).
- RestorePIDGains - to restore the PID configuration back to default.

I have been playing with different PID value settings and it's indeed a very nice feature, although I came to realize these are very powerful settings. Under the wrong combination the servo can really behave crazy.


Also another thing that I don't remember if I shared: in the transparent version the LEDs are connected to the digital IO ports so the LEDs turnon whenever you set the ports to 1 (bit).

I am also looking forward to test the A/D port and see if you can really attach any 0~5V sensor to it.

[PedroR]

Hi

Further findings now that I have been extensively testing and playing with the protocol:

1)
Querying the A/D port seems to be an erroneous process. Apparently, the value of the AD port changes whenever the position of the servo changes.
I was convinced this was an external IO port where you could attach sensors but I this point I do not know.
The values it returns seem to increase when the servo position increases but AD values and servo position grow at different paces/rates.

2)
Servo Movement Boundaries.
It is possible to set the lower bound and upper bound of the servo movement.
If you issue a SET POSITION command to a position outside those boundaries, the command is ignored.
The interesting thing however is this:
if you set the servo to a position on the limit of the upper or lower bound and later force it, with your hand, to a position outside that boundary, the servo will automatically do a full rotation into a position inside that boundary again.

3)
Speed and Acceleration Setting
The protocol includes an instruction to set the speed and acceleration of the servo but setting them to different values did not seem to affect the servo behavior.
For a while I hoped the "acceleration" parameter could be used to implement some form of S-Curve on the movements but it seems to have no effect on the servo at all.
The same goes for speed setting: nothing seems to happen with different values.

So the this report is mostly about disappointing features.

I would really appreciate any guess or feedback on what the values from AD port might mean. Could it be the bare (unprocessed/unnormalized) reading of the servo's potentiometer?

To spice things up, I'm posting a picture of the servo processor. I have disassembled it to try and understand where the AD pins were connected but I couldn't figure anything out myself. All I got was a couple of pictures





Sorry for the poor quality. They were taken with my cell phone.
The first shows the ATMEGA8 processor label and surroundings and the second shows the the IO ports.

[i-Bot]

Hi Pedro,

Do you have anything connected to the A/D pin of the I/O port ? If it is floating it will probably pick up noise.

Either input a fixed voltage to the I/O pin or at least connect a resistor to ground to check if it stays at 0.

Richard

[PedroR]

Hi Richard

At the moment nothing (external) is connected to the IO port.

As I understand you suggest one of two solutions:
- Connect input voltage.
In this scenario can I simply connect a 1.5V AA battery to the port without any resistor? I was afraid to do it because I was unsure if it would short circuit the AA battery.

- Or connect a resistor between the GND pin of the A/D port (bellow pin3) and the ground. The ground should be Ground that comes from the RBC, right?
Nothing will be connected to pin3, correct? Also, what is the value you recommend for the resistor?

Thank You
Pedro.

[i-Bot]

I assume the A/D IN pin connects direct to the A/D input on the AtMega8, which has an input resistance of over 50 M ohms. I also assume the ground pin opposite the A/D in pin connects to RBC ground. Any electrical noise or leakage on the board would account for the strange values you get if the input resistance is that high.

You can use an external resistor (any value between 10K ohms and 100K ohms) connected in series to the A/D in pin and try both, connecting the resistor to the opposite GND pin, or connect the resistor to the +ve of the 1.5V battery which has its -ve to the GND pin. The resistor will not interfere with the reading, but protect any circuits if my assumptions are not correct. Yous hould get two diferent stable readings.

Best to always keep the resistor in series with the A/D in pin to limit the current.

Richard

[PedroR]

hi Richard

Thank you for your tip. I won't be able to try today as, apparently, I don't have any resistor at home LOL. I was unware of that.
I tryed to improvise a resistor using a graphite stick but I couldn't get stable readings of resistance with the Multimeter so I decided to wait for tomorrow and get a couple of resistors.

I will probably disassemble the servo again to try and see if it is connected to the ATMEGA IO pin as you suppose.

Thx
Pedro.

[PedroR]

Hi

I have disassembled the servo yesterday, but this time, I have completely disassembled it.
Form what I've seen it's probably picking up noise as Richard suggested.

Here are my findings:
- The IO ports are actual solder points. They are not holes that go all the way through, because the DC motor is on the other side of the PCB.
I suspected the AD port was reading the RAW potentiometer value but it is probably NOT the case as the AD port and the potentiometer are on opposite sides of the PCB. This is why I'm leaning towards the readings being caused by noise.

I've also played a bit with the protocol library with the servo disassembled. Here are my findings:
- The Speed and Acceleration Setting of the wCK protocol do not have any effect whatsoever. With the servo disassembled, the DC motor always spins at the same speed and acceleration as I had already seen with it assembled.
- The "Torque" parameter that you specify when you issue a "SetPosition" command does affect speed. I believe it should be related to the amount of Amps Volts that the DC motor is getting.
With higher torque parameters the DC motor spins much faster and with lower parameters it seems to spin slower (although still very fast).

Here are the pics:

Plastic cover with the cogs fitted.


Structure in the middle of the servo where the DC motor and PCB are fitted/bolted to.


Bottom side of the PCB. This one can only be exposed once you remove it from the plastic structure shown above.
On the left, the potentiometer (it's the BIG shaft in the servo that spins it). On the right, the DC motor.


Top side of the PCB. On the right I got a clear picture of the IO ports. The Digital ports (on the top and bottom) are fitted with LEDs. The middle solder points are AD.


One other thing: you need a good welding iron and a steady hand to get anything welded there. The solder points are a bit small and are very close to each other. It would be a lot easier if had just fitted a header.

Putting the servo back together was easy up to the point where I had to fit the big shaft in the potentiometer, in the right position.... After a few attempts I'm glad to say the servo (11) is working properly again

[PedroR]

Sucess in using the servo IO ports!

I hadn't done any soldering for the past 9 years (since high school) so it was quite a challenge to get two wires soldered in the small pin 3 and GND (just bellow it). I won't post any pictures as it looks really messy

Anyway, the point here is that Richard's assumptions were right:
I was picking up noise indeed. I did several readings using resistors. All readings were stable and results are bellow.
- 67KOhm - IO read 2
- 46KOhm - IO read 0
- 10 Ohm - IO read 0

I then connected a 1.5V battery and got a stable reading of 86.
It seems to be in proportion with the 0~255 reading range (1.5 is 30% of maximum 5V where 86 is 33% of 255).

Finally, I short circuited pin 3 (AD) with GND and also got a reading of 0 without any damage to the servo.
So I suppose the pins are really connected to the AD pin of the ATMEGA as Richard suggested.

I didn't really understand why I got a reading of 2 with the 67KOhm resistor. I repeated the reading twice and it's stable at 2, so maybe at that impedance value, it will start to pickup noise?

To conclude I must say this is not a very resistant approach. It's great that you can attach an analogue sensor to each servo, and makes the robot very extensible.
However because they are solder points on top of the board and there is not really a "hole" to solder the wires through, I suspect the soldering won't be very reliable under heavy use.
In my case one of the soldering broke after moving the AD wire a bit and then, after re-soldering, I was pulling the wire to test for resistance and ended up separating one of the PCB tracks from the board (the one for AD). The track still works though.

[Joe]

It's great that you can attach an analogue sensor to each servo, and makes the robot very extensible.
However because they are solder points on top of the board and there is not really a "hole" to solder the wires through, I suspect the soldering won't be very reliable under heavy use.

That's pretty common these days though. I think you just need to provide some strain relief; the standard trick is to apply a dab of hot glue after soldering your leads.

There might also be some sort of connector you could solder on there, and then glue down to the PC board, though I don't know exactly what part that would be.

Are those pads connected to anything else? Like the cable connector, for example? If so, it might be much easier to hack a custom cable rather than solder onto the PC board directly.

Best,
- Joe

[PedroR]

Hi Joe

Thank you for your input!

The solder pads are not connected anywhere. BTW today I had a fatal accident where the PCB track that got detached, definitelly broke so now my test servo has dead A/D port....

Limor also sugested that, since the pads sit just bellow the small IO cover, maybe we could fit some spring or connector and expose on the IO cover.

Do you know of anything like this?
iBot ?

[Raymond]

Hi Guys,

Do you have a schematic showing the pins to line up with the wck from the psd/mic sensor which has 6pins as default.

Thanks

Mark

[PedroR]

Hi

The schematics can be found here: http://robosavvy.com/Builders/i-Bot/RBC.pdf

iBot has kindly documented everything.

The schematics for the head cable are on the first page (bottom left) and it's labelled CN3.

Please note the cable is for PSD head sensor (distance sensor) and for the IR sensor (for the remote).

The sound sensor is built into the the RBC controller and it's not in the head.

Regards
Pedro.