My team seems to be having a recurring issue. Every year we have to fight lag in our FTC robots. It seems to me that the robot isn’t checking for the position of the controls often enough. The robot misses quick corrections while driving and may take up to 2 seconds to respond to commands.
My students are thinking that we are overloading the NXT with commands and the packets are being dropped. I am not sold on this explanation considering we are only using 1 touch sensor, 2 encoders, 4 DC motors (skid drive) 1 Lego motor and 6 servos. I have a hard time believing that our hardware is so… anemic that this would be too much for it.
So I have two questions: 1. Is anyone else having this issue? 2. Would someone with experience be willing to look at our code to see what is going on? (I will post it as soon as I can figure out how…)
Here is the code. I’m really looking for some Labview/NI support. However, if we can’t find the cause of this lag we will be dropping Labview and going to robotC where we have heard there isn’t this lag issue.
To add to my mentor’s post, we also experimented with a vi I found last year on the FTC forums known as Read Packet Flush.vi that replaced the read packet vi, in which it erased the inbox before accepting the next packet (least I think that is how it worked, the help file was a little lacking in the technical aspect). Last year this completely got rid of our lag for competition. This year I tried it with a vi of using only the drivetrain and it worked, however when I add the other code for the rest of the robot the lag seems to return.
My first idea is that the NXT is simply running too much code in each iterative and that it wasn’t reading fast enough because of this, but I’ve seen teams with more complex setups than this, so I find it hard to believe. I understand that LABview is not as commonly used in FTC (least not from who we asked at competition last year), but help would be appreciated. The only idea I have left is run the NXT in two states, one for the first controller functions, one for the second, but i can’t imagine this being easy or helping much.
You don’t need to use “Read Packet Flush.vi” this year because the Samantha Module uses USB, which doesn’t suffer the 5 packet buffer problems that Bluetooth does.
Next…
To drive your wheels you are running tank mode, and you have TWO Move MotorS (group) VIs, that are each controlling one wheel. That’s OK, but you are using the “Multiple Motor” version of each one. So you are passing each one an array of motors, that only contains ONE motor. This will double your processing. I suggest changing these to single Move Motor VI’s by clicking on the pull-down list below them and chosing “Move DC Motor” (Without the Group or Multi option). This will require that you also delete the Arrays of DC motors an inputs, and replace them with Single DC Motor inputs.
Finally
I suspect that your lags are really due to the MANY 0.7 second delays that you have in your servo processing code. Whenever you hit an arm function you are moving your servos and putting in a big delay. This delay will prevent the code from processing any new joystick inputs. Yeah… it will be sluggish.
The best way to do this (As shown in the templates) is to read the controls in one loop, and then share the button actions via local variables. Put your servo actions in another loop that can run independantly.
I also noticed that you have set your Message timeout to 10 Ms. (Going into FTC Robot Status). I can’t imagine this is helping.
This tiemout is for detecting loss of link. 1000 ms Is more than adequate.
oddly, I totally forgot that the original template shows manipulators as being in a second loop, I will definiatly try that. As for the increase in the timeout, we found that the NXT kept switching between enabled and disabled without us doing anything to the FCS (we were using the Samantha module when this happened) and when we heightened the number, it stopped doing that. But again, that could be because we were processing so much. I will definiatly make those changes and test the robot with that ASAP. I am planning however to make a backup piece of code using RobotC, if that is ok with my mentor.
While working on the code i have a question that I was wondering if anyone knew. Is the NXT capable of handling flat sequence structures with multiple frames this year? I know in the past multiple frames were not allowed, but this year I’m not getting a broken vi icon on my run button, but I don’t have the robot with me right this second so I don’t know if it will maybe say something when I try to download the code.
I have just finished a revised version of how teleop code. I think I’ve ironed out most of the problems, but I would like to submit it here for review while I’m waiting on a chance to work on the robot.
The zip file contains the revised version known as 0035 teleopstate.vi plus all the subvis. All of the comments and context help data is up to date, and the front panel contains information the vis.
my understanding is that 2009 is the only version of labview you are allowed to use in FTC. I know when FTC first started with 8.5, but after that 2009 was what came in the kits. I have both versions on my computer, and if I have time i’ll make a similar one in 8.5 if I find we are still having problems, otherwise I will keep the format in 2009 until I have a significant reason to change it.
I went through your code and pointed out a few changes that will further boost speed. Mainly, I edited one your subvi’s to avoid the use of waits. Function is unchanged and details are on the block diagram. Caveat: This code is untested!
BTW, nice use of LabVIEW’s documentation features. In my experience, very few teams use them.
I must say, I was not expecting such a strong response from the CD community. I am humbled by such Gracious Professionalism :-). We shall endeavor to pay it forward.
The robot locks up with your edits, I have a few ideas why: you placed a while loop in my subvi, since this vi was in another while loop, it could be causing the lockup. You also had all the state numbers minus 1. so you had state 1 always going to 1, 2 always going to 2, so they never moved forward. Otherwise, I completely understand all of your comments. The switcher was not something I had thought about, but is certainly something I’ll remember. As for the shift registers, in FRC I always use them, but they are a bit of a pain in FTC because the only structure that supports them is while loops, and those cause the robot to lock up if you place them inside of each other. In FRC I just use a for loop where n = 1. it’s true i could have the state and timer values go in and out of the subvis as controls and indicators, and use the entire teleop while loop for the registers, but by that point it’s more ugly than it’s worth, considering it gives a milisecond reduction in lag. Plus although we did have those counters in there, they didn’t seem to freeze anything up when we tested running the arm and the drivetrain at the same time. And finally, I had my suspicions about the usefulness of the hz limiter, and you finally confirmed it.
While I’m reverting back to my version of most of the code, I still must thank you, I learned a lot from your edits that can be used in FRC.
As you state, there is a problem with my case numbering and this is causing the hang. Oops. There may be other errors as well.
The while loop, however, is not an issue. At first glance it looks like it will cause a stall but that is not the case. A false constant is wired into the “continue if true” conditional terminal. This has the same effect as using a for loop with n=1. For further information:
You should put a small time delay in the lower control loop (maybe 25mS). This will prevent the arm control loop from hogging all the spare CPU cycles when it’s not doing anything.
Your “Enable” logic is not quite right. You don’t want to be exiting the arm control loop based on the enable flag. Both loops should run forever (FALSE wired to terminator), but the Enable indicator should be set by the Robot Driving Case Structure (True if driving, False if disabled). Then if you want to use this indicator to also disable your arm control (good programming practice), then put a case structure in your arm loop to do-nothing if the “Enabled” local variable is false.
Your Button 5 code turns on the NXT motor if the button is pressed, but doesn’t turn it off when the button is released…
