RoboSavvy Forum

Position/load/time plots

2009-06-11T10:46:25+01:00

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

Statistics: Posted by tah1 — Thu Jun 11, 2009 10:46 am

Full Official Documentation for the RBC protocol available

2009-06-05T00:35:06+01:00

PedroR wrote:
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:

Statistics: Posted by tah1 — Fri Jun 05, 2009 12:35 am

Full Official Documentation for the RBC protocol available

2009-06-04T13:49:07+01:00

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)

Statistics: Posted by PedroR — Thu Jun 04, 2009 1:49 pm

Full Official Documentation for the RBC protocol available

2009-06-03T23:46:25+01:00

l3v3rz wrote:
...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

Statistics: Posted by tah1 — Wed Jun 03, 2009 11:46 pm

Full Official Documentation for the RBC protocol available

2009-06-03T23:52:08+01:00

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

Statistics: Posted by l3v3rz — Wed Jun 03, 2009 9:24 pm

Load/Position/SPEED measurements ion wCK servos

2009-06-03T16:55:18+01:00

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

l3v3rz wrote:
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 ?????

Statistics: Posted by tah1 — Wed Jun 03, 2009 4:55 pm

Full Official Documentation for the RBC protocol available

2009-06-02T19:42:12+01:00

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

Code:: 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:: 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 !

Statistics: Posted by l3v3rz — Tue Jun 02, 2009 7:42 pm

Full Official Documentation for the RBC protocol available

2009-06-02T17:47:37+01:00

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.

Statistics: Posted by i-Bot — Tue Jun 02, 2009 5:47 pm

Full Official Documentation for the RBC protocol available

2009-06-02T17:34:37+01:00

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.

Statistics: Posted by PedroR — Tue Jun 02, 2009 5:34 pm

Full Official Documentation for the RBC protocol available

2009-06-02T16:48:53+01:00

I missed that...

Thanks for pointing me in the right direction

Statistics: Posted by PedroR — Tue Jun 02, 2009 4:48 pm

Full Official Documentation for the RBC protocol available

2009-06-02T16:46:38+01:00

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.

Statistics: Posted by i-Bot — Tue Jun 02, 2009 4:46 pm

Full Official Documentation for the RBC protocol available

2009-06-02T16:24:32+01:00

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.

Statistics: Posted by PedroR — Tue Jun 02, 2009 4:24 pm

Full Official Documentation for the RBC protocol available

2009-06-01T20:47:32+01:00

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

Statistics: Posted by l3v3rz — Mon Jun 01, 2009 8:47 pm

Full Official Documentation for the RBC protocol available

2009-06-01T20:19:19+01:00

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 ?????

Statistics: Posted by l3v3rz — Mon Jun 01, 2009 8:19 pm

Full Official Documentation for the RBC protocol available

2009-06-01T16:35:11+01:00

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.

Statistics: Posted by PedroR — Mon Jun 01, 2009 4:35 pm