Full Official Documentation for the RBC protocol available

[PedroR]

l3v3rz latest post got me curious.

1)
By reading the "wCK Programmer" Manual (it's on the CD I think) there is a command named "Product Information Scan" / Set Product Information that's not documented on the wCK manual I think.

It seems to return a value that may be a bitmask that may affect the wCK behaviour.
Having looked at the way all components are programmed it makes sense to assume there is a way to adjust the threshold to report load at all times.

2)
If you have a look at the last page of the wCK manual with the summary of the command packets you'll see that there's seems to be room for additional configuration commands on byte 3.

You set the high 3 bits of byte 2 to decimal 7 (which are the commands to read and write the various parameters) and then play with the value of byte 3.

The following "holes" exist for byte 3 that are undocumented (and may have some use):
-> 0~7 - for some reason the opcodes start at 8 so probably these do something as well.
-> 19,20 - i'd bet on these 2. They are among a list of OPCODES that configure something so they probably have some use that's undocumented.
-> 25~99

At 100 begins writing and reading the wCK programs.

At 200 begins the 10bit commands.

Once of the things that was pointed out by tah1 was the fact that reading the analogue IO port only report highest 8 bits although the ATMEGA has a 10bit ADC on that port.
Maybe there's also some OPCODE hidden above 200 that reports the A/D port reading as a 10bit value...

In any case, if for some reason you bring the wCK to an inconsistent state while experiment do not worry there's a trick to perform a factory reset that's documented in page 31 (section 3-10) and page 32 (section 3-12) of the wCK manual.
It consists on shorting two solder points and it will revert all values back to factory defaults.

[l3v3rz]

On the reset function I can confirm it works

Here's a question: How does it produce the Position/Torque/Speed graphs in the wck programmer manual ( 5.4 Graph view section ). Ive just run it and it clearly show the torque setting as a brown line. The return value quoted:

00,00,00,5E,00,7F,00,7E,00,7C,00,7A,00,79,00,79,00,78,00,76,00,75,00,75,00,73,00,
72,00,72,00,70,00,6E,00,6C,00,6C,00,6A,00,69,00,67,00,67,00,66,00,65,00,65,00,65,
00,63,00,5F,00,5E,00,5C,00,5A,00,59,00,58,00,55,00,55,00,54,00,52,00,4F,

But I don't see how it converts that into Position/Torque/Speed lines. The max torq setting is around 30 during max acceleration and drops to zero at max speed (60) which falls off to zero as its target position. How does this work ?????

[l3v3rz]

I've just put a serial port monitor on it and its just using standard position move command. And its does return non zero values right at the start presumably when load is at the highest to get servo turning.

Request: 01/06/2009 20:32:08.28764 (+2.9227 seconds)
FF 14 7F 6B ÿ.k
Answer: 01/06/2009 20:32:08.28864 (+0.0010 seconds)
00 37 .7
Request: 01/06/2009 20:32:08.31264 (+0.0234 seconds)
FF 14 7F 6B ÿ.k
Answer: 01/06/2009 20:32:08.31364 (+0.0010 seconds)
28 37 (7
Request: 01/06/2009 20:32:08.33664 (+0.0215 seconds)
FF 14 7F 6B ÿ.k
Answer: 01/06/2009 20:32:08.33664 (+0.0000 seconds)
14 3E .>
Request: 01/06/2009 20:32:09.36264 (+0.0244 seconds)
FF 14 7F 6B ÿ.k
Answer: 01/06/2009 20:32:09.36364 (+0.0010 seconds)
01 46 .F
Request: 01/06/2009 20:32:09.38564 (+0.0205 seconds)
FF 14 7F 6B ÿ.k
Answer: 01/06/2009 20:32:09.38764 (+0.0020 seconds)
00 4F .O

[PedroR]

i'm coding a different tool to help in further reverse engeneering the procotol.

I am however having some trouble creating the checksum for the RBC command.
I had a look at l3v3rz code to see if he had any algorithm there but he has hard coded all the checksums

From the documentation "- CheckSum = Every each byte of [Command Contents] ‘Exclusive OR’ value."

I was using this algorithm: Checksum = Checksum XOR byteN
And would go though all bytes. However this doesn't work.

What happens is that if I XOR FF with FF I get 0 and XOR with 55 and get 55.

I think that what Robobuilder means is that you look at all 8 bits in each byte simultaneously and see if the number of 1s is odd or even for each bit positon.
Example:
FF FF AA 55 AA 55

1111111 - FF
1111111 - FF
10101010 - AA
01010101 - 55
10101010 - AA
01010100 - 54
-------------------
00000001

I'll have a try with this approach but would really appreciate your feedback.. Do you think this is the correct way to calculate the checksum??

Thanks
Pedro.

[i-Bot]

If you look to section 3 of the document, the checksum is only applied to the "command contents" field, which is the field before. It is not on the whole command.

[PedroR]

I missed that...

Thanks for pointing me in the right direction

[PedroR]

Finally GOT IT!

The "command contents" that section 3 mentions is the last byte before the checksum.

So the check sum is not really a checksum. Is just a repetition of the byte before.

There no calculation going on.
And for most commands the checksum is 01.

[i-Bot]

If the "command contents" field has length 1, then the checksum is the same as the command field. When the length is greater than one, then your caclulation is valid, to xor the bytes, but only those in the command field.

[l3v3rz]

Thats why in the code command_1B (one bytes commands) the command and the checksum are set to be the same

Code: Select all

           
serialPort1.Write(new byte[] { type,           //type (1)   
 0x00,         //platform (1)
 0x00, 0x00, 0x00, 0x01,    //command size (4)
 cmd,                //command contents (1)
 (byte)(cmd)      //checksum
},0,8);


But on button 10 which is a variable command to set all zeros I calculate the checksum (cs)

Code: Select all

               
serialPort1.Write(header, 0, 8);
serialPort1.Write(new byte[] {
   0x0E,        //type (1)
   0x00,        //platform (1)
   0x00, 0x00, 0x00, (byte)MotionZeroPos.Length,    //command size (4)
   }, 0, 6);
serialPort1.Write(MotionZeroPos, 0, 16);
byte[] cs = new byte[1];
for (int i = 0; i < MotionZeroPos.Length; i++)
{
   cs[0] ^= MotionZeroPos[i];
}
serialPort1.Write(cs, 0, 1);

sorry for for my lack of comments !

[tah1]

Well, if one measures the position vs time function (in practice an array of 2D coords), then one can simply differentiate the resulting function wrt time and compute the velocity. As there's no way to read "speed" from the wCKs this must be what they are doing. It's certainly what we are doing in our test/measurement process on the wCKs. Howe4ver, we are measuring position vs real-time (in this case in units of 1/10ms) rather than vs sample number (which can be quite irregular in time due to serial-port delays/traffic/processor overhead at both ends etc).
The sort of data one can then get is like this:
[EDIT by PedroR: find the image bellow as requested by tah1]


RED = position
GREEN = load
BLUE = velocity

t

On the reset function I can confirm it works

Here's a question: How does it produce the Position/Torque/Speed graphs...
But I don't see how it converts that into Position/Torque/Speed lines. The max torq setting is around 30 during max acceleration and drops to zero at max speed (60) which falls off to zero as its target position. How does this work ?????

[l3v3rz]

Yes I agree. I was hoping the were doing something more sophisticated from the look of the graphs. BTW I thought your write up was very informative and spot on about need for low torque values to be returned

cheers

[tah1]

...BTW I thought your write up was very informative and spot on about need for low torque values to be returned...

Thanks l3v3rz
t
PS I have emailed the graph I referred to, to Pedro for posting here in due course

[PedroR]

I've updated the original post and included the graph in the correct place to keep everything together. Please see above (I made a note in green mentioning my edit)

[tah1]

I've updated the original post and included the graph in the correct place to keep everything together. Please see above (I made a note in green mentioning my edit)

It turns out that if one uses 10-bit position read commands, there's enough resolution to be able to compute Acceleration, as well as velocity. This helps greatly with optimising control parameters. Here's an example plot that can be obtained this way:

[tah1]

Sorry - the Y-axis on that graph ought to be labeled "10-bit position", and not "8-bit position" as shown. mea culpa
t