RoboSavvy Forum

How to read from Sound/Distance Sensor via PC commands

2010-03-28T19:40:06+01:00

Hello,

there is any new about get the sensors information with any kind of programming language? Perhaps in the new firmware since May to now ...

EDIT: Sorry, I don't nothing about L# before ... Now, I'm learning a lot!

Statistics: Posted by pepep — Sun Mar 28, 2010 7:40 pm

Detached the speaker

2009-05-11T07:21:45+01:00

Hi Pedro,

I detached the speaker so I can enjoy checking the mic/battery reading as I'm not much into the sound output. I noticed a curious response change for opcode 19 and that was byte #18 changing from a slightly dynamic 0x29 to a static 0xff. So it would seem that this #18 byte shows the volume setting for the speaker.

Hence for this and any other port that is absent or disconnected leaves an 0xff so if the guys find time to play with the responses keep in mind this assumption/observation.

Cheers

Mark

Statistics: Posted by Raymond — Mon May 11, 2009 7:21 am

Found Mic/battery msg packet

2009-05-11T02:09:28+01:00

Hi Pedro,

I finally got the buggers. It is : 19,0,0,0,0,1,1,1.

The response is byte #15 - battery, #17- Mic.

One drawback is that is also fires some speach at the same time (Which is why I dismissed examining this opcode more closely until today) saying 'Moving forward, then moving sideways'. If I cant find a way to disable sound easily by software I will detach the speaker if it becomes a nuisance.

Well now this is sort of done I guess I will go back to doing my job for a bit before I start with KHR.

Remember me when it comes to giving out discounts or Xmas gifts hint hint hint.

Cheers

Mark

Statistics: Posted by Raymond — Mon May 11, 2009 2:09 am

A pleasure to contribute

2009-05-10T18:48:27+01:00

Hi Pedro,

It was fun to find this 'backdoor' to further the ease at which users can play with Robobuilder and in kind boost sales I'm certain of this I am in complete agreement the manufactureres secrecy is counter productive to interest from non robotic enthusiasts. As much as I want to find the mic and possibly the battery level feedback I'm very comfortable with the findings thus far to develop a great interface where no mods are required.

I have been developing a master interface to control 3 different robotic brands, some of it duplicates your dll but you know developers like to do their own code lol. I wanted to share some of the functionality to encourage similar worx if you or the team find it of merit:

Robotis
1) Ability to speak to Dynamixel directly with servo packets
2) Ability to talk to Dyamixel through CM5/2+ commands
3) Ability to interact with BCP while running
4) Ability to take snapshots of scenes and motions on the fly to learn how to resolve different scenarios. In essense rewrote the motion builder using read/sync_write/reg_write
5) Aility to reprogram BCP on the fly
6) Design using Xbee Pro/Xtend which has up to 6/30mil rangerespectively

Robobuilder
1) Ability to speak to Wck directly with servo packets
2) Ability to talk to Dyamixel through Robobrick commands (Ongoing)
3) Ability to take snapshots of scenes and motions on the fly to learn how to resolve different scenarios. In essense rewrote the motion builder using sync_write/reg_write
4) Design using Xbee Pro/Xtend which has up to 6/30mil rangerespectively

Kondo-KHR1h
1) Develop PC ICS interface to allow serial connection for XBee hookup
2) About to packet sniffing to rewrite the comand interface from scratch

I really like Robobuuilder for the flexibility and price I quite agree although a sizeable part of ym investmet has been into Robotis as the servos are huge in torque but I'm developing a soft spot for Robobulder. I figured even if I stay with one kit from Robobuilder I'll share my findings fo those wh wish to take it to the limit. Sorry I didnt have the time to make a dll as I only included the functions in my propietary tool, but I'm sure your coding will be more readable and friendly!

Best Regards

Mark

Statistics: Posted by Raymond — Sun May 10, 2009 6:48 pm

How to read from Sound/Distance Sensor via PC commands

2009-05-10T17:32:39+01:00

Hi Raymond

Thanks a lot for all your work. it's amazing. the packet for starting charging was really unexpected but it's really nice. (maybe there's even a packet to read back the battery level...).

You are progressing at an amazing pace!

With regards to Robobuilder, we have worked with a few manufacturers on that side of the world and they have a posture that's much different from us Western habitants.
I've exchange a few emails with one of the guys from Trossen (with regards to a different matter/product) and they also share this opinion.

In my opinion I believe it would be in all their interest to even open source the firmware as this would be completely unique in the Robotics world and would certainly attract a lot more potential buyers who would simply like to play around with electronics and firmware.
The Humanoid Robotics is still a small market but it's now crowded with many humanoid products that simply try to copy each other and never bring anything revolutionary new.

I personally like Robobuilder very much. It seems to strike a very good balance between ease of use<->quality<->pricing<->design and I think there's a lot of potential in it.
It is my opinion that their firmware is very well thought out (I don't know of any other humanoid that can relay all input and output to the PC in such an easy way) but their understanding is different from ours and they choose to be very secret about the inner workings of the RBC...
I can try and ask them for instructions about the MIC but I would not keep my hopes too high as they have systematically discarded all requests of this kind...

I'm having quite a busy weekend but next week I'll try to put together some sample working software / VB classes that wrap this funtionality to start playing some more with it!
I'll also try to update the chart I created with all your new findings about return codes, etc.

I'll keep posting back

Cheers
Pedro.

Statistics: Posted by PedroR — Sun May 10, 2009 5:32 pm

Accel Opcode confirmed

2009-05-10T10:08:34+01:00

Hi Pedro,

I confirmed the accel is 26,0,0,0,0,1,1,1 with the prescribed header prefix. The x,y,z responses are byte responses #16, #18 and #20 respectively.

I am still lost in tracking down the MIC msg packet but at least we're making progress. Are the guys busy working on stuff or living in the real world ?? Hold back their pay for a week, wait no one is paid, darn it..

Cheers

Mark

Statistics: Posted by Raymond — Sun May 10, 2009 10:08 am

Opcode for charging

2009-05-09T07:08:03+01:00

Hi Pedro,

I'd forgotten one msg packet I identified prior and I'm including here for completeness sake:

20,0,0,0,0,1,43,43

This initiates the charging of the battery

Cheers

Mark

Statistics: Posted by Raymond — Sat May 09, 2009 7:08 am

Opcode update

2009-05-08T23:57:58+01:00

Hi Pedro,

Ater some more investiation I found some possible functions the following opcodes performs:

Op - 17,0,0,0,0,x,x,x turns off the run light maybe stops an action
Op - 23,0,0,0,0,2,x,x turns on the run light (This is redundant if initiates an action as that is documented with a remocon #+XX msg packet

Invite the guys to help us find the MIC msg this is driving me bokers now lol

Cheers

Mark

Statistics: Posted by Raymond — Fri May 08, 2009 11:57 pm

PC Control mode

2009-05-08T18:41:48+01:00

Hi Pedro,

Thanx a mil for the reassurance of a team effort which was my intent in sharing my fndings. I will respond to yout points in turn with my humble response:

1) Opcode 15 - You are right the changes are inconsistent in the value and it may be in fact linked to either IR/Voltage as the trigger

2) Opcode 20 - I now understand your thinking and I believe you're treating the controls of the sound/distance/mic as using the header prefix byte to enter into tha't state to then interact with those input/ouput ports as you would the WCK. This may not be possible as this is perhaps a 'back door'

I have again explored more comboniations and permutations within the last bytes even so much as not always keeping the last 2 bytes equal. So I'm failry confident the MIC is not managed under that prefix head bytes. Unless the MIC is purely a flag that changes when an entered value is satisfied, if that is the case it would be a great headache to confirm, unless the guys who wrote the C-Code can confirm their approach in interacting with the MIC perhapsi-BOT or l3v3rz?

On the note of Robobuilder perhaps not having all the documentation themselves that is indeed possible OR their roadmap requires they don't empower the end users to this extent. It's funny you mentioned the download section being empty, are they concerned with our findings? lol

Cheers

Mark

Statistics: Posted by Raymond — Fri May 08, 2009 6:41 pm

How to read from Sound/Distance Sensor via PC commands

2009-05-08T13:07:58+01:00

A) opcode 21,0,0,0,0,1,0,0 produces a response but no audio I wonder if this is the mic, but I haven't got it to change value when I make various sounds. 21,0,0,0,0,1,1-25,1-25 is the max range of sounds found with audible responses

The meaning of these values are documented in PDF Robobuilder has produced for Microsoft Robotics Studio. I tried to look it up yesterday but the download section of Robobuilder was empty for some bizarre reason. Once I have it I'll post it here. Deppending on the platform setting (HUNO, DOGGY, DINO) you'll get different sounds.

B) opcode 15,0,0,0,0,1,1-2,1-2 response value changes but I cannot find the trigger to these value changes
Do these values change consistently? Could it be some form of reading of the Remote control IR sensor?

With regards to your observations about the prefix you say the header should trigger / open a command window to receive the next 8 bytes.
What I mentioned was that, for sending the command to switch into to PC control mode you do not need to send that header so I still don't understand what was the criteria for them.

With regards to documenting the output there are no reasons to worry. I'm sure we'll all be happy to work together.

Finally with regards to your question about the MIC, the Robobuilder guys are very very reserved and evasive about the firmware code/documentation.
I myself start suspecting their inherited or bought the intellectual property and some of the features haven't even figured by them.

Pedro.

Statistics: Posted by PedroR — Fri May 08, 2009 1:07 pm

Further notes

2009-05-08T05:22:13+01:00

Hi Pedro,

I will try to respond as to new findings and to clarify some of my previous observations. I would like to thank you for putting in a more concise manner that all can comprehend at a glance.

1)
With regards to instructions for LEDs I didn't fully understand which leds are turned on. Are they the ones in the main RBC controller?
If so, there seem to be 12 possible combinations of byte 1 and bytes 6,7 & 8. This confused me as there are only 3 LEDs on the RBC I believe.
(Ah now that I remember some LEDs have multiple colours so their states are not just ON/OFF... could this be the case?)

Ans: The leds I found affected by this command are only the left leds not the pf1/pf2. Playing with 1/2,0,0,0,1-2,1-2,1-2 will show the various results and combonation of leds being On. I think 1,0,0,0,1,0-1,0-1 resets the lights to the single green

2)
I am not sure that we always need to send the FF FF AA 55 AA 55 37 BA prefix.
For PC control mode for example this prefix is not needed so the purpose of it is still a mystery...

Ans: Yes it is required as all this happens not in pc control mode. Apparently it opens up a new command interface to trigger the effects/responses

3)
Having looked at the way they organized the wCK protocol and assuming they used the same philosophy here there should be more OPCODES available.
The lowest OPCODE Raymond has found was 0x01 and the highest was 0x1F.
The OPCODE seems to be the first byte on the 8 byte sequence and the parameters are the last byte(s).

Ans: My feeling is this command interface was created primarily for using the remocon but that opened up use of this hence the non standard opcodes. I explored all 00-ff opcodes inclusive of all possible combinations of the last 3 bytes before settling on the 1-31

4)
With regards to the instruction packet that you suspect belongs to the ACC sensor, again, you have found 27 possible combinations for bytes 6, 7 & 8
Since the basic Acc Sensor readings are values for X, Y, X, what could these additional combinations mean?
Are they some sort of access port to additional I2C devices that one might assemble there? Would this even make sense?

Ans: I have a suspicion that like the distance response replicating the distance value in bytes 16 & 17(16=17), there may be something like 3 of the same value as a replicated check for the accel

New thoughts:

A) opcode 21,0,0,0,0,1,0,0 produces a response but no audio I wonder if this is the mic, but I havent got it to change value when I make various sounds. 21,0,0,0,0,1,1-25,1-25 is the max range of sounds found with audible responses

B) opcode 15,0,0,0,0,1,1-2,1-2 response value changes but I cannot find the trigger to these value changes

Unless stated otherwise all my values are in decimal

I will try later tomorrow if no one beats me to it to paste the results for each of the commands in the table you created. I have almost run out of options to isolate the mic msg packet. If this fails I have a question for the guys who created the C-Code for the mic, does the mic produce a value we compare or do we set a threshhold value and when it is reached a flag is set. If this is the case then another position has to have the mic value set by us and then the packet will simply set a flag byte to say sound reached.

The accel will someone with the accel installed check the response values for the unknown msg packets in the table. I can say for everyones records that opcode 31 produces for me a response that does not chaneg the last 3 bytes so if with an accel this changes then thats a great possibility.

Cheers

Mark

Statistics: Posted by Raymond — Fri May 08, 2009 5:22 am

How to read from Sound/Distance Sensor via PC commands

2009-05-08T01:43:44+01:00

Hi all

I have organized Raymonds findings about the instructions packets for the main RBC controller here: http://robosavvy.com/Builders/PedroR/Ro ... cs_XLS.zip
My idea is to keep updating the document so each can share his findings and eventually document the full protocol

With regards to Raymond's findings, after having organized everything, I do have a couple of questions/suppositions:

1)
With regards to instructions for LEDs I didn't fully understand which leds are turned on. Are they the ones in the main RBC controller?
If so, there seem to be 12 possible combinations of byte 1 and bytes 6,7 & 8. This confused me as there are only 3 LEDs on the RBC I believe.
(Ah now that I remember some LEDs have multiple colours so their states are not just ON/OFF... could this be the case?)

2)
I am not sure that we always need to send the FF FF AA 55 AA 55 37 BA prefix.
For PC control mode for example this prefix is not needed so the purpose of it is still a mystery...

3)
Having looked at the way they organized the wCK protocol and assuming they used the same philosophy here there should be more OPCODES available.
The lowest OPCODE Raymond has found was 0x01 and the highest was 0x1F.
The OPCODE seems to be the first byte on the 8 byte sequence and the parameters are the last byte(s).

4)
With regards to the instruction packet that you suspect belongs to the ACC sensor, again, you have found 27 possible combinations for bytes 6, 7 & 8
Since the basic Acc Sensor readings are values for X, Y, X, what could these additional combinations mean?
Are they some sort of access port to additional I2C devices that one might assemble there? Would this even make sense?

Lots of questions.

Cheers
Pedro.

Statistics: Posted by PedroR — Fri May 08, 2009 1:43 am

Testing procedure

2009-05-06T16:11:02+01:00

Hi Pedro,

I knew this was a cool find and it will help complete the functionality of your dll nicely! The testing procedure unfortunately was as follows:

Looking at action builder and some assumptions of the 4 digit command and mapping back the last 3 digits of the remote msg packet. I tried numerous settings to confirm the 3rd to last byte more often than not remains at '1'. Also the 1st byte after byte xBA proved to be the command byte and the 3rd byte when applicable as thevalue to be referenced by the command (I think for the sound/mic ,accel and voltage).
Honestly after those weak assumptions I tried numerous combinations not changing the prefix bytes. to validate my assumptions. Sadly it took me 12hrs, so there was some grunt work.

Lastlty I of course was sniffing the com port and when I sent an experiemental packet I looked for a response and if no response I moved on. I can only guess Robobuilder didnt want to release this as yet or didnt have the time to publish it, maybe the guys who developed it moved on and not every bit of knowledge was readily available.

I was giddy like a kid once I found the distance sensor packet! I almost almost wanted tokeep it to myself but after seeing how hard you guys worked I figured it belongs to everyone.

Cheers

Mark

Statistics: Posted by Raymond — Wed May 06, 2009 4:11 pm

How to read from Sound/Distance Sensor via PC commands

2009-05-06T08:06:21+01:00

Hi Raymond

Your findings look like awesome news.

You mean these packets work with the standard Robobuilder firmware?

For some reason the Robobuilder guys never documented or released information on this....
If you have actually found the ACC and distance packets I have to say I'm really excited and I have ideas popping up all over my brain

May I ask what was the testing procedure you used to find this out?

Thx
Pedro.

Statistics: Posted by PedroR — Wed May 06, 2009 8:06 am

SOund output msg packet

2009-05-06T03:21:57+01:00

Woops forgot one msg packet

This is for sound output

21,0,0,0,0,1,1/xx,1/xx

Statistics: Posted by Raymond — Wed May 06, 2009 3:21 am