Our NavX yaw is delayed from reality. It seems to get worse as power on time increases. I graphed the yaw and the turn command and it is clearly lagging. Although it does seem to start moving in the right direction immediately.
We have tried switching connection methods from serial to SPI. We have made sure that the roborio is not maxed out on CPU.
We are programming in labview. We have some confusion about whether we can initialize the NavX in periodic tasks or if it should only be done in robot main.
The symptom is that once P is high enough to get the job done the robot wags while driving, and overshoots it’s turns. We might be able to tune for this but a faster update would be much better.
Also we can’t seem to reset the yaw reliably. I have not got to the bottom of that yet. Even in the troubleshooting vi that shows all the datapoints none of the reset buttons work.
Updated the firmware a few weeks ago to 3.0.xx I could not find the last digits on the firmware.
We may just switch back to the analog gyro because we are not bumping over obstacles this year or needing more than about 5 seconds of yaw guidance for our auto.
The LabVIEW navX-AE library requires that the “navX Main.vi” which performs the initialization run only once. So whether you place it in your robot main VI, or within periodic tasks - it’s important that “navX Main.vi” not be placed in a loop in your code.
We have achieved sample frequencies at 200Hz. They have been tested and are being used by many different teams including mine. I would be happy to look at your code to see if there are suggestions on how you can run faster. You can also set the sample frequency to something other than the default 50Hz. I am not sure how fast you are moving but we have drive straight code, and after a little tuning of the PID, runs smooth and straight. If you are seeing a lag I would guess it is the way things are being set up or read.
The navX software was designed to be a standalone process. There should be no need to initialize the code. All of that is done once you drop it onto your block diagram. Serial is the slowest communication that you can have with the navX and is limited to 50Hz no matter what value you give it as a constant for setup. SPI and I2C are the fastest communication protocols.
The zero function changed a little from the release at the beginning of the year. You only need to send a button push to the vi to get it to zero now. You no longer have to put it into a case structure and look for the button push. There is a Boolean input on the zero vi that needs to have an input. If you wire up the joystick button directly to the navX zero it should work without problem.
I am willing to look over your code and see if I can help.
I thought that omnimount was something done in code. I did not know that it was a calibration routine that is so fast and easy.
It is possible that we did omnimount at some point in the past with this board either accidentally or for some other robot. We have used the board for 2 previous years. It also shows 60 degrees yaw when I turn the robot 90 so a stale calibration could be the issue.
The NAVX is mounted topside up and front side pointed to the left. I might be able to rotate it 90 if my cords all reach. But I thought that a gyro didn’t care about which way was the front of the robot as long as yaw motion was perpendicular to gravity.
The Roborio/board is also mounted in the left rear of the robot. I thought that omnimount compensated for the acceleration difference when we did that if we wanted to use the motion stuff.
I also don’t understand why reset would just do nothing if omnimount was not done.