How to read from Sound/Distance Sensor via PC commands

[Raymond]

Hi Guys,

Can we use the WcK command to read Input from the head sound/distance sensor and if so what ID is assigned. Secodly if we cannot ue the WCK what msg structure will enage the sensor.. Thirdly what comand/msg structure exists to interact with the Axis accel.

Please keep in mind this is via the pc msg to the com port

Thanks

Mark

[PedroR]

Hi Raymond

It is currently not possible to do what you request using the standard firmware for these reasons:

- The wCK protocol is meant to communicate with the Servos only.
- The distance sensor (and acc sensor) are attached to the main RBC controller and thus are not part of the wCK protocol specification.
- There is currently no instruction for the main controller board that would return the value of the distance sensor.

I myself have requested this feature a couple of times from Robobuilder and this last time they seemed more receptive.


To implement what you request there are two possible solutions:
1)
Using the standard firmware, you can connect the distance sensor to the IO port of any servo (instead of connecting it to the RBC controller board).
The wCK protocol includes instructions to read the value of the A/D port on a SERVO.
Details on the servo IO ports and querying them are posted here: http://robosavvy.com/forum/viewtopic.php?t=3324

2)
Alternatively you can use the home grown OS/firmware that the guys here at the community have been developing.
This is a replacement firmware for Robobuilder that aims at implementing the base functionality of the standard firmware and extend it beyond.
Using this firmware you will be able to read the distance sensor from the COMM port, send commands to the servos using the wCK protocol, and I also believe you can read the acceleration sensor, all these through the COMM port.
Details on that here: http://robosavvy.com/forum/viewtopic.ph ... c&start=30

With regards to the sound sensor I really don't know. Maybe the replacement firmware has some built in functionality for this.

I'd also like to mention the the Bluetooth module for Robobuilder.
It lets you connect to the Robot through a wireless / virtual COMM port, essentially replacing the need to use the COMM cable for all these operations and control from the PC.

[Raymond]

Hi Pedro,

Thanks for such a concise response. I have a couple questions:

1) If I was to explore the hooking up of the psd sensor to the wck AD I/O is it a straight pin to pin connect as I saw in that discussion you had to use some resistors or was that for testing only and not required when I solder pins to permit the 6 pins for the psd sensor from Robobuilder.

2) If I use the teams custom firmware will we be able to comunicate with the WCK servos using the msg commands defined in the wck manual?

Thanks again for taking the time to be so precise in listing the options, much appreciated.

Cheers

Mark

[Raymond]

Hi Pedro,

I missed the part where you stated the wck protocol is supported which is cool. My only question now is what msg format is required to gain response from the sensor/accel in the custome firmware.

Cheers

Mark

[PedroR]

Hi Mark

To answer your questions:
1)
With regards to attaching the distance sensor to the wCK analogue sensor port:
- You do not need to use a resistor. I used one in my testing because I was not sure how the A/D port was set up.
However, I have tested and can assure no resistor is needed.

- With regards to attaching the sensor, yes it is a pin by pin match.
You solder the three wires (GND, Vdd, and Sensor/reading) directly to the solder pads on the servo I/O ports.
It is a normal A/D port. Any 5V A/D sensor will work there.
If you're into experimenting, you can add as many sensors as you'd like. Robosavvy has some A/D sensor packs here: http://robosavvy.com/store/product_info ... cts_id/368 (full list here http://robosavvy.com/store/advanced_sea ... rds=sensor )

With regards to the 6 wires in the head cable, please note you do NOT need the 6 wires for the PSD sensor.
The head includes the PSD sensnor and the IR sensnor (for the remote) so that's why there are 6 wires.
For the distance (PSD) sensor you only three of the wires. If you disassemble the head you'll see the PSD sensor has a 3 pin JST connector free, so maybe what you can do is connect a JST cable to the PSD sensor and don't even touch the head cable.
Pictures of a disassembled head are available here: http://robosavvy.com/forum/viewtopic.php?t=3420 (you can see the JST connector there).
The JST connector seems to be connected in parallel with the head cable.

2)
I'm not very familiar with the custom firmware as I have not yet played with it myself.
I have been keeping up with the thread and discussing additions, etc.

As I understand, the custom firmware implements a kind of "terminal-like" method.
You can install the firmware on the robot and open up Hyperterminal (or similar) and start getting feedback and sending commands (TEXT commands).

I think there are commands that will return the status of both the PSD and the ACC sensor.

Also, if you want to send commands directly to the wCK servo bus (wCK protocol commands) you issue and "x" or "X" command followed by the hexadecimal representation of the sequence you want to send.

In practice what you need to do is write some form of parser that sends the command to get the status of ACC/Distance and then parse the textual response you'll get.

The cool thing though is that you can play and test yourself all the commands using Hyperterminal and then once you understand it start coding for it.


Pedro.

[Raymond]

Hi Pedro,

Your feedback was awesome that can truly get me the capability I'm looking for. Attaching sensors at least soldering is new to me but I recon after the first it should become much easier. I was not expecting your response so quick so I stayed up last night like a moron and found the following msg's to aid those who wish to control the Robobuilder via pc without having to upgrade firmware or mod their servos (Solder novices like myself).

1/2,0,0,0,0,2,2,2 - leds (1/2,0,0,0,0,1,1,1) - toggle till only one led on
15,0,0,0,0,1,1/2,1/2 -?
17,0,0,0,0,1,1,1 - ?
31,0,0,0,0,0-3,0-3,0-3 - ?
22,0,0,0,0,1,1,1 - distance response bytes # 16 & 17 give the distance
20,0,0,0,0,1,0-63,0-63 - remote buttons
26,0,0,0,0,1,1,1 - ?
11,0,0,0,0,1,1,1 - ?
12,0,0,0,0,1,1,1 - ?
16,0,0,0,0,1,1,1 - pc control mode
18,0,0,0,0,1,1,1 - ?


The prefix is the FF FF AA 55 AA 55 37 BA described in the remote pdf and the next 8 bytes (shown above in decimal) appended in a single string and you will get the desired result.

Now I pass the hat for someone to find the Mic msg packet to get a response on the sound level. The msg packets with a question (?) indicate a response port not yet configured or I cant confirm what its talking to, but I have a suspicion that 31,0,0,0,0,0-3,0-3,0-3 may be for the accel which I didnt connect as yet.

Look forward to a resilient genius to point me in the right direction.

Cheers

Mark

[Raymond]

Woops forgot one msg packet

This is for sound output

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

[PedroR]

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.

[Raymond]

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

[PedroR]

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.

[Raymond]

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

[PedroR]

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.

[Raymond]

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

[Raymond]

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

[Raymond]

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