ROBOTC.net forums
http://robotc.net/forums/

EOPD malfuntion on SMUX
http://robotc.net/forums/viewtopic.php?f=52&t=5556
Page 1 of 2

Author:  The Florist [ Thu Feb 28, 2013 4:21 pm ]
Post subject:  EOPD malfuntion on SMUX

Hi everyone,

For autonomous my team uses two Hitechnic EODP sensors. Usually they were very acurate and relyable, we use them in their "close range".
Now that the sensor-needs of our team have grown we included our Hitechnic SMUX to the project and this is where things started going wrong.
The output of both the EOPD's is almost random and they are not acurate enough anymore to keep using them. On the regular (direct) NXT-imputs they are fine.
Our Gyro kind of misbehaves as well on the SMUX (It starts to drift, which it never does on a direct link) the rest of our sensors work fine there (Angle, touch, light, IR V2, all Hitechnic/LEGO).
We upgraded to the new RobotC 3.59 beta and the new new sensordrivers by Xander (thanks a million for all that Xander).

Has anyone experienced behaviour like this?
Hints? Tips?

Author:  mightor [ Fri Mar 01, 2013 12:37 am ]
Post subject:  Re: EOPD malfuntion on SMUX

I'll take a look at it this weekend. Which version of the suite are you using? 3.2.1?
= Xander

Author:  The Florist [ Fri Mar 01, 2013 4:21 am ]
Post subject:  Re: EOPD malfuntion on SMUX

Ah thanks Xander we were hoping you would pick this up. Yes we are using 3.2.1
Btw we were the ftc-team that did the demo in Groningen. I (the coach) talked to you about my students building a delta-robot. I was talking to Martijn about the new mindstorms software. I will be in Zeeland this weekend but will be able to answer mail. I hope this is not going to be mutch trubble for you

Author:  The Florist [ Fri Mar 01, 2013 5:45 am ]
Post subject:  Re: EOPD malfuntion on SMUX

Is differentiating between short and long rage maybe seen as a write action to the sensor? That could explain the behaviour maybe? If so, is there any way to get the short range data and a little later the long range?

Author:  mightor [ Sat Mar 02, 2013 2:20 am ]
Post subject:  Re: EOPD malfuntion on SMUX

When you are rapidly changing from long to short range, you need to give the SMUX a little time to do a new reading of the sensor. I would put at least 5ms between changing the range and reading a new value. The sensor is completely analogue, so the switching of ranges occurs by simply toggling the dig0 pin, like with the old LEGO Light Sensor.

You wouldn't happen to have a small program that demonstrates this issue, would you?

= Xander

Author:  The Florist [ Sat Mar 02, 2013 5:52 am ]
Post subject:  Re: EOPD malfuntion on SMUX

No we are not rapidly changing the range. We use short range for a while and want to switch to long range about 5 sec later. There is no switching back and forth, nothing fancy there. I will post the code later today. Thnx already

Author:  The Florist [ Sat Mar 02, 2013 7:45 am ]
Post subject:  Re: EOPD malfuntion on SMUX

Code:
#pragma config(Hubs,  S1, HTMotor,  HTMotor,  HTServo,  HTMotor)
#pragma config(Sensor, S2,     HTSMUX,         sensorI2CCustom)
#pragma config(Motor,  mtr_S1_C1_2,     voorL,         tmotorTetrix, openLoop)
#pragma config(Motor,  mtr_S1_C2_1,     achterL,       tmotorTetrix, openLoop)
#pragma config(Motor,  mtr_S1_C4_1,     achterR,       tmotorTetrix, openLoop)
#pragma config(Motor,  mtr_S1_C4_2,     voorR,         tmotorTetrix, openLoop)
#pragma config(Servo,  srvo_S1_C3_2,    EOPDservoR,           tServoStandard)
#pragma config(Servo,  srvo_S1_C3_3,    EOPDservoL,           tServoStandard)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#include "hitechnic-sensormux.h"
#include "hitechnic-eopd.h"

const tMUXSensor EOPDL = msensor_S2_1;
const tMUXSensor EOPDR = msensor_S2_4;

int i=0;
int state = 0;



void initializeRobot()
{
   nMotorEncoder[achterR] = 0;
   nMotorEncoder[voorR]     = 0;
   nMotorEncoder[achterL] = 0;
   nMotorEncoder[voorL]   = 0;

   servo[EOPDservoL] = 250;
   servo[EOPDservoR] = 90;

  return;
}



task main()
{
  initializeRobot();

 // waitForStart();


  while (1)
  {

      nxtDisplayTextLine(4,  "EL: %d", HTEOPDreadRaw(EOPDL));
      nxtDisplayTextLine(5,  "ER: %d", HTEOPDreadRaw(EOPDR));


      switch(state)
      {
         ////weg gelaten stuk code////
      
               case 5:
               if(i==5)
               {
                  HTEOPDsetShortRange(EOPDL);
                  HTEOPDsetShortRange(EOPDR);
                  
                  wait1Msec(1000);
                  
                  if(HTEOPDreadProcessed(EOPDL) < 110)
                  {
                     motor[voorL]   = -50;
                     motor[achterL] = -50;
                  }
                  else
                  {
                     motor[voorL]   = 0;
                     motor[achterL] = 0;
                  }

                  if(HTEOPDreadProcessed(EOPDR) < 110)
                  {
                     motor[voorR]   = 50;
                     motor[achterR] = 50;
                  }
                  else
                  {
                     motor[voorR]   = 0;
                     motor[achterR] = 0;
                  }


                  if((HTEOPDreadProcessed(EOPDL) > 110) && (HTEOPDreadProcessed(EOPDR) > 110))
                  {
                        i=6;
                        state = 6;
                  }

               }
               break;


////////weg gelaten stuk code//////////////////
               

               case 7:
               if(i==7)
               {
                  servo[EOPDservoL] = 130;
                  servo[EOPDservoR] = 230;
                  
                  HTEOPDsetLongRange(EOPDL);
                  HTEOPDsetLongRange(EOPDR);

                  wait1Msec(1000);

                  if(HTEOPDreadProcessed(EOPDL) < 110)
                  {
                     motor[voorL]   = 50;
                     motor[achterL] = 50;
                  }
                  else
                  {
                     motor[voorL]   = 0;
                     motor[achterL] = 0;
                  }

                  if(HTEOPDreadProcessed(EOPDR) < 110)
                  {
                     motor[voorR]   = -50;
                     motor[achterR] = -50;
                  }
                  else
                  {
                     motor[voorR]   = 0;
                     motor[achterR] = 0;
                  }

                 if((HTEOPDreadProcessed(EOPDL) > 110) && (HTEOPDreadProcessed(EOPDR) > 110))
                  {
                        i=8;
                        state = 8;
                  }

               }
               break;

////////weg gelaten stuk code///////////

      }    //switch
  }         //while
}            //task main[size=50][size=85][size=50][/size][/size][/size]

Author:  mightor [ Sat Mar 02, 2013 2:59 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

I can't replicate the issue here but try this program and see if you still see the problem. Make sure you change the sensor settings.

Code:
#pragma config(Sensor, S1,     HTSMUX,         sensorI2CCustom)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#include "drivers/hitechnic-sensormux.h"
#include "drivers/hitechnic-eopd.h"
const tMUXSensor EOPDL = msensor_S1_1;
const tMUXSensor EOPDR = msensor_S1_2;

task main()
{
  int leftVal = 0;
  int rightVal = 0;
  bool longRange = true;
  while (true)
  {
    if (longRange)
    {
      writeDebugStreamLine("short range");
      longRange = false;
      HTEOPDsetShortRange(EOPDL);
      HTEOPDsetShortRange(EOPDR);
    }
    else
    {
      writeDebugStreamLine("long range");
      longRange = true;
      HTEOPDsetLongRange(EOPDL);
      HTEOPDsetLongRange(EOPDR);
    }
    wait1Msec(500);
    leftVal = HTEOPDreadRaw(EOPDL);
    rightVal = HTEOPDreadRaw(EOPDR);
    writeDebugStreamLine("left: %d, right: %d", leftVal, rightVal);
    writeDebugStreamLine("-----------------------------------------");
    wait1Msec(100);
  }
}

Author:  The Florist [ Sun Mar 03, 2013 3:28 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

When we add more sensors (on the SMUX) the EOPD sensor is getting a higher output. After a few test we conclude that the EOPD value is chainging. Switching between short and long range is clearly no longer a problem. The main problem now seems to be the fact that other sensors seem to disturb the value of our EOPD's. Apart from both EOPD's we have an angle sensor and a Lego active light sensor on the SMUX. Is this normal when the EOPD is on the SMUX, or is it because of the other sensors? Haw can it be that the sensors seem to interfere!?

Author:  mightor [ Sun Mar 03, 2013 4:41 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

Could be a slight voltage drop when additional sensors are connected. Can you tell me if this is a 5, 10 or higher % drop? My drivers wouldn't be the cause of that.

= Xander

Author:  The Florist [ Mon Mar 04, 2013 8:13 am ]
Post subject:  Re: EOPD malfuntion on SMUX

The value goes from 10 to 40.
The sensetivity is less too.
It doesn't happen WHEN we connect other sensors, they are already connected but seem to interfere.
We will check tomorrow if we can swap all the other sensors to a second SMUX (this was just delivered today).

Author:  The Florist [ Tue Mar 19, 2013 6:07 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

Xander,

Will you be attending the FTC match in Delft this saturday 23 march?
If so, maybe we can look into this issue together then because right now our final conclusion is:
EOPD directly on NXT: standard value measuring 10 and is stable, when we detect an obstacle, value changes to 19 of 20. This is enough precision for us.
EOPD on NXT via SMUX: standard value measuring 50 (!) and unstable (going to 56 sometimes), value changes to 60 sometimes when we detect an obstacle. This delivers enough unpredictability for us to avoid using the EOPD right now.
Strangest to me is the change of measurement from 10 to 50,....WHY?

Author:  mightor [ Wed Mar 20, 2013 1:29 am ]
Post subject:  Re: EOPD malfuntion on SMUX

I can try to be there but I can't make any promises. Do you have a time and place for this event? I was there last year but I don't recall how I got there. I'm in R'dam, so it's pretty close by.

= Xander

Author:  jorge_the_awesome [ Wed Mar 20, 2013 2:00 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

We actually had (what I think is) a very similar problem. We have to use the EOPDs on the sensor ports because when we put them on a multiplexer (which otherwise works fine) we could not switch them out of some weird shortrange mode. Using your standard driver suite (at least what was published at the beginning of this season) we found that when on the multiplexer, the range of the sensor (as in, what caused the reading to change) appeared to be much closer to the short range mode than the long range mode. Also, while the sensor readings should start at 0 and increase, we found that the sensor readings would start at roughly 1040 (a number that changed based on battery power), increase to roughly 1500 or 1600 (we could not find the exact number) and then overflow to roughly 500 or 600 (again, we could not find the exact number).

Author:  mightor [ Wed Mar 20, 2013 2:08 pm ]
Post subject:  Re: EOPD malfuntion on SMUX

Do you see a similar issue with NXT-G or LV?

= Xander

Page 1 of 2 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/