Full Official Documentation for the RBC protocol available

[PedroR]

Hi all

Robobuilder has (finally) released a PDF document with the documentation of the RBC protocol (ie querying the RBC controller box through the COMM port or Bluetooth on the PC).

The file is available here http://robosavvy.com/RoboSavvyPages/Rob ... _v1.13.pdf

The manual explains the basic packet structure and details the following operations:
- Read the Acc Sensor data

- Read the Distance Sensor.

- There is state that fires an event and sends a packet when:
.... Remote Control Button is pressed (returns the button that was pressed)
.... Sound level reaches a certain threshold (also details how to setup the threshold)
.... Pressing one of the buttons on the RBC.
I haven't yet understood what is the timeframe when these commands remain active.

- Play motions (I think it's a packet different than what had previously been released in the Remocon protocol)

- Play sound (if you have an RBC with speaker)

- Check the execution status (don't know what they mean "execution status" right now; will have to check..)

I must say the way the firmware is designed seems quite clever to me.

I'll have to compare this against the findings of forum member Raymond as he may have uncovered additional packets/operations not documented here.
There is also still no documentation on writing motions and actions to the flash memory.

The manual has plenty of info to keep me busy for the next month.
My first project will be creating a tool to test all these packets.

Regards
Pedro.

[Raymond]

Hi Pedro,

I don't know if to thank Robobuilder or curse them for making me learn it all the hard way, inclusive of the chksum calculation. In a nutshell the only two opcodes I learnt from the document is :

op 23
op 24

Purely because I kept my command length static at 16 bytes. I would like to share with my fellow roboteers to exercise caution with the commands that state will repeat until a next command is entered. I was forced to promptly issue a next command to halt as it tends to overflow the comport buffer and corrupt system memory crashing the PC. I messed slightly trying to find the proper battery opcode but got bored. If it exists I'm sure the guys will find it in time 2 days before Robobuilder publishes again of course.

I don't think opcode 30 is correct maybe they meant op 31/15 and 1=finished, 2=running, who knows or cares lol.

Laslty opcode 26 for accel is working in firmware 2.15 so I do not know what they are talking about, unless the firmware is not reporting values properly from the accel?

Thanks for pushing the manufacturer.

Cheers

Mark

[PedroR]

Hi Mark

I had been asking for this info for the past 6 months.
I think the fact that we (you) were doing reverse engineering on ourselves has pushed them (I actually sent them the links to our forum thread).

Anyway, I agree with you on the opcode for the acc sensor.
Maybe the opcode you found is for something more.... You did find 27 variations that work with that opcode so maybe it does something else.

They also make a note under the acc sensnor, saying it requires firmware 2.17 and that they "will open sooner or later". I believe this refers to open sourcing at least part of the firmware but again I have no idea when, what or how....

Also with regards to the commands that keep sending a response thank you for your input on the overflow.
May I ask what firmware version you are using?
If it's the latest I might ask them to add a delay (of something like 400ms) in RBC code to avoid this.

Regards
Pedro

[Raymond]

Hi Pedro,

I agree completely on your assumptions as to their motivations. On the matter with the continuous feedback opcodes I didn't want people being turned off with their PC's experiencing the blue screen when playing with some remote commands.

I'm using Firmware 2.15. I have 3 x RBC's with and without Speakers. All the commands work on 2.09 as well (havent confirmed accel on 2.09 as yet tho)

Good idea on the delay for the continuous response commands. Although for me I'd ask them to remove the continuous as we can and will issue the command when we want feedback, it's not like we're streaming, perhaps a flag in the command packet to request continuous or not.

I know the battery feedback is something more techies will want and what I've noticed for that opcode is the lowest value that the unit still responds safely is value = 148. So the value returned from opcode 19 - 148 is the actual charge index which counts down.

Cheers

Mark

[i-Bot]

Hi,

To claim a few of the missing commands found by Raymond, and to answer the question from Pedro on the flash download, here are few more command descriptions. Maybe Robobuilder can issue a full full version.

I did not yet try these from the PC.
http://robosavvy.com/Builders/i-Bot/RBCommands.pdf

[i-Bot]

Updated .pdf above to include the reading and setting of zeros.

Not sure why only works with 16 servos. Maybe beacuse it is only used for Huno.

Maybe we need to make a tidy complete list. The different parts cause some confusion between decimal and hex values. What do you think ? I can share the .doc if anyone wants to use it.

[PedroR]

Hi Richard

Thanks for the additional info.

Someone had already suggested creating a Wiki for Robobuilder with all the information we have already on the forum (connector models, servo protocol, IO ports and IO port usage, additional DOF, RBC protocol, some adapter boards, custom firmwares, etc etc).

I know Robosavvy has a public Wiki system installed so I'll have a look into it and share it with you once I have the details.
I'll have to check with Limor. As you know when I came to work with Robosavvy the system was already up and running so sometimes I'm still playing catch up on the less used features (such as wiki).

Regards
Pedro.

[l3v3rz]

I've upload a simple C# . NET program that enables the user to send PC remote commands and operate in Direct mode - reading and set servo position. Comes with full source. Built using c# 2008 - but should work with earlier versions. Really for people who want to experiment with C# rather than being a full program. Also I notice some of the commands only work with V2.15 (i.e. reset memory and read distance to name two I tried). I've included an Exe for those that just want to try it out.

Use at your own risk :0

I created it using C# Visual Studio Express 2008 which is a free download from Microsoft.

Update: Version0.21 now uploaded - includes Read and Zero Positions among other things
http://robosavvy.com/Builders/l3v3rz/PCControlMode0.21.zip

[PedroR]

Just to update my post about the wiki, I0ve already started a WiKi section at robosavvy dedicated to Robobuilder.

It is here http://robosavvy.com/site/index.php?opt ... obobuilder

There is also a forum thread about that here: http://robosavvy.com/forum/viewtopic.php?p=19882

[Raymond]

Hi Pedro and Team,

I wanted to reflect a correction to Robobuilders comment concerning the accel requiring firmware 2.17 and up to be recognised via remote command packet msg's. The Accel is recognised in the 128YNN but not the 128NNN although each is loaded with same firmware be it 2.09-2.15. Also I've found the the packet which I found that reports the mic and battery levels seems more sensitive for the mic than the continuous stream packet command Robobuilder published.

Just thought I'd share these little observations...

Cheers

Mark

[l3v3rz]

perdro,

When using the protocol in DC mode and sending wCK commands to read the position of a servo the wcK protocol says its should return two bytes, the load and the positon, but the load byte is always zero? Is this not supported on the current servos? Is there any information from Robobuilder about how to read the load on the servo ?

What I'm trying to do is as I close the gripper to sense the load increase so that it knows when it has grasped an object

thanks

[PedroR]

Hi l3v3rz

The load is a parameter that only seems to report anything above a certain threshold.
We have another customer who was trying to use the Load reading for a similar project and his findings seem to indicate that load is only reported above a relatively high threshold.

Unfortunately I guess it won't be possible to do as you had thought. However, may I suggest an A/D pressure sensor that you attach to the gripper and connect to the servo IO port?

[l3v3rz]

I don't suppose you could ask Robobuilder if theres an undocumented command to set the load threshold ?

cheers

[PedroR]

I'll try and ask that. I hadn't thought of that being a possibility.

However please note that the guys on that side of the world sometimes answer sometimes don't.... It's really hard to predict what they'll do or release. (I should program a shortcut key for this sentence as I seem to be writing it on a daily basis... :S)

[PedroR]

The other person who's doing the project with Robobuilder servos that needed current feedback has documented a list of errors and incompletenesses in the wCK Manual v1.7.

The document is available here http://robosavvy.com/Builders/PedroR/wC ... nesses.doc
(he seems to have found, for example, that load/current output that l3v3rz was mentioning is only reported when it's above ~350mA)

I believe he's already posted here under tah1.

If you have the time, take a look at it and share your thoughts. I have forwarded it to Robobuilder but I haven't had any reply yet.

Pedro.