Hello! I had a navX sensor connected to the RoboRIO with USB micro, and they did communicate, but the sensor readings are weren’t updating (stayed 0 although the robot was moving). When I changed it to I2C via MXP, the values did start updating.
Why, and how can I get it to work with USB? Thanks!
I could guess you didn’t define the USB port right for the one you plugged into (there are 3 choices and 2 work with the correct constructor port). If that isn’t a good enough hint, then I’d need a photo of your roboRIO and navX with the navX connection showing and the complete robot code that fails. IIRC, the outside edge type A USB is Serial.onboard.USB1 (and I don’t always remember correctly so try both Type A’s).
edit: almost forgot that since you didn’t indicate there are any errors, I’d require proof by looking at the console log (or riolog). Also, if you open the SmartDashboard, navX sends one field to it in certain modes to help assure that it is working.
The code isn’t failing! It just isn’t updating the yaw measurement value. No errors are thrown, and it’s printing all the normal things on startup (I can show a photo tomorrow).
When I disconnected the USB cable, it started printing “failed to connect with navx sensor” or something like that over and over again. When I reconnected the cable, that stopped. So they obviously have communication.
It is connected to the RoboRIO on the outer USB-A port, as you said.
In the constructor, I am passing SerialPort.Port.USB1, could that be a problem?
Here is a link to the GitHub repository: https://github.com/ShakedMev/SwerveFollowTragectoryRepo/tree/develop
The navX is initialized in robot/subsystems/chassis/DrivetrainSubsystem
Did you disconnect the I2C wiring before starting the USB connection? They might interfere with each other.
You can run the I2C SCL and SDA (no power) and use the I2C port with a USB data cable and it uses the power only. I’m not sure the other way around works, though; never tried it.
Did you disconnect any other USB devices? Some of them don’t play nicely together.
USB has restrictions so this might be required for USB. We use it.
ahrs = new AHRS(SerialPort.Port.kUSB1, SerialDataType.kProcessedData, (byte) 60); // kUSB1 - outside type A
Timer.delay(1.0); // make sure AHRS USB communication is done before doing
// other USB. Also give it time to settle in; a few more seconds never hurt
ahrs.enableLogging(true);
Also, the navX takes some time to start. Have you restarted or rebooted the robotRIO much after starting the navX. Seems like it’s several seconds - maybe 20 seconds? There is a method that tells you if the navX is ready to use or still starting. Try putting a sleep for 30 seconds after the constructor and see if that helps.
Thank you, I’ll try this today! Out of curiosity, what is the point of changing the update rate to 60?
To answer your questions, I disconnected the I2C before starting the USB connection. It was also the only USB device on the RoboRIO currently.
I tried this solution, and still have the same problem. I did more tests and found that the isConnected() method returns false, while isCalibrating() returns true. Which is strange because the logging to the RioLog prints “startup calibration complete”.
Solved! We calibrated the navX with the buttons and it works now. Thank you for answering!
Great that your navX is working. You are welcome. The next suggestion would have been make sure the firmware is correctly updated since some people have inadvertently loaded navX-MXP into the navX-micro, etc.
Specifying a value that is also the default value is a stylistic action since it accomplishes nothing. I like default values so things work without having to do much thinking at the beginning when I don’t know how to use something. As I learn about something, then I like specifying the value even if it’s the default and that’s a sort of documentation and memory jogger. I can then recognize 60 hz update and remind me that’s a good number for the 50 hz iterative robot. If I happen to change the robot cycle time I can see immediately without having to remember that the navX is still at 60 hz. Also, if the code author changes the default, I’m insulated from that change; that may or may not be good.
Oh, I get it. Thanks!
For @shush I’d add that my students checked for isCalibrating for no more than 7 seconds then moved on. Also, if it is determined the navX isn’t working and you move on, you should not use its values. For example, disable field oriented driving and have autonomous work as best it can without a gyro. And for the very cautious teams that use redundancy on critical circuits put on a second gyro.
I’m not sure how fast that navX.reset() works so maybe make sure it always finishes before using values. (The code isn’t perfectly robust; the students used it to solve what they thought were problems and didn’t anticipate any trouble they hadn’t seen in testing.)
I’ll add that multiple USB devices sometimes don’t work right. Our CANivore and navX wouldn’t start up together without tricky manual intervention that wasn’t going to happen if there was a brownout during a match.
navXTimer.reset(); navXTimer.start(); System.out.println("NavX is calibrating"); while (navX.isCalibrating() && (navXTimer.get() <= 7.0)) { } if (!navX.isCalibrating()) { System.out.println("NavX is done calibrating" + navXTimer.get()); System.out.println("Firmware version: " + navX.getFirmwareVersion()); navXIsCalibrated = true; navX.reset(); } else { System.out.println("NavX calibration timed out"); }
It makes sense to wait until the navX is done calibrating on startup, but wouldn’t the code in this example cause loop overruns? Same with the other example you posted earlier.
Also, I never measured how long the calibration takes, probably quite a few seconds, but I know that the yaw reset is almost instantaneous! We do it with the press of a button, and it prints to the RioLog “navX-sensor yaw reset complete” almost immediately.
They are merely benign suggestions that something might be wrong so you don’t have to be a slave to them and an occasional one can be ignored but I agree you ignore them at your peril and too many means something probably needs to be corrected.
Anyway this isn’t relevant because you aren’t in the loop. You are in RobotInit and everything waits patiently for the robot to prepare itself (sometimes an embarrassingly long time of several minutes at a match in which case the audience breaks out in song and dance).
Oh😂 yeah, we can spare a few seconds on startup to ensure the navX works right. I try to avoid loop overruns because we’ve had problems with them previously (motors timing out), but you’re right, that shouldn’t be a problem when it’s only in the beginning.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.