[FTC]: Progress report on using encoders

[PhilBot]

I finally got back to FTC programing.

I’m now using the latest FTC update, which has a bugfix for the “FTC MOVE MOTORS.VI” which was apparently having trouble with reading the encoder.

So I took Team 288’s template and switched the drive logic for a single stick drive, ensuring that I clip the motor drive signals to +/- 100.

Yay… the program works with no huge delays and no weird “dead times”.
It seems like “move motors” is pretty robust at this time.

So, I then had to try what I really wanted to do, and that was to replace “Move Motors” with “FTC Constant Speed.vi”

Constant speed should use the encoders to provide a more consitent driving experience, with better low-speed control and less degredation as the battery voltage drops.

I replaced the VI’s and made sure the controls were compatible.

When I initially started running the new program it was great. It could crawl along with good torque, and turning was very nice. Then, the old 2.5 second drive lock started happening, followed by long periods of no control at all. Then everything starts working just fine for a while.

Anticipating this problem I has tied one of the controller buttons to a tone output, so I could verify that even though the drive wasn’t responding, the code was correctly seeing the button press., so Comms was good.

I switched back and forth between “move motors” and “constant speed” several times and each time I used Constant Speed, I would get the random drive failures.

It looks to me that there are still issued with the encoders. This is a new set of hardware, so I don’t think it’s a coincidence that it’s hapenning again.

Anyone out there using encoders for speed control? Is it reliable?

Phil.

[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. I hadn’t even thought about them for driving, except for the arm.

However, our when we attempted the same stategy using RobotC sample codes it worked. The Robotc codes had some logic waiting for the encoders to give the correct results. So it may be a coding issue in Labview.

[PhilBot]

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]

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

EncoderTestLoop.vi (36.1 KB)


EncoderTestLoop.vi (36.1 KB)

[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]

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).