[FTC]: Progress report on using encoders

[PhilBot]

Originally Posted by jbbjjbt

We've been messing with the encoders for autonomous and haven't much success so far using Labview. We had a lot of difficulty. We'd run the same program 4 times and get 4 totally different results. Sometimes both encoders reset, sometimes only one, sometimes none.

Hmmm. I had reported that to NI a while back. I found that the "failure to reset" seemed to be related to the speed that you commanded the motors to move afterwards.

If you sent an encoder reset command, and then gave the motor a high power move, it was more likely to ignore the reset state and revert back to the last encoder count. However, if you only gave a low power move, it seemed to keep the reset most times.

It's as if there is some race condition that if the encoder counts before the reset is complete it gets messed up.

I've really been hoping that I could use LabVIEW for both FTC and FRC, but if it's not reliable I'm going to be forced to change.

Any issues to report with RobotC?

[jbbjjbt]

Originally Posted by PhilBot

Hmmm. I had reported that to NI a while back. I found that the "failure to reset" seemed to be related to the speed that you commanded the motors to move afterwards.

If you sent an encoder reset command, and then gave the motor a high power move, it was more likely to ignore the reset state and revert back to the last encoder count. However, if you only gave a low power move, it seemed to keep the reset most times.

It's as if there is some race condition that if the encoder counts before the reset is complete it gets messed up.

I've really been hoping that I could use LabVIEW for both FTC and FRC, but if it's not reliable I'm going to be forced to change.

Any issues to report with RobotC?

That sounds very much like what we were trying to do: come down the ramp slow, reset encoders, then go full power.

We've spend very little time and effort on RobotC so far. It blows my mind when it compliles and downloads in about 1/2 second.

[PhilBot]

I just setup a LabVIEW ap to illustrate the problem.

This code runs a loop where the encoders are reset, the motors run for a second, and then stopped for a second. This repeats while the encoder position is charted.

The first attached images are bad case where the motors are turned on immediately after resetting the encoders. The data shows how often the encoders don't get reset.

The second image set is better, I assume, because there is some delay between the reset and move. Only forgets to reset a couple of times

Adding a delay probably helps this code, but I want to know for sure that the encoders will reset properly.

[jbbjjbt]

Phil,
Please explain how this program works. You are running the motors and encoders on the NXT but plotting on the pc screen. Is that correct?

Are you running this code on the pc or on the NXT? How is the NXT connected to the pc?

I had no idea you could do this, please tell me how.

Thanks,

[PhilBot]

Hi

What you are seeing is a standard debugging feature provided by LabVIEW in conjuction with the NXT.

If you are using LabVIEW you must be using the NXT Terminal to download and run the program. You are probably pressing the left hand icon on the terminal to run the program.

Instead, if you press the third icon over (Arrow pointing to lightbulb) it will compile and download the program and then maintain a connection with the running program for debugging purposes. Any LabVIEW display elements that you have included in your NXT program will now operate and be visible on the PC's normally-empty front panel. (This is one of the main reasons I planned to use LabVIEW.... it's a powerfull debugging tool).

There are (of course) the usual caveats: It slows down your program a bit, and it only updates at the bandwidth available by your link to the NXT.

For bench testing this program, I don't need the Bluetooth link, so I connect to the NXT with USB. It provides a pretty good debug window.

For robot testing (on the bench), you can download and debug via USB, while the Bluetooth is used by the Controller program.

I haven't found a way to debug while driving on the field yet

Try this yourself by LEFT-clicking on any wire and selecting "Create - Indicator".
The indicator will be added to both the block diagram and the Front panel.
Change it to any graphical type you like.
When you start debugging, there is a several second delay before the Front panel starts updating... so be patient.

Note: I've attached the LV program that shows the bad encoder resets.
Download (debug) it using the method I expalined and just let it tun.


Phil

[jbbjjbt]

Phil,
Thanks for explaining, hopefully I will try this feature tonight. It could be very helpful.

[RNasir]

I'm in work on a fix for both the resetting issue and the Constant Speed driving issue now. I'll let you folks know as soon as I have something ready.

[jbbjjbt]

Originally Posted by RNasir

I'm in work on a fix for both the resetting issue and the Constant Speed driving issue now. I'll let you folks know as soon as I have something ready.

Thanks, we are looking forward to it.

[jbbjjbt]

Phil,
We tried your encoder test program and got similar results. We added a loop to reset the encoders again if the encoder value was greater than 5. This worked for resetting the encoders. But the constant speed vi messed up occasionally and the motors ran on for 2.5 seconds. We then replaced the constant speed vi with move motors vi and got identical results.

[RNasir]

I have a tentative fix available now. I want to do some more testing in-house before officially releasing it, but I can send it to any teams that would like to try it out before that happens (sometime next week). If you're interested, send me an email at ramsey.nasir@ni.com and I'll send you the fixed files. Please be sure to specify in your email whether you use LabVIEW or NXT-G (or both).