Help with speed control set up

[zombieslayer16]

We are using a sonar sensor with our robot, we want the the robot to slow to a stop when in a certain range of the wall. That range is defined at the average of the minimum and maximum values defined by the driver station. I know we could implement a more elegant solution but with our limited programming skill this is the best we could come up with. The problem is that when the button is held down the robot seems to constantly go at a slow speed and never slows to a stop, even when started at the stopping point and the button is held.

Thanks in advanced

[Mark McLeod]

Have you run it in debug mode and probed the values to see if they are what you expect?

A couple of problems with the loop itself:
- That loop does need a delay to avoid maxing out the CPU as it's doing now.
- That loop executes only once. When you really use it is it inside some other loop or are you using the continuously looping debug (the button with two arrows chasing each other)?

It's difficult to tell how your math works itself out.
What are typical values you are using for Sonar Min and Sonar Max?

[Alan Anderson]

Where did you place this code?

It's a "while loop" that terminates immediately, and there aren't any shift registers to maintain values from one execution of the loop to the next, so it's just as if there were no loop at all.

[zombieslayer16]

I was trying to show that piece of code by itself, this actually goes inside our teleop VI. I tested the values of, the numbers seem to come out fine. We usually have the min and max set to 60 to 90 respectively.

[Mark McLeod]

It seems like the value at the test for <= 6 can never be lower than 75.
That's the only test that is capable of outputting a speed of 0 while button 10 is pressed.

(60+90)/2-0v/.0098=75
(60+90)/2-5v/.0098=435

[Jmulderig]

Mark wouldn't the 5v be -435. So if the voltage was .735 then your final would be 0?

[Mark McLeod]

Opps, yes. Although, the <=6 test uses an absolute value there is a small gap where the result will dip down < 6.
Thanks for the correction Jake.
I was working on three different team codes at once and started getting them confused. In addition to this mistake, I also mixed up the code and sent Connectquot this sonar code by accident. Long days.

So, there is a pretty small range where the motor should be moving.
They did say they probed the numbers and were satisfied with what they saw.
I assume that means that the sensor values changed properly according to distance. Plugging the sensor in backwards for instance would probably result in a constant unchanging voltage.

[Jmulderig]

haha yes mark my eyes are not as straight as they were 6 weeks ago either...
yes we got all appropriate outputs from the sensor when we look at the drivers station reading. we then positioned the robot at the exact avg out put held button 10 and the robot still took off when we moved the joystick we were getting it to slow down a little maybe to the first step but that range was hard to judge in our confined space.

I know edwin even made a little applet in labview using that same code that we could type in a sonar value and joystic value and it would tell us the moptor output and that all worked well.

[Mark McLeod]

The best suggestion I could make would be to run the code in debug with something in front of the sensor at the desired distance, then probe the code starting at the Motor Set Output and work backwards to identify where the non-zero value is being set, and why the 0 isn't being set.

I'll see if I can test your code on a robot with a range sensor, maybe tonight.

[Jmulderig]

ok thanks

[Mark McLeod]

Because the <=6 test uses absolute value there is a very tiny range .0588v wide where the test will pass.
This is what I forgot before when I did that quick min/max calculation (and I forgot to note that it was absolute value).

Specifically, from the raw sensor readings:

• 0v to 0.6761v fails the test
• 0.6762 to 0.735 passes the test
• 0.736 to 5.0v fails the test

I couldn't get my sensor to hit that tiny range last night and trigger a 0 speed.

I'd suggest positioning your sensor at the min and max of where you want the robot to be, take the sensor readings at both positions, and I wouldn't test for being between those two raw sensor marks. I'd just test for being less than the first one. The way it's setup now, if the robot doesn't stop within the 6" it overshoots the mark and drives away.