Page 1 of 1
NXC: US Sensor seems to stop in middle of program
Posted: 01 Feb 2011, 16:30
by babmoink
Hi,
I encounter a strange problem with an NXT 1's US sensor. The program consists of several tasks which are considered as states. The main task is used to initialize the input ports as low speed ones, then passes the control to the first state. At the beginning the program works perfectly well, the transitions between tasks happen as expected. But after some time, typically a couple of minutes, the robot seems locked in one state. It's always the same state, and normally there should be a state transition when the US sensor detects an object near. I've tried to put my hand in front of it, it doesn't seem to detect anything anymore, as if it was switched off.
Here are the parts of the code where I use the US sensor :
Code: Select all
task main() {
SetSensorLowspeed(IN_1); //Compass Sensor
SetSensorLowspeed(IN_2); //Ultra Sonic Sensor
SetSensorLowspeed(IN_3); //Colors Sensor
//...
}
task randomApproach() {
StartTask(randomCourse);
SetSensorLowspeed(IN_2); //Ultra Sonic Sensor
Wait(1000);
int mesure = 300;
while(SensorUS(IN_2) > 50) {
Wait(50);
}
mesure = SensorUS(IN_2);
//Musical identifier
PlayTone(131,32*__NOTETIME);
Wait(16*__WAITTIME);
StopTask(randomCourse);
Off(OUT_AC); //Use the brakes to stop the robot
Wait(500);
//...
}
//Called by randomApproach() to move the robot around like it's drunk
task randomCourse() {
int power;
while(true) {
power = Random(100);
OnFwd(OUT_C, power);
OnFwd(OUT_A, 100 - power);
//controle de l'ouverture de la griffe
if (MotorRotationCount(OUT_B) >= 90) {
OnRev(OUT_B, 50);
}
Wait(600);
}
}
//Called by scan()
task mesure() {
//Initialization : guarantees at least one measure will be done
distance = 300;
while(true){
if(distance>SensorUS(IN_2)) {
distance = SensorUS(IN_2);
ResetRotationCount(OUT_AC);
}
Wait(40);
}
}
Some precisions : here randomApproach() is one of the "states". randomCourse() and mesure() are auxiliary tasks, called by "state" tasks. What happens is that the robots gets locked doing the randomCourse() : the problem might be stopping that task rather than detecting objects.
So, do you seen anything that looks like awfully wrong practice to you in the code ? I confess I'm a bit confused about Low Speed sensors and their API functions : is there a need for a waiting time or is it included already in functions such as SensorUS(port) ?
Another thing : there was some other strange behaviour from the robot since I've changed the firmware to enable multitasking. (For instance, the ResetRotationCount function was not working properly anymore.) I'm using BricxCC, was there anything to change in its configuration after installing the enhanced firmware on the brick ? Now that I think of it, it could explain my problems... :s
Thanks in advance for your help !
Re: US Sensor seems to stop in middle of program
Posted: 03 Feb 2011, 14:44
by babmoink
No clue, anyone ?
Re: US Sensor seems to stop in middle of program
Posted: 03 Feb 2011, 15:12
by hassenplug
First, I'd be interested to know if you are allowed to have a task, and a variable with the same name.
Without seeing the whole program, and understanding what all the states should be doing, it's hard to say what's going on. It would seem like (as you said) it's getting stuck in some state. I doubt the US sensor stops working. It's more likely that the program simply stops looking at the readings. The program may be getting into a loop that it can't exit.
You may also want to look at your motor-B handling in the randomCourse task. It doesn't look like it would work too well. Assuming motor B is started in another task, this would only cause it to bounce back when it gets to 90, but it doesn't ever reverse or stop the motor, again.
Not much help. Sorry.
Steve
Re: US Sensor seems to stop in middle of program
Posted: 03 Feb 2011, 17:30
by HaWe
just 1 question right now:
why do you declare
SetSensorLowspeed(IN_2); //Ultra Sonic Sensor
both in task main and in task randomApproach?
one declaration should be enough (at first sight).
2nd question:
why do you start continuous tasks from a 2nd level task and not by task main?
mybe you can simplify it and the error resolves by itself....
...and be sure you are using the latest brickcc release and and the latest beta update and the latest enhanced firmware!
Re: US Sensor seems to stop in middle of program
Posted: 09 Feb 2011, 15:26
by babmoink
Hi guys, thanks for your answers !
Unfortunately I didn't have the robot with me so only now have I been able to test some things...
At first I checked I had the newest version of BricxCC and the enhanced firmware, which was the case. Still I re-installed the firmware, but it did not solve the problem.
I changed the name of the task "mesure" to avoid any possible conflict (though the compiler didn't seem to mind), added an instruction to stop the motor B in randomCourse, and removed the multiple declaration of the sensor (those were added when I used to think the problem came from the sensor).
2nd question:
why do you start continuous tasks from a 2nd level task and not by task main?
mybe you can simplify it and the error resolves by itself....
I think that might very well be the problem... What do you mean by "continuous task" ? I use the StopTask() and StartTask() functions to manage the tasks, along with Precedes in the main, and ExitTo... But it looks like there is some strange behaviour sometimes. I've added some musical instructions in randomApproach :
Code: Select all
task randomApproach() {
StartTask(randomCourse);
//SetSensorLowspeed(IN_2); //Ultra Sonic Sensor
Wait(1000);
int mesure = 300;
//while(mesure > 25) { //waits until something close is detected
// mesure = SensorUS(IN_2);
//}
while(SensorUS(IN_2) > 50) {
NumOut(0, LCD_LINE1, SensorUS(S2), DRAW_OPT_CLEAR_WHOLE_SCREEN);
//Wait(50);
PlayTone(294,16*__NOTETIME);
Wait(16*__WAITTIME);
}
...
}
At the beginning of the execution, it all goes as expected and I hear the tone when the robot moves around. But then at some point, for an unknown reason, the randomCourse is triggered but no tone is played. So I suppose the brick's scheduler never gives the control back to the task randomApproach()...
What could make this happen ?
Re: NXC: US Sensor seems to stop in middle of program
Posted: 09 Feb 2011, 17:29
by hassenplug
It's very hard to see what the program is doing, without seeing the whole program.
In the last clip you posted, if the randomApproach task is started while the value of sensor 2 <=50, it will start the randomCourse task, but NOT play a tone.
Steve
Re: NXC: US Sensor seems to stop in middle of program
Posted: 10 Feb 2011, 04:09
by afanofosc
Generally, I would avoid using start and stop (aka StartTask and StopTask) unless you cannot possibly figure out a way to do the same thing without them. Neither of these are supported by the standard firmware. Stop task, especially, and the workaround that allows start to work is tricky and could cause weird problems with the standard firmware. My latest enhanced firmware changes/fixes brought on by Doc Helmut's prodding have improved the way that these enhanced firmware features behave but it is certainly possible that you are running into an as yet unfixed bug in those enhanced features. If you don't really need two tasks running at the same time then don't use two tasks. If you want to use the ultrasonic sensor's value on multiple threads maybe it would be better to read it on just one thread and store the value in a global variable that you read on multiple threads. If you can use the firmware's native task scheduling mechanism (Precedes and/or Follows) then use that option in preference to stopping and starting tasks explicitly.
It would definitely help to see your entire program. You could zip it up and attach it to your next post.
John Hansen
Re: NXC: US Sensor seems to stop in middle of program
Posted: 11 Feb 2011, 21:57
by babmoink
Hello M. Hansen
This was a school project, and we had a final competition between robots on Thursday. The problem was not solved, but we were actually allowed to restart the program if it got stuck, so in the end my team did pretty well, ranking 2nd out of 4 ^^
Still if you want to understand better what was happening,
here is the website describing the competition, and we have a website describing our robot
here (the link on the other page - we were group #3 - needs to be updated). You can find a link to download the source code at the bottom of
this page.
As you'll see, I followed your suggestions, replacing the stop and start statements by using booleans. But still we encountered the mysterious problem. (I think it was happening less often though - but there was much confusion during the competition so it's hard to know ^^) Maybe because we did not re-install a standard firmware ? Unfortunately we have given the robot back now, so we cannot make any tests ourselves any more.
Hopefully the teacher will soon update the competition page with some videos of the competition so you see Rufus and its opponents in action !
Thanks for your attention, and for your work on NXC !