We have been over the code about a dozen times… but we can’t seem to figure out why our autonomous mode waits about 3 seconds before moving. Most robots are 1/4 way through the field by the time we start moving, and this is allowing the human play to score 2 -4 balls before we can get out of striking distance. I am not a programmer, but posting this question for the team!!!
It would really be something with the code, and ultimately you might have to end up posting the code,
but my best guess is that if you have a lot of sensor initializing, then if your program waits for sensors to stablize, ie an accelerometer, or gyro, or something, then it might take a sec, or seconds. But that’s my two cents.
I will get you the code shortly, it’s more of an issue to pull it off of our server…
Thanks for the quick response though…
Sunny’s right - it could be sensors. Specific sensors like the gyro, need time to initialize, whilst others do not. I can’t exactly remember how much time is recommended for the gyro to initialize, but I don’t think three seconds would be it - sounds too long.
Also, the mass amount of stuff to initialize could be it. If you are using a lot of motors, sensors, servos, or anything else - it could take a long time for the cRIO to create them all and initialize them all. I haven’t seen this in experience with teleoperated, though I’m not sure about autonomous - we haven’t exactly thought about that yet.
Another thing it could be if a student has placed a wait sub-vi in the autonomous initialize block (assuming they use LabView). If one is there, it literally pauses the entire program, while waiting for the time to pass. Its not exactly a possibility that it could happen, but it is a cause.
Hope this helps.
Just so that programmers are on the same page, can we know what programming language you’re using?
We are using labView, and we are trying to initialize a gyro and an accelorometer, in addition we have two wheel encoders.
Most of the Opens that do initialization are super fast, way under a millisecond. The exception is the gyro, and I suppose the accelerometer. Because these are trying to measure a baseline, they need to calibrate for drift when known to be stationary, and they average many values to get a good estimate. You may want to move the gyro init to Begin or outside the loop, then write it to a global to be used in auto.
Yeah, the gyro takes 5 seconds to initialize in WPILib/C++. You need to move the initialization somewhere besides your autonomous routine, as I would imagine its about the same in LabView.
You should be initializing (everything) in the Begin.vi. If you are using autonomous independent mode, then you’ll have to stash the references in a global and use the global in the autonomous independent vi.
Begin happens right when the robot is turned on. Way way before autonomous mode.
I haven’t looked at the internals of the gyro class, but automatic calibrations of things can sometimes slow down if there’s a lot of noise while it’s trying to calibrate(so it either tries to wait until there’s less noise to tries to take more samples to compensate). In your setup, there are quite a few factors that could cause this–robot movment, vibration from a compressor, electrical noise from wires or motors, etc.
The gyro init will always take several seconds to average values in order to get an accurate baseline. Both C and LV will do this. As mentioned, do this in Begin or outside the loop in Basic.
Do you have your robot starting at full speed? you could be burning out and the delay is your robot trying to gain traction
Sorry for the long delay… Not just word play!
Attached is a zip file with alll of our vi’s.
An explanation of the code from our chief programmer:
In Autonomous Independent.vi, the outermost case is for autonomous mode selection, e.g. “2” for autonomous mode 2. The innermost case is a state machine used for the selected autonomous mode. It takes about 2 seconds to enter the “Start” case that is nested in the outermost autonomous mode case. Using probes, the outermost case is entered immediately, but a probe in case “Start” does not update until approximately 2 seconds later. Once the state machine is entered, everything operates as expected, but for some unknown reason entrance to the state machine is delayed. I have not had a chance to use Highlight Execution to find out where the delay is originating since I do not have access to a cRIO.
The encoder code and gyro code are used.
The code for the ultrasonic and IR sensors at the bottom is not used and will be deleted.
As the others have stated, the problem is that you have your gyro open in autonomous independent. This delays for 2 seconds.
Move the gyro open to your basic robot main, outside the while loop, and publish the dev ref with a global variable (I see you do this already with your encoders).
It’s probably too late for this year, but next year you guys should look at the advanced framework. It should help keep your code more organized.
Actually, my team has been having problems with delay in the advanced framework too. All sensors were initialized during the begin.vi, but there was still a 2-3 second hang-up during the init state of every mode.
During every state change, the driver station would display “Watchdog” for 1-2 seconds, enter the state for about half a second, display the watchdog timeout message again for another 1-2 seconds, then return to normal operations.
We even stumped the NI representative at the regional event after we pinpointed the cause of the hangup to be a section of a vi with approximately nothing in it.
I rewrote almost the entire program at the regional using the version 3 advanced framework and the delay between states disappeared, but there was still about a 1 second delay entering autonomous mode during matches. We were not using any sensors or the camera at the time, and the delay only seems to occur on the competition field (the first time it is run maybe?) because the robot appeared to start autonomous immediately when we tested it in the pits.
Any ideas as to where this delay is coming from?
Having been one of those NI Reps at times, it can be pretty hard to think straight after six straight hours of troubleshooting everything from bad cables to bad HW to missing updates. Besides, amidst all the chaos, a robot with a delay just doesn’t get the same attention to a robot with no DS or no code what-so-ever.
Anyway, if you post the code, I’m pretty sure that the delay can be spotted when the chaos factor is a bit lower.
Here’s the rewritten code. The code that delays between state changes is in so many different places, it’s not worth trying to find all of it and bring it together into a .zip.
This code delays for about a second during autonomous at the start of a match, but doesn’t seem to have any delays any other time.
I didn’t see anything odd, so I decided to wait till we had a cRIO. We had a chance to load and run the code late yesterday and the auto started right away everytime. Of course since we didn’t have your robot, we don’t know of that would necessarily move your robot.
Here is a test to do. We placed a chart on the drive VI to update the speed. It is inside your drive % VI. This will let you see what your velocity looks like over time during auto. If you want to see both inputs, bundle them to a cluster. Leave this panel open, run your Robot Main and flip to auto or however you normally reproduce the delay. We see the speed to the motor start ramping immediately.
I don’t think we have our robot yet either, but once it returns, we’ll take a look. The funny thing is, we can’t normally reproduce the delay. In the pits, we got the same results as you–the motor speed starts ramping immediately–but there is a noticable delay at the start of a match.
If anyone has videos of the Wisconsin regional, you can see that our robot takes off about a second later than all the others during the second day. (During the first, it was more like 2-3 seconds)
Thanks for looking over it though.