[FTC]: 35's Drive problem

[wilsonmw04]

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?

[Lowfategg]

Originally Posted by wilsonmw04

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?

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

[KayyPii]

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

[wilsonmw04]

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?

[gdo]

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

just a question, are you using a "deadband" in your code like:

if (-10 < joystick.joy1_y1 < 10)
{
motor[motorD] = 0;
motor[motorE] = 0;
}

((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).

[KayyPii]

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.

[wilsonmw04]

Originally Posted by gdo

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

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.

[ttldomination]

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?

[gregsanCHEVY121]

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.

[Monty Python]

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

[KayyPii]

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

[wilsonmw04]

Originally Posted by Monty Python

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

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?

[ttldomination]

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

[wilsonmw04]

Originally Posted by ttldomination

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

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

let's see what happens.

[gdo]

Originally Posted by wilsonmw04

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.

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)