View unanswered posts | View active topics It is currently Fri Apr 18, 2014 5:00 pm






Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
EOPD malfuntion on SMUX 
Author Message
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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?


Thu Feb 28, 2013 4:21 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post 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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Fri Mar 01, 2013 12:37 am
Profile WWW
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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


Fri Mar 01, 2013 4:21 am
Profile
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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?


Fri Mar 01, 2013 5:45 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post 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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Mar 02, 2013 2:20 am
Profile WWW
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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


Sat Mar 02, 2013 5:52 am
Profile
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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]


Sat Mar 02, 2013 7:45 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post 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);
  }
}

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Mar 02, 2013 2:59 pm
Profile WWW
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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!?


Sun Mar 03, 2013 3:28 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post 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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sun Mar 03, 2013 4:41 pm
Profile WWW
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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).


Mon Mar 04, 2013 8:13 am
Profile
Rookie

Joined: Thu Feb 28, 2013 4:12 pm
Posts: 9
Post 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?


Tue Mar 19, 2013 6:07 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post 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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Mar 20, 2013 1:29 am
Profile WWW
Rookie

Joined: Sun Dec 05, 2010 11:58 am
Posts: 28
Post 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).


Wed Mar 20, 2013 2:00 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3105
Location: Rotterdam, The Netherlands
Post Re: EOPD malfuntion on SMUX
Do you see a similar issue with NXT-G or LV?

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Mar 20, 2013 2:08 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 17 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.