38 posts / 0 new
Last post
dogbed79's picture

In the macro mode of the RSM, under conditions, there is ir_trigger. Has anyone tried this condition. If so, did it work? I can't get it to work. All the other conditions work but not the ir_trigger, whether it be right, left or center. What does ir_trigger mean?

Nocturnal's picture

At a guess, it means does something enter his IR Vision (Left, Right or Center).

Robert Gilmore
Robert Gilmore's picture

I have no clue- haha.

Good luck though; ask Milw.  He probably can help. 

milw's picture

no, I'm afraid I haven't tried to use it either.

android78's picture

This is a really old thread, but just wondering if anyone has an update to this. I only got my robot yesterday and managed to make a macro that (with altering the script once saved from the RS media editor) calls it self. Basically it just loops checking the IR sensor and then saying either "nothing to see" or "found something" depending on the result. So far, no matter what I put in front it just says "nothing to see". I think the problem may be that I've been using 'audition' from the media, personalities menu, and IR is disabled in media mode. I'll have to check this out when I get home though. Would like some others opinion though.

Grandlarseny37's picture

why would running a macro from the audition menu make any difference?

Santa Matt
Santa Matt's picture

I have had some strange returns from the front looking IR sensor. Try altering your script to use one of the side sensors and see if it works better.

Santa Matt

android78's picture

Thanks for the tip santa.
Indeed It seems that the forward sensor (long at least) doesn't work.
So... I pulled his head apart and found interresting things:
- the sensor is ok. Plugging the forward sensor into the right sensor socket and the right trigger works.
- similarly, plugging the right sensor into the middle doesn't trigger it.
- the sensor output is attached to the unshielded ribbon cable, 6th pin from the RIGHT (7th from the left) when looking from the front of the head. The other end you can count down 6 lines from the top when looking at the cable with writing right way up.
- All the connections to the sensor appear to be right. Electrically (from the camera board at least) it appear right.

So.. this leave two ideas:
1. It's a software issue. They are checking the wrong input line.
2. It's a hardware issue on the main board. the line may not be attached or is attached incorrectly.

Anyone who has opened up the main part of the robot care to assist?

Santa Matt
Santa Matt's picture

I believe it to be a software issue. Has anyone else investigated this? At this point I have no idea if this will be correctable or not. Perhaps a quick support mail to WowWee?

Santa Matt

android78's picture

hmmm... I wonder if they have just messed up the input mask for the front sensor. Have you been able to spit out the variables for the inputs so see if there's anything odd with them. As I have seen posted previously, one of the variable for max arm position appears to control the wrong arm which indicates they have just made the variable too large which is triggering another line.

Santa Matt
Santa Matt's picture

The variables are clearly marked once you get into the scripts.
IR long range center RSM_IR_TRIGGER_L_D
IR short range center RSM_IR_TRIGGER_S_D
IR long range left RSM_IR_TRIGGER_L_L
IR short range left RSM_IR_TRIGGER_S_L
IR long range right RSM_IR_TRIGGER_L_R
IR short range right RSM_IR_TRIGGER_S_R
When I wrote a script to test these one of the center sensors returned a strange 6 or 7 digit number. All of the rest returned a 1 or 0 depending on if it saw something. I also thought perhaps the bit masking was off, but that long number does not change when it can or can't see something. Kind of a bummer.

Santa Matt

android78's picture

From what Nocturnal pasted in the following, it appears that there may be RSM_IR_TRIGGER_L_D_VAR in /buffer/tmp/state that it could be worth investigating. Also, in that same directory, I see linein_state that is something we should checkout:

Just out of interest, I would like to see what is in the files in /buffer/tmp/stat directory when the middle sensor is 'seeing' something. I haven't got an SD card for my robot yet so can't do this myself.

BTW, is it the same problem with RSM_IR_TRIGGER_S_D as RSM_IR_TRIGGER_L_D? ie, can we confirm the processor is seeing the line at all?

android78's picture

Just a thought. Could you send me the code for RSM_IR_TRIGGER_L_D and RSM_IR_TRIGGER_L_L (I'm aware it's probably compiled binaries) and I'll have a dig around to see what I can find.

I wonder if others on here have managed to get the front sensor to work. Maybe there are only three of us with the same version (firmware and/or hardware) that has this issue that I'd love to be able to rule out.

android78's picture

When I say code, I mean binaries. They should be in /usr/bin/robot/state directory. I see that RSM_IR_TRIGGER_L_D and RSM_IR_TRIGGER_L_L are actually the same size, so feel we should be able to just do a binary compare to see the different variable or maybe even the mas being used. Then we may be able to experiment with a binary editor (ultraedit or similar) with changing this to see if we can fix it. Just a thought.

FreddyA's picture

I dont know what firmware or harware version I have ( I have 2 rs medias), but I also have the IR issue with both robots. I do have a sd card but I wouldn know what im doing. I could try following some steps if you need.

android78's picture

Hi Freddy,
I sent you a private message with more details, but so that other on here know...
I believe that you can use the test script under
"*Example bodycon script (used to run the 'hello' executable:-"
from the following thread:
... BUT replace the line:
./hello > /mnt/sd/hello.txt
cp /usr/bin/robot/state/* /mnt/sd/*

My belief is this should copy all the binary files from that directory to the sd card. If that doesn't work then may need to call it as:
/bin/cp /usr/bin/robot/state/* /mnt/sd/*

If Nocturnal is watching this thread, I'm sure he could confirm this. lol

FreddyA's picture

It made a hello.txt doc with nothing, tried making the change you noted on the post and got the same results. Sorry took so long I'm new to this and had a rough time making the alternate .sh file. I used santa matt's macro editor copied line by line with the /bin/cp /usr/bin/robot/state/* /mnt/sd/* change. hope I did it right. It was my first try, I dont know how else to make custom .sh files. If you want to make another .sh with the /bin/cp /usr/bin/robot/state/* /mnt/sd/* I will try it just incase I made it wrong.


I will try any other files if you need, I need to learn!

Santa Matt
Santa Matt's picture

Since you are on a windows machine, using my Macro Editor or a utility like Edit Pad Lite, is the best way to go. Windows terminates a line with a carriage return and a line feed. Linux uses only a line feed. So the previously mentioned utilities format the output properly for use in our Linux powered friends.

Android, if you want to send me the script you want run I'll take a crack at it.

Santa Matt

Nocturnal's picture

I swear by UltraEdit. Simply put, editing scripts in a normal windows editor, will create scripts that are unusable.

android78's picture

Hi Guys,

I'm not sure why the cp function isn't working as it should. There are several editors that you can use. I suggest either ultraedit or textpad (textpad has a free trial that just reminds you from time to time but all features are available).
I'm thinking, since the hello.txt is getting created, we should be able to find out more by adding the output to that file. ie. use the following to copy:
/bin/cp /usr/bin/robot/state/* /mnt/sd/ >> output.txt
While we're at it, we could check the files are there before the copy.
So, the full code should be (don't include the '--' lines):
#number of Bcons: 0
#Start Macro|StartEvent|1|
#End of Macro|EndEvent|0|
#code section:

/bin/mount /dev/mmc /mnt/sd -o rw,remount

echo "List files in directory /usr/bin/robot/state/" > output.txt
/bin/ls /usr/bin/robot/state >> output.txt
echo "Calling copy" >> output.txt
/bin/cp /usr/bin/robot/state/* /mnt/sd/ >> output.txt
echo "Calling sync" >> output.txt
echo "Remount" >> output.txt

/bin/mount /dev/mmc /mnt/sd -o ro,remount

From this you should be able to see the output.txt in the root of the SD card.
I hope this works. Nocturnal, Have you managed to get these files?

android78's picture

BTW... I logged a support ticket with wowwee asking them about the macro. Here's the helpful response from their support:
Thank you for your interest in WowWee. Please contact the distributor in your area at the following email address:
I don't think I'll bother.

android78's picture

Oh man... I think I worked out my issue with cp:
/bin/cp /usr/bin/robot/state/* /mnt/sd/*
should be
/bin/cp /usr/bin/robot/state/* /mnt/sd/
Mixing up DOS and UNIX commands. grrrr.

Nocturnal's picture

Yes.... that would be a problem. Of course with windows, you can't actually have a file or directory name that contains * or a variety of other useful characters.

android78's picture

Is it poor form to keep answering your own questions in a forum thread? I hope not.
Well... I got an SD card. and my findings are rather interresting.
1. The binaries for the IR functions are all the same. I do, however, see a few interresting strings:

Error reading robot state! %d

Of particular interest is /tmp/state/%s_VAR as I believe this is accessing the variable file with %s being the binary filename that is calling it.
This is good, and bad news. The good... I suspect there's nothing wrong with the code in RSM_IR_TRIGGER_L_L . The bad is that we can't just alter some mask in here to resolve the issue.

2. I had a play with calling the binaries to see what they would return. I used the following code:
echo $(RSM_IR_TRIGGER_L_L) >> /mnt/sd/debug.txt
This returned the following with no object in front of robot for the finctions:
RSM_IR_TRIGGER_L_D returned -1073742520
RSM_IR_TRIGGER_S_D returned 0
RSM_IR_TRIGGER_L_L returned 0
and with an object in front:
RSM_IR_TRIGGER_L_D returned -1073742520
RSM_IR_TRIGGER_S_D returned 0
RSM_IR_TRIGGER_L_L returned 1

I've looked aat the number, and all I can think is it's a memory address:
-1073742520 in hex is: FFFFFFFFBFFFFD48
Which means it could be a simple coding mistake of passing by reference instead of by variable (easy to do in C)

Ok... so where does this leave is with this issue? I think I'll have a look at the other code and see if I can see any other references to this value (probably binary encoding of the value). Also I'm not sure if there's another way to call the input scanner directly (hard to explain what I mean by this) that we can compare it to. Also, I could suggest decompile... not sure what others feel about this.
Let me know if any of you come up with anything.

android78's picture

Seems there's none interrested in this, but I'll keep going anyway (don't want to let this thing get the better of me)...
Just did a find in files. The most interresting is in /bin/robot/mediademon
This file appears to have strings for all the variable files in /tmp/state directory except for RMS_IR_TRIGGER_L_D_VAR . I think they may have just left it out for some reason. :( May need to decompile this file to find out more though.
Does anyone have a robot where the center IR macro DOES work. ie. is this just a bad version of the operating system that may have been fixed in a later version so we can fix it easily?

Santa Matt
Santa Matt's picture

android78 said:
Seems there's none interrested in this, but I'll keep going anyway (don't want to let this thing get the better of me)... <snip>

I am very much interested in this topic. But due to a number of issues I have not been able to  do much to persue it. I have been watching your results closely. Right now I have two pieces of software I'm working on for the RS Media. I had a melt down on my Ubuntu VM that I had to fix. And then there is that whole real life thing that keeps getting in the way, you know, family, work, church etc.

But seriously, I am watching what you are finding out. And I have done some of the same tests you have done. I get the same results as you from the RSM_IR_TRIGGERs.

 Santa Matt

android78's picture

Thanks for your support Santa.
Well... Think it'll be slow progress from here.
Did some disassembly last night. I'm a little concerned as it seems that there are two places in the code that call an update to the variable files (one to set the value to 0 and another to update it to 1 on certain conditions), and the RSM_IR_TRIGGER_L_D_VAR is missing from both places. The reason this is concerning is it would appear to be more likely an intentional omission. It's also difficult to follow the optimized assembly. It's been a long time since I've done assembly programming.
On the plus side, I have something to go on with. I see there appears to be a switch/case that is setting the variable that is being called... one for long/short and one for the sensor. The compares R3 against on 0x01, 0x02, 0x04, 0x09 and 0x0A (looks like bitmasking). This is interesting because there is no checking for R3 against 0x0C , and the check against 0x04 then sets the string to RSM_IR_TRIGGER_S_D_VAR (0x01, 0x02 and 0x04 are for the short-range variables. 0x09 and 0x0A are for long-range variables). I'm tempted to just change the binary to do the compare that sets the value in RSM_IR_TRIGGER_L_L_VAR to check against 0x0C and then try to either overwrite the existing mediadaemon (anyone know if we can do that) to see if the RSM_IR_TRIGGER_L_L will then detect the front sensor.. proof of issue... before I go trying to insert my own code to fix the bug. If this doesn't work, I think we would need the source code to fix the issue.

BTW. It seems that mediadaemon is the main robot binary that controls everything from the video playing to input sensor detection. I wish they had stand-alone binaries for things, it'd make this debugging much simpler!

Nocturnal's picture

Don't bother trying to overwrite the existing media daemon, it can be done, but it requires a non trivial amount of setup / work (you have to decompress an image of the file system, modify it, recompress, and hope its the same size (smaller would probably also work) as the original and then reflash the partition with the new image). Far simpler is (if you have shell access) to kill the running media daemon and start your own one.

The other way to do it is to use the rsupdate/rsupdateapp script on an SD card to start your own media daemon on startup (this is what the java SDK does).

android78's picture

Thanks for the update Nocturnal.

I was more thinking about just putting in a script:
/bin/cp /mnt/sd/mediadaemon /bin/robot/mediademon
but I guess that the file is probably write protected.
Would probably have to first kill the process that is running this so I can run it again. This would be trouble for just testing.

As you've pointed out, it'd be easier to kill the running daemon and run it directly off the SD card. I believe that there is an init script that starts the real one that I could use as a basis. Shame I'm not really a Linux expert... any ideas the shell commands to do this? Or will I just look at the script for stop all and init? ;-)
I'm at work ATM so can't test any of this, just throwing some ideas in there for thought.

Nocturnal's picture

the filesystem is compressed, you can't write to it (except a few places).

This is an example of a rsupdateapp script that will run a custom mediadaemon.

mkdir /tmp/state

touch /tmp/state/RSM_CAMERA_BLUE_HIT_VAR
touch /tmp/state/RSM_CAMERA_GREEN_HIT_VAR
touch /tmp/state/RSM_CAMERA_HUMAN_HIT_VAR
touch /tmp/state/RSM_CAMERA_RED_HIT_VAR
touch /tmp/state/RSM_CAMERA_BLACK_HIT_VAR
touch /tmp/state/RSM_GAUNTLET_L_I_VAR
touch /tmp/state/RSM_GAUNTLET_L_O_VAR
touch /tmp/state/RSM_GAUNTLET_R_I_VAR
touch /tmp/state/RSM_GAUNTLET_R_O_VAR
touch /tmp/state/RSM_FOOT_L_B_VAR
touch /tmp/state/RSM_FOOT_L_F_VAR
touch /tmp/state/RSM_FOOT_R_B_VAR
touch /tmp/state/RSM_FOOT_R_F_VAR
touch /tmp/state/RSM_GRIPPER_R_VAR
touch /tmp/state/RSM_GRIPPER_L_VAR
touch /tmp/state/RSM_IR_TRIGGER_L_D_VAR
touch /tmp/state/RSM_IR_TRIGGER_L_L_VAR
touch /tmp/state/RSM_IR_TRIGGER_L_R_VAR
touch /tmp/state/RSM_IR_TRIGGER_S_D_VAR
touch /tmp/state/RSM_IR_TRIGGER_S_L_VAR
touch /tmp/state/RSM_IR_TRIGGER_S_R_VAR
touch /tmp/state/RSM_SOUND_CENTER_VAR
touch /tmp/state/RSM_SOUND_LEFT_VAR
touch /tmp/state/RSM_SOUND_RIGHT_VAR
touch /tmp/state/BC_AUDIOPLAYER_VAR
touch /tmp/state/BC_IMAGEVIEWER_VAR
touch /tmp/state/BC_TAKEMOVIE_VAR
touch /tmp/state/BC_VIDEOPLAYER_VAR
touch /tmp/state/BC_AUTOTRACK_VAR
touch /tmp/state/BC_JAVA_VAR
touch /tmp/state/BC_TAKEPICTURE_VAR
touch /tmp/state/mp3_state
touch /tmp/state/sleep_state
touch /tmp/curvol
touch /tmp/state/scriptrun
touch /tmp/state/linein_state
touch /tmp/state/usb_state

killall nano-X
killall main_ui
/usr/bin/robot/nano-X -p &
/usr/bin/robot/start_robot_main &
/usr/bin/robot/main_ui &

Helibot's picture

Hi all,
My RSMedia has the same problem you are seeing - forward sensor never trigger (although mine always return 0 not a large number?). I looked into it further today and I dont think the data from the forward IR sensor is ever sent to the media board :-(

Some details:-
By monitoring the commands received from the robot board I can see data received like :-
ff fa 3 XX 0 ff

'ff fa 3' means IR tracking message. XX is the actual data, it seems to be bit mapped to only four bits.
My best guess of the mappings are:-
bit 0 = Short Range Left
bit 1 = Long range Left
bit 2 = Short Range Right
bit 3 = Long range Right

I can bringing an object in from the either side and see the corrosponding left or right bits be set.
I only ever saw these four bits. NOTE that covering the forward sensor (in front of his mouth) produces no IR tracking messages at all.

If you have the serial console you can also see messages like "IRData is 12" being printed to the console. The number shown is a decimal version of the four bits (eg 12 = 0x0C or 1100)

By the way the numbers are often jumping all over the place so I guess the media daemon code must be doing some filtering/averaging to get reasonable values.

Also I noted that most of the time when the 'long range' bits are set ,the short range bits are also set.

But my findigs dont seem to fit with some of the code disasembled by Android78 on March2 post. He reported that the code tested for 0x09 - that would be Long Right and Short Left- what use is that?.

I guess the mediadaemon could trigger forward sensing by testing if left AND right sensors are set. (ie testing 0x0A for Long range forward)

Anyway thats all I worked out. Hope its right and hope it helps!