[FTC]: NXT control delay

[Dkt01]

Throughout the season, we've been having issues with a significant delay between gamepad commands and actual robot movements. This varies from ~.25s to ~.5s. We were going to just deal with it, but I realized the emergency stop is useless because of this. The NXT seems to be executing code with little to no delay (we've tested screen output of commands received and it is very responsive). The NXT will enter and exit programs like it should, but the motors and servos do not respond quickly (if we e-stop the bot, the program will end, but the motors will hold their previous state for up to 3 seconds).

I'll gladly provide more information on our setup if it will help solve the lag issue.

[PhilBot]

This is a hugely open-eneded question.

Yes... please provide more information.

eg:
Programming Language,
Connection method (usb/samantha/bluetooth),
Teleop code sample, (could be any number of bugs)

[Dkt01]

Originally Posted by PhilBot

This is a hugely open-eneded question.

Yes... please provide more information.

eg:
Programming Language,
Connection method (usb/samantha/bluetooth),
Teleop code sample, (could be any number of bugs)

Sorry about that, I was hoping it was some common issue.
We're using LabView.
We're downloading code via bluetooth, but running everything via the Samantha and the FCS.

A correction on the error stuff: there is still a half-second delay, but I was able to fix the E-Stop delay (now the motors don't run for several seconds after the E-Stop command). I did this by making the teleop a loop that continues while the robot is in teleop and there hasn't been a communication error (used the block that checks time between packets). I then used a sequence to force all motors to brake when teleop is ended or a connection error occurs. This seems to fix the danger issue, but if there is a connection pause in competition, this code would effectively disable the robot for the remainder of the match. If you have any suggestions, they'd be appreciated.

Like I said, our teleop code is basically just a loop that checks for new packets, then we made a VI to output a cluster of named axes and buttons. We then unbundle the cluster and use different buttons and axes to control the two drive motors (we made our own tank drive vi for programming practice, should we use the supplied vi instead?), a conveyor motor, a scissor lift motor, and a few servos.

Again, if I left out some important information, please let me know.

[PhilBot]

It doesn't sound like you are using the teleop template from this year.

The standard template does all the things that you say you coded.

The Template also shuts down all motors and servos when the robot is disabled, or loses coms.

I haven't been able to test whether the E-STOP sends a disable before shutting down the program... I will do that tomorrow, but without your code listing it's impossible to pinpoint a specific problem.

My question regarding the delay is: Does the delay occur all the time, or just when shutting down.

As for the tank drive... unless you have a specific reason for NOT using the one that's built in, it's probably a good staring point.

Sounds like you code is doing several tasks, any of which could be causing a problem. I can speculate about lots of different causes, but you probably don't want a generic answer. Attach the VI to your next post.

[EricVanWyk]

Originally Posted by PhilBot

It doesn't sound like you are using the teleop template from this year.

I agree with Phil (always a safe choice).

Try using the Joystick Editor to create, generate and download a default teleop program. This will tell you if the issue is in your code or it is more systemic.

[Dkt01]

Yeah, the template fixed it. Silly me. I didn't realize there even was a template.

Thanks for your help.