[FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Great! My team will try it out.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Copying Phil's suggestions posted in another thread:

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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)

Re: [FTC]: LabVIEW Programming Template for FTC
 

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

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Good idea... I'll look for a good USB extension cable :)

Re: [FTC]: LabVIEW Programming Template for FTC
 

[quote=PhilBot;771468]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,

Re: [FTC]: LabVIEW Programming Template for FTC
 

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

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

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

Re: [FTC]: LabVIEW Programming Template for FTC
 

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

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

We checked it, and got:

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

I have the same...

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

Re: [FTC]: LabVIEW Programming Template for FTC
 

Cool....

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

Thanks.
Phil.

Re: [FTC]: LabVIEW Programming Template for FTC
 

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.

Re: [FTC]: LabVIEW Programming Template for FTC
 

I would suggest a different approach described below.

On the PC side, the game controllers are scanned every 50 milliseconds and their status sent, via Bluetooth, to the NXT. Normally the Bluetooth message (less than 20 bytes) takes less than this time to transmit.

Your message processing "loop" should be running much faster than this. If it is not, then there's likely something seriously wrong in your program!

So what I would suggest instead is that you put a short tone playback in the message received "true" case. Something like 1500 Hz for 65 milliseconds. 65 because it 50 + 15:

• 50 milliseconds scanning rate.
• 15 milliseconds because I think this is Bluetooth's period. Depending on when you send a message it may take up to 15 millisecond to transmit (I think).
  

If everything is working well, then you'll get a nice constant (and annoying) tone of 1500 cycles. If anything is delayed, then there will be a break in the tone and you can gauge the length of the delay. Note that a new "play tone" will abort the previous tone if it is still in progress.

I have measured and noticed that sometimes a BT transmission can take well over 100 milliseconds. This is readily apparent with the above test.

NOTE for ROBOTC Users:
There's an optional feature in ROBOTC firmware than reduces most of these long duration packets.

ROBOTC has an integrated Controller Station applicaton that already has this audible feedback feature built in. You don't have to do anything in your program. It's enabled by a check box on the PC window. Up to now, it was playing a short blip tone on every 10th message. I just changed it to above. The way it works is it sends the "PlayTone" request to the NXT along with the Game Controller update.

Re: [FTC]: LabVIEW Programming Template for FTC
 

The NXT terminal won't let you download the program unless you have the 1.21 firmware installed. So no chance of running incompatible code.

I'm not getting any consistency on the tests I do with different programs and on different computers and NXT's.

I absolutely saw a large response delay with the Floating Point Joystick processing in place, that went away when I just deleted it and used a wire to bypass the code. I did this several times .

However, based on your post I did some time tests on the JS code, and sure enough it runs VERY fast.

So I ran the original code on a NXT WITHOUT a motor controller attached and it runs like lightning.

So... something in the I2C protocol, or interface code, interracting with the FP code? Maybe interrupts are disabled?

Anyway, since the developer has said that there is a bug, I'm loath to worry about it any more until we see an update. Hopefully he will post something about the underlying bug so we can say "oh, yeah... that explians it" (hint, hint)

Re: [FTC]: LabVIEW Programming Template for FTC
 

Could someone provide us with a program that we can use to test our drive system. We have not gotten to a point to do our own programming yet and havent been able to meet with our programming mentors and get them up to speed with labview. So we need some help. Thank You.

Mike
FTC and FRC Team

Re: [FTC]: LabVIEW Programming Template for FTC
 

When you connect to the Controller Station, it should automatically download Program Chooser and FTCTeleOp to your brick. You can use FTCTeleOp to drive your robot, assuming you've got a standard 4-wheeled setup like the example robot. You'll find the source code for it in the LabVIEW 8.5\examples\FTC Toolkit directory.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Basically, I just removed the encoder read from the Move Motors VI/block. It could very well be the cause for the delays you saw - it added two I2C read/writes to each motor call. It's a little bit more involved than that, so I don't recommend removing it yourself - the fix will be up in the next few days and I'll post a link then.

EDIT: Removed the caution against use of floating point in NXT-G/LabVIEW. It was in fact intended for use with FTC AND tested - just not by me and before I joined the FTC project. Sorry for the confusion.

Re: [FTC]: LabVIEW Programming Template for FTC
 

The download is live on the new software. Look here:

http://joule.ni.com/nidu/cds/view/p/lang/en/id/1129

Have fun!

EDIT: It's the same location as the original encoder update and the update for braking. Rather than put up several different versions of essentially the same software, we've just been updating the updates.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Thanks. I missed this yesterday, so we will try the FTC Move Motors over the weekend.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Thanks very much, I'll try it out today.

ps:
Any chance you can put more detailed information in the "Version" and "Release date" fields of the NI page header? It currently just says: Version 2009 and Release Date 09-2008. The file name is the only real clue that this update had changed.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Is FW 1.21 available for public download? I'm a mentor for an FRC team but we would like to start mentoring a FTC team as well, and I have an NXT and would like to start working with some of the programming for it.

Re: [FTC]: LabVIEW Programming Template for FTC
 

Hello,

I thought I'd drop you a line. I'm an instructor who is a week out from our FTC comp and can't get the NXT to talk the motors with labview. If you can find me some help call me at 5098388471. I'm figuring if you can setup your own teleop prgm you might have the chops to help me. Thanks

Bern

Re: [FTC]: LabVIEW Programming Template for FTC
 

Number 1 recomendation is to do a quick run through the "Getting Started with LabView for FTC" manual that shipped with the KIt, or read it online. Search NI site: www.NI.COM/FIRST

It describes setting up the motors and running "TheMechanic" program to test your motor wiring. It's a great diagnostic tool.

What is your specific problem?
No response at all on DC motors?

- Did you start with the FTC_TelopBasic.vi tempate?
- Have you verified that the Motor controllers are powered (does the RED LED glow).
- Have you told your program where the motor controllers are plugged in (default is Port 1 controller 1) Wiring MUST match Program.
- Are you running the Controller Program on the PC or the Field Control Software?
- Have you made a bluetooth/USB connection and enabled the program?

What is the display on the NXT saying? Offline, Enabled or Disabled?