[FTC]: LabVIEW Programming Template for FTC

[Team_288]

Our lead programmer has created an awesome template using LabVIEW. It takes care of many issues that could cause problems:

-Disable Flag: this allows the field to shut down your robot after Autonomous and Teleoperated modes

-Autonomous/Teleoperated Switch: this allows you to put both modes into one program and will allow the field to tell them when to run

-Logitech Controller Dead Zone/Scaling: this takes care of the issue of the Logitech controllers not returning to zero when released, it also scales the input value from the controller to allow more precise maneuvering

This program has lots of notes that will assist you in customizing it to suit your robot.

The attached zip file contains the template and the custom scaling VI. Keep them in the same folder so the template can locate the scaling VI.

Please feel free to check the program template for any errors (we have checked it over for many hours now and can’t find any more mistakes).

Please let us know how it is working for you, and if you have any questions email or call (our contact info can be found on a note inside the program template), we will be glad to help.

Competition Template - from FTC Team 288.zip (32.1 KB)


Competition Template - from FTC Team 288.zip (32.1 KB)

[Monty_Python]

Great! My team will try it out.

[Richard_Wallace]

Copying Phil’s suggestions posted in another thread:

[FTC]: Pros/ cons of programming languages

… That’s pretty cool and useful. In many ways it mimics the template that shipped with the FRC LabVIEW beta test. Lots of good comments too.

I’ve been playing with the encoder controls a bit, and your code would be easilly adapted to that to (constant speed vs move motor)

My only trivial suggestion is that instead of inverting the drive signal to one motor, you can set the “Invert” input to “true” for that wheel.

The only reason I mention this is because if you do end up using the encoder based motor drives, the “invert” input is also used by the encoder code, so both motors will count in the same direction, even though one is running in “reverse”.

[Team_288]

In an effort to explain the code that fixes the dead zone and motor scaling issue so that others may better understand how it works, our lead programmer has put together a detailed document. You will find it attached to this post.

Dead Zone Scaling Documentation.doc (50 KB)


Dead Zone Scaling Documentation.doc (50 KB)

[lynca]

Im glad to see teams posting programming Labview resources for FTC. I have taught a couple NXT Labview workshops and this is actually a bit more difficult to get working and understand than VEX or NXT-G.

Hopefully if teams take the time to learn to use the Labview Toolkit with the NXT it should help tremendously with learning the new FRC 09 controller.

[PhilBot]

SInce this seems to be a good place to discuss Labview FTC issues, I have some observations and comments.

I’ve been playing with the LabVIEW NXT and FTC VI’s for a while now, and I’ve also started using Team 288’s cool template.

So far, my satisfaction with the new FTC system is not so hot.

My biggest compaint is that the telemetry isn’t fast or reliable.

For example, I’m running the Controller application on my somewhat dated desktop (2GHz pentuim 4 CPU), The screen responds to joystick changes pretty fast, but the robot’s response is pretty sluggish. It doesn’t seem to matter whether I use Bluetooth or USB… I get the same response.

I can jog the joystick and let it return to home, before the NXT even starts to turn it’s wheels. Almost 1/2 a second delay. That makes it hard to drive.

I’ve also noticed that the wheels don’t always respond on command. Thsi may be since I’ve installed the new FTC toolkit, but I’m not sure.

Since I like to try my best to debug problems, I needed some way to determine where my problem lies. So what I did was add an audio debugger to the NXT. I basically wired a very short tone to the same signal that’s driving the motor controller. I used a base frequency of 1000 hz, and used the motor drive signal to sweep the tone by +/- 400 Hz.

Now I can see if the link is the problem or if it’s the motor controller.
I only get a tone when a GOOD command is received by the NXT from the PC.

It was quite interesting what I learned.

1. The first thing I learned was that the delay is certainly before the motor driver. The tone follows well behind my joystick movements.

2. Next I learned that the telemetry link is pretty reliable. It does seem to change it’s update rate a bit, based on where the robot is located, but it never drops out unexpectedly.

3. Since the link seems solid, the flakey motor behavior must be in the Motor controller or it’s interface. Every now and then a motor will run on, or fail to start, even though the “tone” clearly indicates that the NXT knows the motor should be doing something.

Not sure where this leaves me, except to ask the comunity if my results are typical or unusual. Was there a FTC beta test group and what did they discover?

I’ve added a picture of the audio debugger I created… it’s actually fun “hearing” what the link is requesting.

[PhilBot]

OK, I’ve done some more testing and I have some usefull information.

1. I’d recommend that everyone put a “beep” in the case statement that runs when the NXT Bluetooth VI returns a non-packet status. Specifically when “Message Received” = False. You can quickly determine if you have problem reception-errors. 200ms at 200Hz is pretty noticable.

Wheras I “thought” that the link was running prety smoothly, at some times it just seems to drop out (for me) and start beeping for no reason. I wonder if there is a “high Power” bluetooth base station I can find?

2. Sorry team 288, but your Dead-Zone scaling is a major CPU hog, and on my NXT it introduces a very noticable delay. I suspect that it’s the floating point divide and two floating point multiplies. Without a floating point processor, divides can take a long time.

I just went back to using my own deadband, and the Toolkit’s motor scale vi.
Driving is almost managable now… (still not as responsive as a standard radio control with servos though)

[jbbjjbt]

We’ve been having a lot of issues with driving also. The robot would respond fine, then stop responding or drive in a circle for a while then start working again.

One test I did was to make an all NXT/Lego bot driving on lego motors. It drove fine never obviously losing signal. It seemed very responsive. So the issue does not seem to be bluetooth.

Back to the FTC system. We tried replacing wires and the motor controller with not much luck. We have to motors installed but not the encoders. In examining the FTC Move Motors VI, it calls the encoders. When I replaced the VI with the original August VI that came on the cd’s, the robot responds much much better. It also seemed to help by hanging the computer with the bluetooth dongle out over the field.

Jon Thompson
Coach FTC 177
Twisted Bots

[PhilBot]

We’ve been having a lot of issues with driving also. The robot would respond fine, then stop responding or drive in a circle for a while then start working again.

Yeah, that’s what we get too. Something to consider…
The motor controller (don’t know if it’s S/W or H/W) has a 2 second timeout. So if it stops getting commands, it will continue to do the same thing for 2 seconds and then coast to a stop. This often explains the driving in a circle effect: if only one motor is running when the commands stop… it circles for 2 seconds and then rolls to a stop.

It also seemed to help by hanging the computer with the bluetooth dongle out over the field.
Twisted Bots

Good idea… I’ll look for a good USB extension cable

[jbbjjbt]

Yeah, that’s what we get too. Something to consider…
The motor controller (don’t know if it’s S/W or H/W) has a 2 second timeout. So if it stops getting commands, it will continue to do the same thing for 2 seconds and then coast to a stop. This often explains the driving in a circle effect: if only one motor is running when the commands stop… it circles for 2 seconds and then rolls to a stop.

QUOTE]

Where did you learn about this? This seams to be the issue?

Also from farther up the thread, do you know any way to have a non-linear scaling that isn’t a memory hog?

Thanks,

[PhilBot]

>> Where did you learn about this? This seams to be the issue?

I was communicationg with a developer at NI and he said:

The motors have a watchdog timer of 2.5 seconds, after which they will automatically shut off if they don’t receive any commands. I disabled it for finite operations like moving X rotations, but for potentially infinite operations (like running unlimited or running at constant speed), I left it enabled.

>> Also from farther up the thread, do you know any way to have a non-linear scaling that isn’t a memory hog?

I don’t think this is really that essential, since “most” driver just bang the controls, but an alternative would be a simple two slope scaling… eg: a scale of 0.5 for the first 50% of the Stick travel, and then a scale of 1.5 for the second 50%. This gives you full scale for 100% travel:

( 0.5 * 0.5 ) + (1.5 * 0.5) = 1.0

[Team_288]

instead of inverting the drive signal to one motor, you can set the “Invert” input to “true” for that wheel.

Done. Thanks for the suggestion, we hadn’t noticed the ‘invert’ input.

Sorry team 288, but your Dead-Zone scaling is a major CPU hog, and on my NXT it introduces a very noticable delay. I suspect that it’s the floating point divide and two floating point multiplies. Without a floating point processor, divides can take a long time.

We’re sorry to hear that you experienced this with our code. In all of our (admittedly very unscientific) tests, the robot seems to respond to its controls instantly. In an effort to improve speed, we have re-done the scaling so that it now uses only one integer division, and never deals with floating point numbers. This should be faster, but we are honestly unable to notice any difference.

We would appreciate it if you could try out the improved scaling code and see if our changes have any impact.

On another note, we have noticed that many computers have trouble displaying the formula embedded in the scaling paper, so we exported it to a PDF.

Dead Zone Scaling Documentation.pdf (41.5 KB)
Template Code V1.1.zip (179 KB)
Quadratic Control Scaling and Dead Zone.vi (13.6 KB)


Dead Zone Scaling Documentation.pdf (41.5 KB)
Template Code V1.1.zip (179 KB)
Quadratic Control Scaling and Dead Zone.vi (13.6 KB)

[PhilBot]

In all of our (admittedly very unscientific) tests, the robot seems to respond to its controls instantly.

Really! That’s odd, because it’s very noticable on my NXT’s.

I’m wonderng what the possible differences might be. We both should be using the same NXT firmware. Did you download the recent FTC Toolkit update (released on Oct 16th)? I did, so I wonder if this could make a difference.

I just installed your code right as it came, and got the delayed response. There is no doubt it’s there.

I wonder if the NXT internals have changed recently. When I get a chance I’m going to look at the internal Settings/NXT version info. in the brick to see how it compares with yours. Can you lookup and post that info when you get a chance?

I’ll try the new code when I get a moment.

[jbbjjbt]

Really! That’s odd, because it’s very noticable on my NXT’s.

I’m wonderng what the possible differences might be. We both should be using the same NXT firmware. Did you download the recent FTC Toolkit update (released on Oct 16th)? I did, so I wonder if this could make a difference.

Philbot,
Do you have encoders on your drive motors and are they hooked up? We don’t and the new move motors vi definitely has delays if you don’t have encoders.

[Team_288]

I’m wonderng what the possible differences might be. We both should be using the same NXT firmware. Did you download the recent FTC Toolkit update (released on Oct 16th)? I did, so I wonder if this could make a difference.

We had not installed that update, so we put it on one computer as a test. We did not notice any lag in the NXT’s performance.

I wonder if the NXT internals have changed recently. When I get a chance I’m going to look at the internal Settings/NXT version info. in the brick to see how it compares with yours. Can you lookup and post that info when you get a chance?

We checked it, and got:

FW:   1.21
AVR:  1.01
BC4:  1.01
BUILD 0508081346
ID    0016530857F2

[RNasir]

We’ve been having a lot of issues with driving also. The robot would respond fine, then stop responding or drive in a circle for a while then start working again.

I don’t believe this is a result of communication problems. I’ve discovered a bug in my LabVIEW and NXT-G implementations of Move Motors that causes this behavior. We will be issuing an update as soon as I’m sure it’s fixed - it’s in testing now.

[PhilBot]

Philbot,
Do you have encoders on your drive motors and are they hooked up? We don’t and the new move motors vi definitely has delays if you don’t have encoders.

Well, I do sometimes… We’re trying a few drive combinations and only have the encoders on one set of motors.

I looked at the code and although there does seem to be a call to “GetEncoders” the call just seems to be setting some flags. No sure why it’s there. The Move command is just a fixed power command as far as I can tell… not sure why there should be any extra delays… but I’ll take your word for it… I gues I better test it both ways to see if I get simmilar results.

Too bad if I want to drive the motors without encoders…

Phil.

[PhilBot]

FW:   1.21
AVR:  1.01
BC4:  1.01
BUILD 0508081346
ID    0016530857F2

I have the same…

but it looks like there may be a fix in the works… Woo Hoo !

[PhilBot]

I don’t believe this is a result of communication problems. I’ve discovered a bug in my LabVIEW and NXT-G implementations of Move Motors that causes this behavior. We will be issuing an update as soon as I’m sure it’s fixed - it’s in testing now.

Cool…

Once the new code is online, can you post a link here as well, Please…:]

Thanks.
Phil.

[dickswan]

2. Sorry team 288, but your Dead-Zone scaling is a major CPU hog, and on my NXT it introduces a very noticable delay. I suspect that it’s the floating point divide and two floating point multiplies. Without a floating point processor, divides can take a long time.

The “standard” NXT-G firmware (i.e. version 1.05) does not support floating point variables. FTC uses a special version of NXT-G firmwre (version 1.21); I don’t know whether this has changed fror it.

The LabVIEW toolkit for NXT compiles your program into a object file for execution on the NXT. It does not warn you about the lack of floating point.

In any case, floating point calculations on the NXT are quite fast. They take 5 to 15 microsecnds depending on the operand – division is the slowest. This is inconsequential for this particular application.

• The PC application only scans the joysticks at a 50 millisecond rate!
• The NXT’s Virtual Machine that interprets the “object code” takes 40 microseconds or more for simply opcodes.
• The NXT communicates with the Motor Controller over a slow I2C messaging link. It takes 5 to 10 milliseconds to send a message.

ROBOTC does support floating point variables. And its I2C messaging to the Motor Controller runs 3 to 5 times faster than NXT-G.

So it is unlikely that floating point calculations are the culprit.