View unanswered posts | View active topics It is currently Wed Sep 17, 2014 10:33 am






Reply to topic  [ 14 posts ] 
IR Seeker Driver or 4th controller bug? 
Author Message
Rookie

Joined: Wed Feb 24, 2010 11:19 am
Posts: 8
Post IR Seeker Driver or 4th controller bug?
We are using RobotC 2.01 and firmware 7.88. We have 3 motor controllers and 1 servo controller (in 4th position). We are using HTDIR driver version 1.2.

We have been having problems with autonomous routines. We finally realized it is because the encoder values on the drive wheels are jumping around. This only occurs when using the IR Seeker(HTDIR). If we never call the HTDIR the encoders are stable. Once called they continue to be erradic even though you stop the program and restart it. We have found two ways to stabalize the encoder values.

First we can turn off the NXT and back on and the values are stable until HTDIR is called again. We have 3 auto programs, only one uses HTDIR. The other two work fine until the one that uses HTDIR is run then the other two mess up continually until we turn NXT off and back on.

Second, we can unplug the 4th controller which is a servo controller and the encoder values will stabalize. We would eliminate the servo controller, but we are using 6 motors and 3 servos so eliminating the servos is not an option.

Is this a bug with the 4th controller code or the HTDIR code or is our code doing something wrong to cause it? The problem is the same on two different NXT's. Our code is below. Sometimes it will drive to goal, sometimes part way, sometimes won't appear to move toward goal at all.

#pragma config(Hubs, S1, HTMotor, HTMotor, HTMotor, HTServo)
#pragma config(Sensor, S2, HammerEye, sensorLightActive)
#pragma config(Sensor, S3, HTDIR, sensorLowSpeed)
#pragma config(Motor, mtr_S1_C1_1, motorD, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C1_2, motorE, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C2_1, motorF, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C2_2, motorG, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C3_1, motorH, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C3_2, motorI, tmotorNormal, openLoop)
#pragma config(Servo, srvo_S1_C4_1, , tServoNormal)
#pragma config(Servo, srvo_S1_C4_2, , tServoNormal)
#pragma config(Servo, srvo_S1_C4_3, , tServoNormal)
#pragma config(Servo, srvo_S1_C4_4, , tServoNormal)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//

/////////////////////////////////////////////////////////////////////////////////////////////////////
// Autonomous Mode Code Template
/////////////////////////////////////////////////////////////////////////////////////////////////////
#include "JoystickDriver.c" //Include file to "handle" the Bluetooth messages.
#include "HTDIR-driver.h" // Includes for HiTechnic IR Seeker Sensor

int IR; // holds the value returned from the IR Seeker Sensor
/////////////////////////////////////////////////////////////////////////////////////////////////////
// initializeRobot
/////////////////////////////////////////////////////////////////////////////////////////////////////
void initializeRobot()
{
// Place code here to sinitialize servos to starting positions.
// Sensors are automatically configured and setup by ROBOTC. They may need a brief time to stabilize.
return;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////
// Main Task
/////////////////////////////////////////////////////////////////////////////////////////////////////

task main()
{
initializeRobot();

waitForStart(); // Wait for the beginning of autonomous phase.

///////////////////////////////////////////////////////////
//// Add your robot specific autonomous code here. ////
///////////////////////////////////////////////////////////

// Use this to set to 1200Hz (the default)
HTDIRsetDSPMode(HTDIR, DSP_1200);


servo[servo1] = 210; //set shooter height
nMotorEncoder[motorD] = 0; //zero wheel encoders
nMotorEncoder[motorE] = 0;

motor[motorD] = 55; //start turn to goal
motor[motorE] = 55;
IR=HTDIRreadACDir(HTDIR);

while(IR != 6) //keep turning until pointed at goal
{
IR=HTDIRreadACDir(HTDIR);
}

nMotorEncoder[motorD] = 0; //zero wheel encoders
nMotorEncoder[motorE] = 0;
motor[motorD] = 25;
motor[motorE] = -25;
while(nMotorEncoder[motorE] < 1400) //drive forward to goal
{
}
motor[motorD] = 0;
motor[motorE] = 0;
//end of program
}


Wed Feb 24, 2010 12:18 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3221
Location: Rotterdam, The Netherlands
Post Re: IR Seeker Driver or 4th controller bug?
Try changing:
Code:
while(IR != 6) //keep turning until pointed at goal
{
  IR=HTDIRreadACDir(HTDIR);
}


to

Code:
while(HTDIRreadACDir(HTDIR) != 6) //keep turning until pointed at goal
{
  wait1Msec(10);
}


and

Code:
while(nMotorEncoder[motorE] < 1400) //drive forward to goal
{
}


to

Code:
while(nMotorEncoder[motorE] < 1400) //drive forward to goal
{
  wait1Msec(10);
}


Regards,
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 Feb 24, 2010 12:38 pm
Profile WWW
Rookie

Joined: Wed Feb 24, 2010 11:19 am
Posts: 8
Post Re: IR Seeker Driver or 4th controller bug?
Xander,

I made the modifications you suggested. No change in symptoms. The encoders still start jumping around as soon as HTDIR is used. Also, unplugging the servo controller stabalizes the encoder values.

I can run the same program with the servo controller unplugged and the encoder values are very stable.

I can run the program with servo controller plugged in but removing reference to HTDIR and use encoder counts instead for the turn and encoders are very stable.

Andy


Wed Feb 24, 2010 7:41 pm
Profile
Rookie

Joined: Wed Feb 24, 2010 11:43 pm
Posts: 34
Post Re: IR Seeker Driver or 4th controller bug?
We have the same issue - we didn't realize that it was IRSeeker related, but noted that the encoder values jumping around... even when the program is stopped. The values are not just close to the same, they are ALL over the place... jumping from zero to -13448 to multiple other random values.

Pretty obviously our C program is not at fault here. This symptom can be seen in the NXT devices window on the debugger. It is apparent (when it is active) whether there is a program running or not...

We noted that when we reset (cycle power) to the NXT the problem went away, but hadn't pinpointed it down to the IR Seeker yet.

Our setup is:
Port 1: Servo, Motor, Motor, Motor
Port 2: Touch Sensor
Port 3: IR Seeker
Port 4: Sensor Multiplexer - w. 2 light sensors

The next thing we are going to try is to put the IR Seeker into the SMux, if that fixes the problem, we'll let you know.

Is there a way to deactivate power to the IRSeeker? -- is it possible that the hardware is putting a random frequency signal on the bus that messes with everything else?

Alan


Thu Feb 25, 2010 12:07 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3221
Location: Rotterdam, The Netherlands
Post Re: IR Seeker Driver or 4th controller bug?
I know the servo controller uses I2C as does the IR Seeker, so perhaps there is something that's conflicting somehow. I don't have a servo controller so there is not a whole lot I can test.

If you don't query the sensor, nothing should happen and the driver won't be doing anything. What happens if you connect the sensor but comment out all the code for the IR Seeker?

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]


Thu Feb 25, 2010 2:06 am
Profile WWW
Rookie

Joined: Wed Feb 24, 2010 11:19 am
Posts: 8
Post Re: IR Seeker Driver or 4th controller bug?
Xander,

I had an opportunity to set up the test on a completely different system. Same results. On the second system, I removed the 3rd motor controller making my setup motor, motor, servo. The encoders were stable. So it seems pretty clear to me that it has something to do with having a 4th motor/servo controller in the mix.

Looking at the updates for RobotC V2.01 one of the fixes was to allow a fourth controller to be used. Maybe it is tied into this change.

But again, I never have encoder problems unless I access the HTDIR Driver.

Andy


Thu Feb 25, 2010 2:17 am
Profile
Rookie

Joined: Wed Feb 24, 2010 11:43 pm
Posts: 34
Post Re: IR Seeker Driver or 4th controller bug?
mightor wrote:
I know the servo controller uses I2C as does the IR Seeker, so perhaps there is something that's conflicting somehow. I don't have a servo controller so there is not a whole lot I can test.

If you don't query the sensor, nothing should happen and the driver won't be doing anything. What happens if you connect the sensor but comment out all the code for the IR Seeker?


Until you query the sensor, nothing happens wrong. After that, the encoder values have random spikes. --Even if the program is stopped!--

By the way, I tried putting the IRSeeker on the Sensor Mux, and the same thing still happens. I wonder if there's a voltage/power/frequency issue with the IR seeker (rather than a software bug).

Luckily for us, by moving the IR Seeker to a port on the SMux, I freed up a port on the NXT, and was able to split up the controller chain. Now with 2 NXT ports connected to 2 (each) controllers, the encoder readings are again stable.

There's obviously something that happens with a chain of 4 controllers - I don't know anything about the electrical characteristics, but it could be that... or it could perhaps be a memory conflict with the array of controllers into the same space as the IR sensor... or...

Alan


Thu Feb 25, 2010 3:37 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3221
Location: Rotterdam, The Netherlands
Post Re: IR Seeker Driver or 4th controller bug?
I really wish I could help you guys figure out this problem, but without the hardware necessary to reproduce this, makes this like looking for a needle in a haystack.

Does this problem occur with 4 controllers and another random HiTechnic digital sensor or other I2C sensor? The sensor MUX is just another I2C sensor as far as the NXT is concerned, as are the controllers.

Regards,
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]


Thu Feb 25, 2010 3:43 pm
Profile WWW
Rookie

Joined: Wed Feb 24, 2010 11:19 am
Posts: 8
Post Re: IR Seeker Driver or 4th controller bug?
I am using the active light sensor and that doesn't bother it. I haven't tried any other sensors. We may try compas tonight if we have time before packing for our tournament.

I will try moving my 4th controller to our empty port and see if that helps get us through our competition this weekend. Our only other option is to try to filter out the encoder readings that are out of the range we are expecting.

Andy


Thu Feb 25, 2010 4:34 pm
Profile
Rookie

Joined: Wed Feb 24, 2010 11:19 am
Posts: 8
Post Re: IR Seeker Driver or 4th controller bug?
Well, we made it though our tournament at Arlington and won as a first pick team. Had high score during seeding match of 336 all on our own. Guess with the possiblity of getting an invitation to world I'll order a sensor multiplexer so we can add the extra sensor we want and leave the 4th controller on a channel by itself.

Andy


Sat Feb 27, 2010 11:49 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3221
Location: Rotterdam, The Netherlands
Post Re: IR Seeker Driver or 4th controller bug?
I think a congratulations is in order then! Well done :)

- 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 Feb 28, 2010 3:44 am
Profile WWW
Rookie

Joined: Wed Feb 24, 2010 11:43 pm
Posts: 34
Post Re: IR Seeker Driver or 4th controller bug?
So... still haven't figured out what the problem is... but we just separated out two of the motor controllers to a separate NXT port as well, and then ditched our light sensors' use for state.

We did OK at our tournament too... we were captain of alliance #1, lost in the semi's but won the inspire award, and now we'll be going to world in a couple weeks.

So... now we come back to this though!

We also tried putting the IR sensor into the sensor multiplexer and that didn't change anything. Our current setup is:
1: Servo - Motor
2: Sensor Multiplexer - a)Touch, b)Light, c)Compass, d)Light
3: Motor - Motor
4: IR Sensor

The IR sensor doesn't work as easily over the SMUX as it probably should for us - so we're using it (the SMUX) for simpler sensors.

In any case, still no resolution on this, and I really would like to be able to use one port for all four controllers. the SMUX isn't quite fast enough to handle the touch sensor the way we need it.

Alan


Wed Mar 31, 2010 3:00 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3221
Location: Rotterdam, The Netherlands
Post Re: IR Seeker Driver or 4th controller bug?
Alan,

If you'd like to send me your code via email, I'd like to have a look at it. What makes it hard for you to use the IR Seeker via the SMUX? I've used it that way quite a number of times and it works fine. The only caveat is that it is stuck in 1200Hz mode. Can you explain how the touch sensors aren't working as well as you'd like?

You are using the latest (v1.3) of my driver suite, right?

Regards,
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 31, 2010 3:18 am
Profile WWW
Rookie

Joined: Wed Feb 24, 2010 11:43 pm
Posts: 34
Post Re: IR Seeker Driver or 4th controller bug?
I'll be more than happy to send you the code!

The reason we're not using the IRseeker with the SMUX is that we really haven't got a firm grasp on what the various pieces of information mean. We initially wrote the robot's program using the standard functionality of the "SensorValue[]" array and were able to make that work very well. When we moved it to the SMUX we didn't get the same values... again though, that's probably because we didn't dig into it enough.

The Touch Sensor issue is that we've got a piece of plastic whipping past the sensor - It's not always fast enough to catch it going past. It looks like a full Multiplexer (2 Light sensors, a Touch sensor, a Compass sensor, and MUX Status) updates in about 38 mSec... may not be fast enough for what we're needing. - Then again, I can try putting a priority scan into it too...

We were using the most current driver suite... I think I saw 1.2 but I'll look again!

Alan


Wed Mar 31, 2010 3:47 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 14 posts ] 

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.