NavX causing robot code to reboot

[one4robots]

Hopefully CD can help!

The NavX we used successfully last year is causing our robot code to continually restart. If the NavX code is commented out, the code runs perfectly. We have just updated the NavX firmware. Any ideas what is causing this?

Thanks!

[slibert]

Originally Posted by one4robots

Hopefully CD can help!

The NavX we used successfully last year is causing our robot code to continually restart. If the NavX code is commented out, the code runs perfectly. We have just updated the NavX firmware. Any ideas what is causing this?

Thanks!

That's the first I've heard of this symptom; I would suggest that providing more details about your configuration (language, which communication interface you're using), what else is going on in the robot application when the restarts occur, and any other things that might seem related could be helpful.

[Poseidon5817]

We've had issues with a NullPointerException getting thrown for the NavX not being detected when the robot code loads. Restarting the code or roborio usually fixes it.

[slibert]

Originally Posted by Poseidon5817

We've had issues with a NullPointerException getting thrown for the NavX not being detected when the robot code loads. Restarting the code or roborio usually fixes it.

Please post the stack trace for the exception next time you encounter it.

[Ginger Power]

We have had somewhat related problems with our NavX as well. We've been battling a communication issue for a really long time and we just figured it out.

We had the NavX in our C++ code and we didn't have it on our practice bot. Because of this, we could only connect to our Roborio 1 time. After the power was shut off and turned back on we could no longer connect. The only way we could connect was by reimaging the Roborio. After reimaging we could connect 1 more time.

The people on our team who actually know the details behind the problem are contacting NI and FIRST and making them aware of the problem. I believe they will also be posting their findings to CD.

[Jonathan L.]

In 2015 we used the nav6 (predecessor of the navX). It used a serial connection to the roboRIO. We had issues with the roboRIO not working (not connecting or something like that). It seemed like we had to re-install the roboRIO firmware and re-image. Removing the nav6 from the robot fixed the issue. Anyway, we found that unchecking the "Console Out" checkbox in the roboRIO imaging tool allowed us to use the nav6 normally.

[torzewsk]

Originally Posted by slibert

That's the first I've heard of this symptom; I would suggest that providing more details about your configuration (language, which communication interface you're using), what else is going on in the robot application when the restarts occur, and any other things that might seem related could be helpful.

We are using C++. The navX is plugged directly into the RoboRio and we are calling ahrs= new AHRS(SerialPort::kMXP); commenting this line out allows the code to continue, but of course our AHRS pointer is null. The line is called from Robot::RobotInit. I've tried commenting out almost the entire rest of the program to no effect. Thanks for thinking about this!

[tr6scott]

https://www.chiefdelphi.com/forums/s...d.php?t=154205

We are a labview team, we have also had strange issues with NAVX this year...

[torzewsk]

There is more going on. Subsystems were just constructed. I am suspicious that one could be using the navx before it is ready. Are default commands kicked off in parallel threads? I have a feeling this one subsystem is using the pointer too soon. I'll try commenting it out as soon as I get back to our robot.

[Oblarg]

Originally Posted by torzewsk

Are default commands kicked off in parallel threads?

Unless C++ is implemented very differently from the Java version, AFAIK all commands (except for PIDCommand, which has an internal PIDController) are run synchronously from the main loop.

[slibert]

Originally Posted by torzewsk

We are using C++. The navX is plugged directly into the RoboRio and we are calling ahrs= new AHRS(SerialPort::kMXP); commenting this line out allows the code to continue, but of course our AHRS pointer is null. The line is called from Robot::RobotInit. I've tried commenting out almost the entire rest of the program to no effect. Thanks for thinking about this!

Thanks, the details help. The code you have shown is attempting to communicate via TTL UART serial port w/the sensor. Is that your intention?

Most teams that use navX-MXP use MXP-bus SPI (SPI:ort::kMXP).

navX-Micro is typically used w/USB. (SerialPort:ort::kUSB).

I'd recommend you review the port specification parameter to the AHRS class constructor. It's possible you're trying to specify a communication path that is invalid for your configuration.

[slibert]

Originally Posted by tr6scott

https://www.chiefdelphi.com/forums/s...d.php?t=154205

We are a labview team, we have also had strange issues with NAVX this year...

Hmmm, missed that thread. So I'm curious also when your robot application is initializing the MXP IO (if any), and if that might be contributing to some sort of collision. The best hypothesis I can come up with is a race condition when allocating the MXP IO resources that in turn causes the allocation of SPI and other comm resources to fail (except the first time after loading the app after reimaging). Does this seem plausible to you?

[TylerHarmon]

If your code is crashing when you try to initialize the NavX, it probably is not properly communicating with the roboRIO. If you try to read from it before it is booted, you will also get a Null Pointer Exception. Just check if the value you want from the NavX != null before you try to do anything with it.

Most likely from what I have read here, you are not properly communicating with the NavX on an electrical side, or it is wired properly but you are trying to communicate with the wrong protocol.

[torzewsk]

We found it. PEBKAC
We had an obsolete version of AHRS.h in our include path, and it was not the right size. The adjacent memory allocation and the navx were wiping each other out. Thank you for your help, it got us thinking.

Tim T.