Question: Emulating the IR Controller

[PedroR]

Hi all

We're working on a bridge for EasyVR (former VRbot) to Robobuilder and Bioloid.

The Bridge to Bioloid has become a bit more trickier than we (I) thought (beginner mistake...)

In any case, for the Robobuilder, what we're trying to use is EasyVR connected to an Arduino Mini. The role of the Arduino Mini is to understand the EasyVR serial protocol and then output a signal the Robot can understand.

We were planning to hack the head cable and send a signal emulating the IR remote control.
The problem is I have no clue at this point on how to emulate the IR remote control signals.

Do you have some information/code on how to do that?

(the other way is to go in through the BT socket using Remocon Serial commands but that's a bit too much I think; that's probably the way we'll have to go with the Bioloid though using Zigbee protocol emulation).

Thanks
Pedro.

[l3v3rz]

Sounds like you need i-bots clever PS2 controller board. Its the "brown board" with a PIC that converts PS2 controller board receiver to IR command sequences and plugs directly into the head.

See here:

http://robosavvy.com/forum/viewtopic.ph ... highlight=

[PedroR]

Hi l3v3rz

That's exactly it. I was just wondering if I could get a hold of the code.

We're using an Arduino Mini for now as the "bridge" and not a PIC but a look at the code might help understand the Remocon function.

From what we've seen so far the remote sends an ID along with the command itself (this way you can have multiple IR remotes operating without interfering with each other).

I hope i-Bot can share some of his knowledge on this subject

Thx
Pedro.

[l3v3rz]

[Edit: See below for correct link to code]

Also check out section 3.9 of the Robobuilder_C_tutorial on IR - gives details of the spec.

http://robosavvy.com/RoboSavvyPages/Rob ... Source.zip

Received data has 4 Byte information as the below.
Byte1 + Byte2 + Byte3(remote controller own custom code) + Byte4(data code)

Why not use a cheap PIC - rather than than whole arduino ??

[PedroR]

Hi l3v3rz

A cheap PIC is probably a better idea and I appreciate your siggestion. We're using the Arduino as it's easy to do mock-ups with it.

We also have access to some cheap Arduino clones.

Our intent is not to make a closed solution but to "show a way" (and eventually sell it as a set of parts if someone wants to reproduce it).

There are really talented people here on the forum and they'll certainly find more clever ways of doing it. Our intent is to show a working example. (if you recall I have discussed VRbot + Robobuilder in an old thread but it never came to live at the time).

Adding an Arduino to Robobuilder and tapping into the IR channel, has another advantage which is offering a way to replace ActionBuilder to add autonomous reactions to the outer world. (we all know ActionBuilder isn't really a very good tool). Arduino language is fairlly accessible and popular so we believe it may help reach out to other audiences.

If you tap IR into the command channel to direct the Robot you can then connect as many sensors and add as many logic to the Arduino/Robot as you want, using something that's within the reach of a not-so-technical audience.


A bit off topic, the native RBC control protocol is one of the best I've seen. (for this you'd need to tap into the BT socket though)

If you look at how the CM 730 operates in DARwIn-OP in conjunction with the FitPC you'll see it has a lot of similarities to the way the RBC protocol works with an external device to control and query the robot.
And the two products are completely opposite market segments.

Anyway, I'm getting a bit carried away here.

Thank you very, very much for the information and for pointing me in the right direction.

I'll post further news as we progress.

Regards
Pedro.

[i-Bot]

Hi, sorry for the delay, I had to seach brain and old PC for the file. 3 years ago Ouch!.

The file in the post from l3v3rz is for the Robonova. The one here is for the Robobuilder.
http://robosavvy.com/Builders/i-Bot/RobobuilderPS2.zip

This was created before the doc. from Robobuilder was issued and based on snooping the data stream, hence why I have slightly different values for the lengths of delays.

The biggest snag is that the RBC needs to be set to the address of the remote. I did this by using the existing remote, and capturing the address on the RBC. This address was then hardcoded into the PIC code. Easiest way to do this is probably to hook up an IR receiver on the arduino to learn the remote code.

I did just get my Robobuilder out of storage ready for the UK event in June. Interesting with the extra dof in the hip it has identical leg kinematic layout as the DARwIn-OP. I wrote DARwIn drivers for the wCK protocol and have working wCK_manager, as alternative to dxl_manager. Am now looking at the walking and motions conversion. Not sure if it will be done for the event ! Was hoping the new Roboard would be available by now for it.

They come fom different market segments, but may yet spawn a love child ( A DARwIn chick ) !

[PedroR]

Hi i-Bot

It's really interesting to find out that the Hip arrangement is similar to the one on DARwIn.

If I recall you custom built your own hip/leg parts using carbon fiber, right?
So from your post, you mean that your custom design is similar to DarWin's or is it the design of the "official" Robobuilder Hip Kit that is similar to Darwin's arrangement?

As for the Remote control ID, thank you for the tip. Indeed I was aware that different remotes send different IDs. What I was thinking about doing was taking advantage of the IR Remote "pairing" functionality that exists in the RBC control box that let's you change the associated IR Remote ID.

My idea was to use a generic ID and in the first use, you'd put the RBC in Remote pairing mode, and use some trick in the Arduino for it to send the necessary data for the pairing (I think it's pressing the STOP button).

I'll post my progress as I get along. Thank you very much!

Regards
Pedro.

[l3v3rz]

If you're using an arduino would it not be simpler to create a serial lead with a jack on the end and plug it directly into the RBC unit in the hole provided Then the VR commands simply need to generate the RBC serial protocol to call up motions etc. Has the advantage you can still use your IR remote as well. I assume the arduino can do 115200 baud rx/tx.

[i-Bot]

Hi Pedro. My carbon fibre brackets are same as "official" including hip kit.

[PedroR]

Hi i-Bot

Thanks for the information.

I'd also like to ask you another question (if you still recall) about these schematics http://robosavvy.com/Builders/i-Bot/RBC.pdf

I'm focusing on connector CN3 (the head connector) but I can't figure out what pin 4 is for. It is connected to the MIC 5205 which looks like a voltage regulator. However when I connect a multimeter to pin 3 and 4 I get 0V...


Hi l3v3rz

As for your suggestion the reason why we're not using the jack is due to signal level. Arduino is at TTL level and the Jack that connects tot he computer is RS232 so we'd need a level shifter.
We're using Arduino Pro Mini so it's even more stripped down than the regular Arduino.


As for my progress so far I've learned about IR signals (including TV protocols!), I've read through the docs/PDF you sent me about C coding and "kind of" understood what data needs to be sent.

I also found a nice Arduino library that relies on PWM functions ( http://www.arcfn.com/2009/08/multi-prot ... brary.html ) to be capable of doing the IR receiving and sending at very decent resolution.
I was considering a frequency of 40Khz which gives me 20cycles for 0.5ms if I understand correctly.

I'll see how it goes but to retain the IR remote functionality I was thinking about connecting the head IR receiver to the Arduino as well. This way we'd be getting data from VRbot and the IR receiver and relaying results to the robot thus having no loss of features.

Thanks
Pedro.

[i-Bot]

I think pin 4 is used to power the IR distance sensor. It is switched on/off by an I/O line from the processor. I used 5V on pin 1 for the power and a 3.3v regulator because my Logitech PS2 radio was 3.3V.

With just 3 wires, one 6 way head cable can do both the in and out cable from your arduino. The tiny connector pins are a pain to source and to crimp.

[PedroR]

Ah I see.

Thanks i-Bot!


I've been doing some reverse engineering of my own and it seems that the Remotes don't behave exactly as described in the docs (page 59 of the C source manual).
We have 2 remotes at the office so I could experiment with 2 different ones.

Apparently:
- Byte 1 is the Remote Control ID and not Byte 3. (at least it's the only thing that changes if you change remotes)

- Byte 2 seems to always be 01000000 (<strike>not sure if</strike> this means 2 <strike>or 64 though...</strike>).
The docs don't specify what this should be but the sample code makes use of this data to verify if the Robot knows this remote.

- Byte 3 seems to always be 0
The docs say this would be the Remote Control ID but I believe it's wrong (it seems it's byte 1) and the docs don't specify what Byte 1 should be either. Again, the sample code makes use of this data to verify if the Robot knows this remote.

- Byte 4 is the data Byte as documented

The order of the bits seems to be reversed (I'm not sure if this is correct though; probably a normal practice in IR communications but a newbie here).

From what I understand you receive the bytes in the correct sequence 1, 2, 3 , 4.

But each byte seems to have the least significant bit on the left (bits coming in reverse order) so for the STOP button I'm seeing the bits comming in this order 1 1 1 0 0 0 0 0.

<strike>If you make it into 11100000 this is 224.</strike>

If you reverse it, you get 00000111, which is 7 (STOP button) and corresponds to the code seen on the Serial Remocon Protocol as well.

[EDIT] I've confirmed it. Found the IR constants in the Sample C code and they're the same as those explained here http://robosavvy.com/RoboSavvyPages/Rob ... ommand.pdf

So I'm definitely receiving the bits from the least significant to the most significant. [/EDIT]

Other interesting bits:
- There always seems to be a final pulse/rise of 500us when the remote finishes sending everything

- There seems to be an initial pulse/rise of varying length but maybe this is noise I'm seeing.

I have some Excel Sheets with the analysis of the data and timings of rise and falls.
I won't be posting them as it's probably basic for most of you by now but if you'd like I can make them available.

Regards
Pedro.

[l3v3rz]

I think the manual (which is misleading) means the 3 data bytes (1-3 ) make the "custom" header and byte 4 is the data. The firmware checks all 3 bytes (referred to as H M and L) against an incoming sequence. I think you're right that the IR remotes sequence actually only differ in byte 1

When you save/remember the IR sequence it stores all 3 bytes (H/M/L) in flash and it saves the last 5 sequences sent to it. From the C:

Code: Select all

      if((gIrBuf[0]==eRCodeH[0] && gIrBuf[1]==eRCodeM[0] && gIrBuf[2]==eRCodeL[0])
       ||(gIrBuf[0]==eRCodeH[1] && gIrBuf[1]==eRCodeM[1] && gIrBuf[2]==eRCodeL[1])
       ||(gIrBuf[0]==eRCodeH[2] && gIrBuf[1]==eRCodeM[2] && gIrBuf[2]==eRCodeL[2])
       ||(gIrBuf[0]==eRCodeH[3] && gIrBuf[1]==eRCodeM[3] && gIrBuf[2]==eRCodeL[3])
       ||(gIrBuf[0]==eRCodeH[4] && gIrBuf[1]==eRCodeM[4] && gIrBuf[2]==eRCodeL[4]))

It checks all 5 of them against an incoming IR sequence custom header. So you could have different sequences for your IR controller and 1 for your arduino and they will both work.

[PedroR]

Hi l3v3rz

Sorry for the late reply and thank you for your information. In fact after reading your post and looking more clsoelly the 3 bytes are all coloured blue and the code does show it checks for all 3 bytes.

Interesting design decision. I guess they wanted to accomodate the possibility of 2^24 (16 777 216) robots on IR range

Anyway, back to the project in hand I was really curious to find out how they set the ID of the remote so I opened it up. (or "teared it down"; teardown seems to be mroe fashionable these days lol )

Here are the pics:

Disassembling a Robobuilder Remote #1 by RoboSavvy, on Flickr


Disassembling a Robobuilder Remote #2 by RoboSavvy, on Flickr


Disassembling a Robobuilder Remote #3 by RoboSavvy, on Flickr


Disassembling a Robobuilder Remote #4 by RoboSavvy, on Flickr

From the pics you can see there is essentially a PIC16F716 with some supporting circuitry.
I guess the ID is programmed into the PIC as I found no potentiometer or external variable component that would hint that this adjustment is external.
I was under the impression you'd get a HEX file and burn in into PICs one after the other but in this case there must be some other technique used.
(comments are welcome on how they do tis as I'm intrigued )


A thumbs up to the way the battery connectors are designed. very clean and effective design. The springs fit onto a specially designed holder on the plastic cover so there's n0 stress on the soldering when the batteries are inserted.

Regards
Pedro

PS: I'm in love with Flickr. It makes it so much easier to embed pics here on the forum and in addition you can open them in High res and browse all our gallery which is quite cool.