We’re at DCMP trying to understand best practice around using the NavX to execute a continuous autonomous routine:
Environment:
LabVIEW + NavX
Problem:
“Zero Yaw” does not seem to be working as expected. We have tested I2C and SPI at different rates. What’s expected at step one is that robot zeroes its yaw, and then adjust as it moves toward the peg if the rotation angle falls outside the deadband of 3 degrees. This works the first time the robot starts up (pressing the run button on Robot Main.VI and deploying code, and then pressing enable on Autonomous). However, after the autonomous routine is tested once, if we disable/enable again the angle the robot sits at currently persists. We need to re-deply code for the Yaw to actually reset to zero.
We run the “Zero Yaw” function in two areas: 1) in Begin.VI and 2) as the first frame at the beginning of the autonomous sequence. There did not seem to be any issue with the navX during TeleOp.
I understand from another chief Delphi post (https://www.chiefdelphi.com/forums/showthread.php?t=143718) that Zero Yaw cannot occur until a calibration process is complete. We’ve noticed that even when “Zero Yaw” is run after the calibration is complete, the Yaw is not actually zero after that.
Appreciate any suggestions and insight you may have. I will post replies from the navX team here as well.
A quick fix to that would be measuring the angle relative to the angle in which the robot starts with.
You can get the angle on the start of auton and just use the current angle minus the starting angle as input for your code.
If you zero the Yaw in auton you need to give the sensor 500ms to 1 sec to do the zero. You also need to make sure that you have connected the true constant to the zero yaw vi. If you never give the true signal to the vi it will never send the command to the device.
When I ran my code I set up a zero where I got the current values and adjusted the out using the initial reading. It is faster than waiting for the system to zero if you can not wait the 500-1000 ms.
We had similar experiences in labview and could never get the NAVX unit to give us a reliable first reading for auton. We even waited 3 seconds before taking the first reading. We only read yaw.
We utilized the idea of taking an initial reading, then using that as our “zero” and normalize all subsequent readings from that data point.
The issue we had was ONLY with the very first reading after powering up the robot. If we just ran Auton, again (think test bench, not field)… The code worked as we expected.
We tried multiple things, but could never get a reliable number for that first reading. It would always be zero, but without moving the testbench/RRio, the next reading (3 seconds later) would always result in a number we trusted. That number would range from 1-12.
Any suggestions would be greatly appreciated. We would be happy to post our working code once this is working, but for now…The first reading is not reliable enough for us to utilize this in our game
Deadreckoning is working 80% of the time…
This is going to be a summer project for us, as Iwe have a few motivated students to figure this out and make this part of our robot design. The VI libraries make it real easy for even the rookie 9ths graders to figure out. (Nice Job kauailabs)…Help us get this working for that “initial read” and we will happily post our working auton code that 9ths graders can understand without having to understand control loops
Attempts to zero the yaw during Startup Calibration are ignored, so it’s important to determine if Startup Calibration is complete.
In the Get palette, there is a "Sensor Status vi (“GetStatus.vi”), and it can return the CalibrationStatus. It’s possible the sensor is still calibrating when first used, and this will help verify if that is the case.
In general, it’s very important that the robot be still when it is calibrating, from the time it is powered on until the time that calibration completes (as indicated by the CalibrationStatus). This period of time is known as “Startup Calibration”.
If the robot (and thus the sensors) is being moved around during Startup Calibration, this can cause it to take a longer time to complete.
If you perform Factory Calibration, this can also help improve somewhat the time it takes to perform startup calibration. More details on this are on the Gyro/Accelerometer Calibration Page.
