[FTC]: 35's Drive problem
 

We've been working on our robot for the past several weeks and we are about done with construction and programming. We are having a slight problem with our controls. Everything we tell the robot to do in teleop is delayed by about 1/2 a second. The arm is toned down enough that it's not that big of a deal, but the delay is making driving the base VERY difficult. We are using labview and we have applied all updates. Is anyone else having similar issues?

Re: [FTC]: 35's Drive problem
 

I remember this problem being discussed on FTC Lab, but the site is down now so I cant get the thread for you. I believe it had to do something with the way you get the data from the control. Anyone else have a clue?

(By the way, nice robot!)

Re: [FTC]: 35's Drive problem
 

My team is also having the same problem, I THINK it is because this controller uses blue tooth and I'm guessing the 1/2 second delay is because of the blue tooth lag. I should check that site myself regarding this issue.

I agree with Lowfategg, you do have a really nice robot xD

Re: [FTC]: 35's Drive problem
 

My programmer was saying he thinks it's because we are running Windows on a Mac (something to do with how the software and the hardware interface). i just can't see how we are running into a hardware issue with what we are asking the computer to do. I believe it's software based. I trolled around FTC Lab and couldn't find anything useful. Is this something i should take straight to NI?

Re: [FTC]: 35's Drive problem
 

There seems to always be a lag time in my experience.

just a question, are you using a "deadband" in your code like:
((I know its a robotC code, but it just to show an example))

I found that it reduced our lag, though did not make it go away. To really slim down the lag, the smaller the routines the robot has to go through, the faster you will get the code to run on the NXT. The NXT isn't extremely powerful, if you overload the processing power with many routines preforming at once, the cycle rate might be reduced.

Something else we found was that RobotC had the smallest lag time in the NXT, followed by LabView, and trailed by NXT-G. I'm not sure why this is, but it is one reason we stuck to the RobotC.

Just try the deadband, it might atleast help with makign sure your robot comes to a stop (because often if you don't have the deadband, the robot won't come to a stop completely).

Re: [FTC]: 35's Drive problem
 

I tried to program a deadband in labview but it didn't really work, and I have yet to get the chance to fix it. But yea, my team will definitely try that.

Re: [FTC]: 35's Drive problem
 

That's where we were headed at tomorrow's practice. What concerns me is this: We didn't have this problem with the VEX system. Doesn't the NXT system have a faster CPU than the VEX? It seems strange that we would be taxing this new system with simple drive commands.

Re: [FTC]: 35's Drive problem
 

I doubt the system is experiencing lag. I'm sure there's something with the code.

BTW, the curiosity is killing me, but can your robot score in the center triangle?

Re: [FTC]: 35's Drive problem
 

we have similar lag in our robot and we are pretty sure that it is the programming language. one of our mentors is pretty sure that in robotC there will not be as much lag. Also Wilsonmw04 nice robot. does it score into the triangle and how well does it pick up off the ground? we had similar design at the beginning but decided not to use it because we didnt think it would pick up well and we had other ideas.

Re: [FTC]: 35's Drive problem
 

Make sure you've updated labview. They said there was an error with the move motors vi that would cause the lag.

Re: [FTC]: 35's Drive problem
 

I have all the updates but I'm still experiencing lag.

Re: [FTC]: 35's Drive problem
 

We installed both updates from NI site. I double checked the installation process and everything was done correctly. Are there any other updates that I'm not aware of?

Re: [FTC]: 35's Drive problem
 

Your best chance now would be to try and hook with someone at NI to get some help and try and figure it out.

Re: [FTC]: 35's Drive problem
 

posted:
http://decibel.ni.com/content/thread/1772?tstart=0

let's see what happens.

Re: [FTC]: 35's Drive problem
 

The NXT is faster, I think the lag has as much more to do with the bluetooth. I found that it was better to incorporate FEWER interface commands, where the code looks for the joystick commands, which definately has a slowing affect.

There are more factors, but the bluetooth speed is the biggest problem I think.

I have had very few problems with the bluetooth interface in RobotC, but I haven't been using the FTC Control station, but the included software in RobotC. It will be interesting to see what the robots will do at scrimages with the competition setup. (the only scrimage I went to, people used personal laptops and all used RobotC)

Re: [FTC]: 35's Drive problem
 

I can't see why it would be the blue tooth. They use blue tooth in a number of things (my Wii comes to mind), and they don't have laggy controls, it must be something in the code.

Re: [FTC]: 35's Drive problem
 

Bluetooth is not the problem. My team used to use Labview and there was lag even when using a USB. Also, the bluetooth was not a problem at the scrimmage I attended. Redownload the last Labview update as I'm not sure if they posted a new update, they may have just edited an old one (although I'm not 100 percent positive, this is just what I remember reading is one of the links on chief delphi). Labview had a ton of lag for us and RobotC has almost none. I would suggest trying to run the sample joystick code for RobotC and seeing if you have lag.

Re: [FTC]: 35's Drive problem
 

I would agree that it shouldn't be the bluetooth, unless it is the software implementation of it. I use a bluetooth mouse with my notebook and while hardcore gamers tell me there is some lag, I definitely haven't noticed it.

Re: [FTC]: 35's Drive problem
 

Well...we're not exactly running mouse from this. Idk, let's wait for an reply from labview.

Re: [FTC]: 35's Drive problem
 

A quick update:
We put at deadband (+/-10) on the drive sticks and it has mitigated the problem. The underlying lag is still there, however. I'm sending our code to NI tomorrow. I'll keep you posted.

Re: [FTC]: 35's Drive problem
 

I should really try the deadband thing.

By the way, anyone has any idea how far bluetooth signal goes?

Re: [FTC]: 35's Drive problem
 

How far do you want it to go? I doubt you'll have problems at competition.

Re: [FTC]: 35's Drive problem
 

That's true

Re: [FTC]: 35's Drive problem
 

No one has been to a competition yet, so who knows what's going to happen. I see this as a quality control issue. If there is something slightly off with LabVIEW and the FTC hardware, I'd rather bring it to someones attention now and eliminate future problems. If this is just a coding error on our part, no harm no foul and my team and I learned something to boot.

Re: [FTC]: 35's Drive problem
 

Well, there have been plenty of scrimmages. So, I'm sure if there were range problems at the scrimmages, then they would have been brought up.

Re: [FTC]: 35's Drive problem
 

Did those scrimmages use the regulation field control system? I have a feeling that we are going to see some interesting bugs tomorrow in U-Hall.

Re: [FTC]: 35's Drive problem
 

I attended a scrimmage where they used the regulation stuff, it was run by the NJ FTC people. There were very few problems and things went far smoother then I expected.

Re: [FTC]: 35's Drive problem
 

First regional is tomorrow? Well, be sure to take lots o' pics for me?

Re: [FTC]: 35's Drive problem
 

I'll be driving, but I'll try to take a couple.

Re: [FTC]: 35's Drive problem
 

Update: While i was having my students do some commenting on the code before we sent it to NI, we noticed something interesting: we has 4 motor controller VI's where there should have been two. When we removed the extra two, the lag disappeared. We live and learn don't we?

Re: [FTC]: 35's Drive problem
 

We did some tests on the Bluetooth speed. We updated the joysticks and then just displayed the value on the screen of the NXT.

The speed DRASTICALLY increased when we switched to a faster laptop (Core-2 Duo chip, more memory, etc - the slower one wasn't slow, it was just slower). The faster laptop also had built-in bluetooth (vs. a USB port dongle), but it went from 0.5 sec+ delay to almost not noticeable... That kinda indicated that some of the problem might not be in the NXT, but in the computer connected to it.

Hopefully the field management system at the competitions will have a reasonable speed!

BTW we're using RobotC - YMMV in NXT-G and LabView.