Autonomous code issue :(

[propionate]

A few potential problems I see with the overall structure:

1. Your "Wheel Distance" VI's are both inside of a while loop. They will be constantly updating, so the drive motors will never actually reach their goal of 50cm.

2. There is no wait timer in the while loop. You may want to add one to avoid any potential cRIO lag issues.

3. You are writing to the drive motors in 3 separate places that I can see. This is generally not a good idea, as LabVIEW gets confused pretty quick if multiple VI's are giving commands to the same motor.

Number 3 is what is most likely causing the problem. Here is some code that should do what you want:

http://i.imgur.com/R1Ukf8Y.png

Instead of your custom VI, I just created a case structure as a placeholder. It works on the same principle as yours, except there is no need to add the 50cm and then subtract off. Simply reset the encoders using the "Reset Encoder" global variable *before* you enter the while loop/first case, and that way you can be sure they will start at 0. It advances to the next case if both encoders have reached 50cm.

[bumblebee3339]

Originally Posted by bvisness

It could be a motor safety problem, since you're only commanding the tank drive output once, and then entering your two loops. You should probably put the tank drive at 0.5 block inside the loop to avoid that problem.

Besides that, your code looks quite good! I'm not sure what your problem would be.

It might be the problem, I'll report as soon as I try to fix it agian. Thx.

Originally Posted by propionate

A few potential problems I see with the overall structure:

1. Your "Wheel Distance" VI's are both inside of a while loop. They will be constantly updating, so the drive motors will never actually reach their goal of 50cm.

2. There is no wait timer in the while loop. You may want to add one to avoid any potential cRIO lag issues.

3. You are writing to the drive motors in 3 separate places that I can see. This is generally not a good idea, as LabVIEW gets confused pretty quick if multiple VI's are giving commands to the same motor.

Number 3 is what is most likely causing the problem. Here is some code that should do what you want:

http://i.imgur.com/R1Ukf8Y.png

Instead of your custom VI, I just created a case structure as a placeholder. It works on the same principle as yours, except there is no need to add the 50cm and then subtract off. Simply reset the encoders using the "Reset Encoder" global variable *before* you enter the while loop/first case, and that way you can be sure they will start at 0. It advances to the next case if both encoders have reached 50cm.

1. I checked it, and the comparison is performed on the value before the loop + 50 and the current value so it can reach it (I moved the robot manually and it worked).

2. How much ms would be the best choice? is 10ms enough?

3. I dont write to the same motor at one time. on the left I give both the same value and on the right the upper controls the left motor and the lower controls the right motor. Is it still might be connected to the problem?

And thx for the code I'll try it !
BTW what is the "Reset Encoder" global variable? I know only about the encoder reset vi, is that the same?

Thx agian !!

[propionate]

Originally Posted by bumblebee3339

It might be the problem, I'll report as soon as I try to fix it agian. Thx.



1. I checked it, and the comparison is performed on the value before the loop + 50 and the current value so it can reach it (I moved the robot manually and it worked).

2. How much ms would be the best choice? is 10ms enough?

3. I dont write to the same motor at one time. on the left I give both the same value and on the right the upper controls the left motor and the lower controls the right motor. Is it still might be connected to the problem?

And thx for the code I'll try it !
BTW what is the "Reset Encoder" global variable? I know only about the encoder reset vi, is that the same?

Thx agian !!

1. Good catch - I wasn't considering my own advice about nested loops.
2. I would suggest something like 30 or 40ms. You can go lower, but it will eat up more CPU usage.
3. I think it will still be problematic because each iteration of the larger while loop contains two commands to each set of drive train motors.

The Reset Encoder global variable may have been more out of habit. I normally put the encoder code in periodic tasks, and you can use a global variable to reset the encoder from any other VI (in your case, autonomous). Using the Reset Encoder VI and a inputting a constant in autonomous will achieve the same result.

[Alan Anderson]

Your problem is almost certainly the motor safety. A tenth of a second after you enter the inner While loop, the drive motors will shut off because they're not being commanded. Moving the first Tank Drive inside the loop should correct that.

Originally Posted by bumblebee3339

3. I dont write to the same motor at one time. on the left I give both the same value and on the right the upper controls the left motor and the lower controls the right motor. Is it still might be connected to the problem?

It's not connected to the problem you're working on right now, but it still is a problem. Tank Drive doesn't control individual motors. For example, if you don't connect anything to the Left input, it assumes a value of 0 and stops the motor anyway.

If you want to do things the way it looks like you're trying to, then you should have only a single inner While loop instead of the two parallel ones. Inside that loop, set the Left input to Tank Drive to either .5 or 0 depending on whether the left encoder has reached its target. Simultaneously set the Right input to either .5 or 0 depending on whether the right encoder has reached its target. If both encoders are at or above their set point, exit the While loop.

[bumblebee3339]

Thx to all of you ! I got some great tips here and I finally got this to work..
The saftey config was the main problem, putting the drive command in the loops made it move - but it didn't move smoothly.
The second problem which I encountered was that the Crio couldn't handle both of the loops so it gave the right a value, stopped it, gave the other side a value and so on...
Finally I made one loop (to rule them all!) simiilar to Stephen's (propionate) idea, thanks alot !

I might be uploading an image of the correct code soon