[FTC]: LabVIEW Programming Template for FTC

[RNasir]

Originally Posted by 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.

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]

Originally Posted by jbbjjbt

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]

Originally Posted by Team 288

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]

Originally Posted by RNasir

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]

Originally Posted by PhilBot

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.

[dickswan]

Originally Posted by PhilBot

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.

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.

[PhilBot]

Originally Posted by dickswan

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.

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)

[mjgard]

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

[RNasir]

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.

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.

[RNasir]

Originally Posted by PhilBot

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)

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.

[RNasir]

Originally Posted by PhilBot

Cool....

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

Thanks.
Phil.

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.

[jbbjjbt]

Originally Posted by RNasir

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.

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

[PhilBot]

Originally Posted by RNasir

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.

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.

[DavidGitz]

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.

[berngannon]

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