ir_trigger

38 posts / 0 new
Last post
android78
android78's picture

Thanks for the work Helibot,
That is interesting. My analysis (of the code) seems to indicate slightly different. The mappings seem to be:
bit 0 = Left Sensor
bit 1 = Right Sensor
bit 2 = Middle Sensor
bit 3 = Short Range/Long Range

Although, there may not be direct mappings as the code I am seeing may be using a switch/case statement so the mappings could be program generated.
One other interesting thing is that the robot only appears to have 3 IR sensors; one right beside each ear and one on the 'chin'. This would indicate to me that they are either varying the intensity of an IR transmitter or changing the sensitivity of the sensors to discriminate between long range and short. This backs up my theory of a single bit for long/short, and single bits for each sensor.
I haven't had much time to play of late (got sidetracked programming a personality editor for Mr Personality), but I can't believe that I haven't actually checked if the front IR actually works for short range, only long range. Has anyone checked this?

BTW. with regards to the large number, this appears to be due to the binary (RSM_IR_TRIGGER_L_D) which checks the variable file RSM_IR_TRIGGER_L_D_VAR not recognizing the the file is empty and so just returns the value at the memory location where it thinks the file stream should be. This file isn't populated because mediadaemon never writes to it under any circumstances.

Helibot, Could you check if the file RSM_IR_TRIGGER_L_D_VAR ever actually has a value in it. If it does, you may at least have a different firmware with different mediadeamon and I'd be VERY interested in getting a copy for disassembly/analysis.

Cheers,
Android

Helibot
Helibot's picture

Hi Android,
Gee I had fun tonight - I have proved that the middle sensor does work AND that mediadaemon WILL set the RSM_IR_TRIGGER_S_D_VAR correctly!!. The mapping you had is almost right. To get it to trigger I had be very careful where the object was placed. Here are some details of my investigation :-

I looked at my raw data again (with your mapping in mind) and also remembered to apply some physics - (which I forgot about the other night!). I did some more testing and I am now sure my data conforms to this mapping:-
bit 0 = Left Sensor
bit 1 = Middle sensor
bit 2 = Right Sensor
bit 3 = Short Range/Long Range

I used a white 1 1/2" foam ball as the object to put in front of RSMedia (I will explain why later!)

Put the ball in font of his left eye and I get a 1.
Put the ball in font of his right eye and I get a 4
Put the ball in font both eyes and I get a 5
move the ball away on the left I get C
move the ball away on the right and I get 9
AND if I very carefully hold it dead centre I can get 3,6,7
AND if I very carefully hold it dead centre and very low I can very rarely get 2
If I put something really big in the way I get F

So I now believe the middle sensor IS working and the encoding is as above.

But what was the physics I mentioned? Well during my previous test I forgot that the IR receiver must receive a reflected IR signal (that is transmitted by the IR LEDs on his forhead!) During my last test I was just covering the middle sensor , which of course just blocked all the light and of course it didn't trigger. But when block the eyes enough IR light was being reflected down to the left right sensors and they triggered.
Using a ball is a good choice because it is round and will generally always bounce some light back to the sensor. (And of course flat shiny objects reflect the light at different angles and will give unstable and incorrect triggers.) So using a white foam ball gave nice repeatable readings!!

So next I propped the ball infont of RSMedia and positioned it so I was getting a 2 from my test program. I then restarted RSMedia main code, he detected data of 2 and set the variable - here is some log from the serial port.

IRData is 2
IRData is 2
IRData is 2
...
# /mnt/sd/Application/dump /tmp/state//RSM_IR_TRIGGER_S_D_VAR
Opened file /tmp/state//RSM_IR_TRIGGER_S_D_VAR
1 0 0 0
Num Bytes = 4

#ls -al /tmp/state/RSM_IR_TRIGGER_S_D_VAR
-rw-r--r-- 1 root root 4 Jan 1 01:53 /tmp/state/RSM_IR_TRIGGER_S_D_VAR

So you should be able to make it trigger as well. Try a ball and hold it about 3 inches from his chin, and down below his eyes.

Helibot
Helibot's picture

One other interesting thing is that the robot only appears to have 3 IR sensors; one right beside each ear and one on the 'chin'. This would indicate to me that they are either varying the intensity of an IR transmitter or changing the sensitivity of the sensors to discriminate between long range and short. This backs up my theory of a single bit for long/short, and single bits for each sensor.

Hi Android,
I was also thinking about how the IR sensors work. There are three IR Leds in his forhead, they could be pulsing them at diffent rates and detecting the rates at the sensors. The middle IR LED on his forhead is set back a bit so it transmits in more of a beam, so maybe its used to transmit the pulses for long detection?
Actually you can see the middle LED is flashing at a slower rate if you look at it through a digital camera - all three LEDS look white (only when RSMedia has his EYES ON). But the middle LED seem to be pulsing?

Cheers
Helibot

android78
android78's picture

That's GREAT news Helibot. The only comment I have is with regards to the variable that you're looking at. The file that, for me, is never written to is for the LONG RANGE front sensor RSM_IR_TRIGGER_L_D_VAR (not the short range RSM_IR_TRIGGER_S_D_VAR). This file is never referenced in the mediadaemon.
Interesting ideas about the IR transmitters on the forehead too. We should be able to test that simply by covering the sensor with something and see if that prevents him seeing distance.

Cheers,
Android.

android78
android78's picture

Ok, I took another look at the code and it appears your mapping is correct (middle being bit 1, not 2). In my current tired state, the following is what I've found:
0x01=Short Right
0x04=Short Left
0x02=Short D(irect???)
0x09=Long Right
0x0c=Long Left

0x0F or 0x05 = Short Left
0x0F or 0x05 = Short Right

0x0d = Long Right
0x0d = Long Left

So the olny time when the middle sensor will produce a result in the variable files is when only the middle sensor is active. The other interesting thing is that the long left and long right will not produce a result when the middle is.
It's really looking to me as if they have defined the mapping in their code variables to the wrong value. Done something like define it as:
RSM_IR_TRIGGER_L_D_MASK 0b00001001
rather then
RSM_IR_TRIGGER_L_D_MASK 0b00001010
as it should be.
I'll try editing the code again if I have time and see if I can get it to at least spit out some value for the middle long sensor.

Nocturnal
Nocturnal's picture

Memory suggests Helibots interpretation of the bits is correct. This is not the first time it has been covered. Somewhere around (here or on other sites) are a thread or two on the same topic. 0xF is sort of a special case, its the "flinch" response. it means something is close to his head, reflecting to all 3 sensors.

If I am remembering correctly, you will never get an 0xA. The "center" receivers prime purpose is to detect an object close to the face (ie "flinch"). I don't know if it is checked or not when the center led (distance) is active, but you may notice its angled downwards. The idea being, the further away from the face, the less likely it is to pick up a reflection.

Andre_S
Andre_S's picture

 

...Sorry not read page 2

Pages