EV3 Infrared sensor class

This is where you talk about the EV3 software itself, installation issues, and programming talk.

Moderators: roger, gloomyandy, skoehler

EV3 Infrared sensor class

Postby tigger » Wed Feb 19, 2014 9:35 pm

Hi all,

last days I started to play around with the EV3IRSensor in my bot.

First experiment was an autonomous bot using IR to detect barriers (currently I do not own an Ultrasonic sensor) - which works ok by using filters to smoothing the measurements.

Then I tried IR as multichannel remote control, which works ok once find out how to use the confusing getRemoteCommands() API method (seems like C programmers style with output array as parameter combined with index + len).

Next was a combination - a RC bot with automatic barrier detection. Here I had these troubles:

(1) EV3IRSensor is using an hard wired SWITCH_DELAY of 250ms visible in source code

Maybe wise to save battery power, but how's about an API method to allow the bot programmer overrule this value? With 125ms I had a better responsibility in my experiments

(2) Fast mote switching between IR_REMOTE and IR_PROX results in strange interferences in results

It seem IR command array contains "old" distance measurements:

Code: Select all
...
IR commands: 0/0/0/0
Distance value: 66.0
IR commands: 0/0/0/0
Distance value: 66.0
IR commands: 0/0/0/0
Distance value: 66.0
IR commands: 0/0/0/0
Distance value: 66.0
IR commands: 66/0/0/2            <= sending a signal on channel 4 takeover "old" distance value into command for channel 1
Distance value: 65.0
IR commands: 65/0/0/2
...


Here my little test program:

Code: Select all
public static void main(String[] args) {
      EV3IRSensor sensor = new EV3IRSensor(SensorPort.S3);
      byte[] commands = new byte[EV3IRSensor.IR_CHANNELS];
      float[] distances = new float[sensor.sampleSize()];
      while(true) {
         sensor.getRemoteCommands(commands, 0, commands.length);
         System.out.println("IR commands: " + commands[0] + "/" + commands[1] + "/" + commands[2] + "/" + commands[3]);
         sensor.fetchSample(distances, 0);
         System.out.println("Distance value: " + distances[0]);
      }
   }


Maybe a hardware problem with mode mixing, maybe a problem in EV3IRSensor.java

Under investigating...

Regards,
Tigger
tigger
New User
 
Posts: 17
Joined: Mon Feb 10, 2014 10:04 pm

Re: EV3 Infrared sensor class

Postby gloomyandy » Wed Feb 19, 2014 9:48 pm

The stale data problem is a known issue, please see the TODO comment in switchMode in the Ev3UartSensor.java. I'm not sure under what circumstances it would make sense to allow the programmer to change the delay value as in theory this has been selected to avoid the stale data issue, it is not there to save power.

Did you see this issue when using the default switch delay? If so this would indicate that some examples of this sensor may require an even larger delay, I did not see this issue with either of the two IR sensors I have when using a delay of 250mS.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Infrared sensor class

Postby fuzzycow » Wed Feb 19, 2014 10:10 pm

Since you mentioned IR and US sensors for barrier detection:

In my tests of IR vs US sensors for "object detection" - IR sensor worked much better.
While the bot remained stationary - IR sensor could reliably detect small objects placed on tile floor or on a table.
Haven't yet tried doing this "on the go".

I wanted to scan ahead of the robot, and the sensor had to be pointed at ~45% angle to the floor.
US sensor gave interesting results, but they also appeared to be less reliable.

The trick for me was to calibrate the distance from the floor, and then wait for change of over ~10%.
Last edited by fuzzycow on Wed Feb 19, 2014 10:17 pm, edited 1 time in total.
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm

Re: EV3 Infrared sensor class

Postby gloomyandy » Wed Feb 19, 2014 10:14 pm

Also we at some point hope to have a better way to handle this issue in which case a delay will no longer be needed, hence making any API to change it of no use. Please remember that this is still an alpha release and much of the code is the first iteration to get things working quickly, we will be revisiting some of it (like the new motor code), as time allows.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Infrared sensor class

Postby tigger » Wed Feb 19, 2014 10:18 pm

Thank you for your quick response, Andy.

Yes, I have the behavior described above with the standard delay of 250ms (ev3classes on tag 0.6.0 freshly compiled & copied to EV3): when a command is sent on channel 2-4 sometimes the value read for channel 1 contains the last value from distance mode. After sending a command on channel 1 the interference is "fixed".

With a shorter delay I fetched some strange IR commands in other bytes too, with 250ms it seems only channel 1 (id 0) is affected.

I'll take a look to EV3UartSensor Java, thank you for the hint!

Regards,
Tigger
tigger
New User
 
Posts: 17
Joined: Mon Feb 10, 2014 10:04 pm

Re: EV3 Infrared sensor class

Postby gloomyandy » Wed Feb 19, 2014 10:34 pm

I have some ideas about how to handle this issue, but will not be making the changes until the weekend as I'm away. You may want to wait until after then I suspect that simply discarding the first reading after a switch will fix things for now (or using a longer delay).
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Infrared sensor class

Postby gloomyandy » Thu Feb 20, 2014 2:17 am

I've just checked in some changes to the handling of mode switching which should be faster and fix the stale data problem. The changes are in git master so you may need to switch to that to test them. If you don't understand the issues with doing that you may want to wait for the next release.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Infrared sensor class

Postby tigger » Thu Feb 20, 2014 9:33 pm

Very interesting solution, Andy - I do not really understand the magic how to interprete the byte buffer in EV3UATPort but I can follow your changes.

The code is 10x faster, great work and a cool demonstration there is no need for an API to modify SWITCH DELAY (was a stupid idea from me, sorry)

My test configuration:
* IR sensor connected to another port to eliminate a broken port as root cause (for sure, it is possible my sensor is broken or my brick - I have a single set only so currently I cannot change these components)
* Test program as posted above (now on S4)
* Starting with jrun on command line to get std out

Results:
* without sending data distance measuring works fine, now with really fast switch between modes PROX and REMOTE
* sending data on channel 1 (remotes channel slider on TOP position)
- distance is fluctuating WHILE receiving data, after sending stable again
- commands on channel 1 received correctly, channel 2+3 keeps 0, several times channel 4 changes value to -24 (ca. 5-10% probability)
* sending data on channel 2-4
- ditance is fluctuating while receiving data (mostly to 100, in rare cases to values < 15) - same as sending data on channel 1
. command on SENDING channel is received correctly, other channels 0 except for channel 1: there is a copy of the distance:

Code: Select all
Distance value: 92.0
IR commands: 0/0/0/0
Distance value: 90.0
IR commands: 90/1/0/0
Distance value: 91.0
IR commands: 91/1/0/0
Distance value: 90.0
IR commands: 91/1/0/0
Distance value: 100.0
IR commands: 100/1/0/0
Distance value: 91.0
IR commands: 91/0/0/0


Note: after receiving a command on channel 2 (button top left, value 1) the value read in channel 1 is changed.

I tried to reset my data array (both int-array for commands and float array to read distance samples), I even tried to declare new variables inside the while loop for a single use - here in this test), the result is the same so I think the UART circle buffer is caching data between the mode changes in a strange way.

Please remember: this is NOT a compliant, I only play around with my EV3 because leJOS is soo cool. "normal" RC controlling works very cool even with mulitple channels, motors works fine, i have a lot of ideas what to try next. For me, there is no need to have a "multiplexed IR sensor" working as distance sensor and RC receiver - I'm a fan of your project and only try to help with reports like this. :)
tigger
New User
 
Posts: 17
Joined: Mon Feb 10, 2014 10:04 pm

Re: EV3 Infrared sensor class

Postby gloomyandy » Sun Feb 23, 2014 4:45 pm

Hi,
I don't think the problems you are describing are related to changing modes. It looks to me like the remote control unit will interfere with the distance reading (not totally surprising since they both generate infra red light). If I simply read distances (no mode switching) and point the remote control at the sensor then the distance readings will fluctuate. Can you try that and confirm that you see the same issue? The problem with odd values on non active channels seems to be a bug with the actual sensor it does not always seem to clear the values for the other sensor channels so you pick up whatever happens to be there. You seem to see this more when switching modes (because that will leave a value in the first byte of the reply) but I have also seen the same problem when using two remotes set to different channel numbers and with no mode switching.

Having said all of that there is still a problem with mode switching that I'm still looking into. There is something very odd about the shared memory implementation on the EV3 and it is very easy to get situations in which the shared memory is not in the state you would expect it to be in. I've sen this with the motor interface and now I'm seeing it with this sensor. Not yet sure if it is the base system or Java that is causing the problems, still investigating things.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Infrared sensor class

Postby tigger » Mon Feb 24, 2014 10:25 pm

To check out your sensor speed improvement in a "real robot" I tried to program my wheel bot - and it works great!

  • The mode switches between distance mode and IR mode now fast enough to suppress the autonomous mode via remote control
  • Distance measuring via a Filter is stable against "interferences" so the robot works in a real life environment

With the remote control I can switch RC controlled mode (forward/backward/left/right/speedUp/speedDown) and autonomous mode (forward as long as way is "free", backward left/right each time a critical distance is reached).

So my project "WheelExplorer" is finished - an autonomous robot which allows me to take control in any case of emergency via RC.

Thank you!
tigger
New User
 
Posts: 17
Joined: Mon Feb 10, 2014 10:04 pm

Re: EV3 Infrared sensor class

Postby gloomyandy » Mon Feb 24, 2014 10:32 pm

Hi,
glad you have it all working. If you get chance it is always nice to see a video of a robot in action and any details you fancy providing. I think I have now resolved the shared memory issues which means that the mode switch is a little faster still. This will require changes to the kernel modules though so will not be available until a future SD card release.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK


Return to EV3 Software

Who is online

Users browsing this forum: No registered users and 5 guests

more stuff