ANNOUNCING: navX MXP Robotics Navigation Sensor

[IndySam]

We had to remove ours in the finals because our robot would sometimes just become impossible to drive when connected to the FMS. It would jump turn and move without driver input things it never did in practice.

I didn't see any brownout problems in the logs and until we unbag it for practice next week we do not have access to them.

At this point I doubt if we put it back on. BTW we are programming in Java.

[Kevin Sevcik]

So I'm vaguely thinking about getting one of these as an upgrade for our bot, but I'm obviously a little concerned about Thad and Sam's bugs. Might I suggest a separate thread with a poll or roll call of NavX MXP users, their programming environment, and their success/failure with the product? If problems are restricted to <5% of users, then I'd probably grab one and try my luck. If >25% of users are having problems, then I'll probably wait until things are more stable.

[slibert]

Originally Posted by IndySam

We had to remove ours in the finals because our robot would sometimes just become impossible to drive when connected to the FMS. It would jump turn and move without driver input things it never did in practice.

I didn't see any brownout problems in the logs and until we unbag it for practice next week we do not have access to them.

At this point I doubt if we put it back on. BTW we are programming in Java.

Typically, in a field-oriented drive (or auto-rotate-to-zero) application, the robot's drive train Z-axis rotation is impacted by gyro data; in other words, a gyro anomaly should impact only rotational motion. So while unexpected turning (e.g., spinning in circles) could point to a gyro issue, a robot that unexpectedly "jumps" and "moves" may be a sign of other control-path issues (Joystick->DriverStation->Network->RoboRio).

Please send along any information you can, it's not clear what's different about robots that are FMS-connected, other than the communication path between the Driver Station and the Robot software. The on-field log data for lost packets between DS and RoboRio, CPU time and communication latency might provide valuable info that might help other teams.

[Kevin Sevcik]

Originally Posted by slibert

Typically, in a field-oriented drive (or auto-rotate-to-zero) application, the robot's drive train Z-axis rotation is impacted by gyro data; in other words, a gyro anomaly should impact only rotational motion. So while unexpected turning (e.g., spinning in circles) could point to a gyro issue, a robot that unexpectedly "jumps" and "moves" may be a sign of other control-path issues (Joystick->DriverStation->Network->RoboRio).

Please send along any information you can, it's not clear what's different about robots that are FMS-connected, other than the communication path between the Driver Station and the Robot software. The on-field log data for lost packets between DS and RoboRio, CPU time and communication latency might provide valuable info that might help other teams.

This thread is tracking an issue with Timers in Java acting differently immediately after a cold boot vs. after a warm boot. It's not directly FMS related, but it's something. The issue seems to be related to the Java Timer class depending on the RoboRIO system datetime, and the datetime initializing to 1970-something on cold start, and getting sync'd to the DS datetime on connection. The problem might just seem related to FMS connection because teams are using a different workflow during match vs. in the pit or practicing.

Also note the post in that thread about SmartDashboard logging buffering during long delays on the field and bogging things down after connection to the robot. There's definitely differences in the order and timing of control system events on the field vs. in the pits.

[Alan Anderson]

Originally Posted by Kevin Sevcik

There's definitely differences in the order and timing of control system events on the field vs. in the pits.

The one obvious and mostly reliable difference is the robot being turned on and probably running user code for a while before the Driver Station is on the network. That's what brings out the timer bug, and the buffered data flood, and perhaps other things that are currently mysterious (e.g. Network Tables glitches). The workaround of restarting the robot program from the Driver Station seems to get past such problems.

[Kevin Sevcik]

Originally Posted by Alan Anderson

The one obvious and mostly reliable difference is the robot being turned on and probably running user code for a while before the Driver Station is on the network. That's what brings out the timer bug, and the buffered data flood, and perhaps other things that are currently mysterious (e.g. Network Tables glitches). The workaround of restarting the robot program from the Driver Station seems to get past such problems.

Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

[Jared]

Originally Posted by Kevin Sevcik

Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

I hit it when our robot connects to the field and we're connected to the driver station. In case I don't have time, I also tether while in line and restart robot code.

[Thad House]

We did notice that rebooting the robot code only fixed the issue a few times. Most times it actually did not fix the issues, and the gyro still wouldn't return anything. Even resetting the gyro, then resetting the robot code did not help.

[Alan Anderson]

Originally Posted by Kevin Sevcik

Off topic at this point, but when's the generally accepted best time to hit that reboot robot button prior to a match?

Restart the code as soon as possible. In general, that will mean within a couple of seconds of the Driver Station establishing communication with the Robot.

But don't reboot the robot. That takes longer than you want, and could delay the match start. Worse, though, is that it also fails to ensure that the real-time glitch won't happen again.

[slibert]

Originally Posted by Thad House

We did notice that rebooting the robot code only fixed the issue a few times. Most times it actually did not fix the issues, and the gyro still wouldn't return anything. Even resetting the gyro, then resetting the robot code did not help.

We are now able to repeatedly reproduce a condition in the lab when there's a RoboRio Stage 2 brownout for ~30ms (shorter than that, or longer than that does not cause the problem). In this condition, the Invensense chip on the navx MXP gets reset, but the navX MXP microcontroller doesn't - and at that point, the sensor no longer returns gyro values. This condition affects I2C, SPI and TTL UART. This condition doesn't occur for shorter brownout periods (since the navX MXP onboard capacitor provides enough capacity to ride it over). And it doesn't occur for longer brownout periods (since the navX MXP microcontroller gets reset). Your info about 20ms brownouts provided the clue needed to find this.

When this case occurs, the S1 and S2 LEDs on the navX MXP will not be lit, even though the red 3.3V LED will be lit. This is the tell-tale sign.

Once this happens, the navX MXP microcontroller needs to be reset - by pressing the navX MXP reset button, or rebooting the RoboRio.

This should be fixable via a navX MXP firmware update, we should have something in a week or so (the team is traveling to Central Valley Regional this weekend).

In our testing, this case does NOT occur when a secondary 5VDC power source is provided to the navX MXP via the USB connector, since in this case all circuitry onboard the navX MXP stays completely powered through the brownout event.

Based upon this, we reiterate the recommendation to provide a backup power source (via USB connection to the VRM) if Stage 2 brownouts are expected, and will also update this thread once a firmware update is available.

[Please note this does NOT appear related to the errors reported by a few teams during Week 1 events when connected to the FMS. Until we have more information the recommendation is, as previously stated by Alan Anderson, to restart the robot code immediately after first connecting to the robot on the field.]

[slibert]

Joe Hershberger of National Instruments has indicated that the USB ports on the Roborio are powered by a separate regulator with boost capability. The Roborio USB port remains powered all the way down to ~4 volts of VIN from the robot battery.

This is welcome news, as it means that to provide uninterrupted power to the NavX MXP even under brownout conditions, a standard unmodified USB cable connecting the NavX MXP to the Roborio is sufficient. In other words, it is not required to connect the NavX MXP USB port to the VRM in order to provide this backup power source.

[pluto7443]

We just got this board, and we are using it via USB. To get it to show up in the web interface, we have to unplug and replug in our usb camera. It seems that the only way to update the usb ports is a different device; this board will not cause an update to what usb devices are connected.

Also, once the roboRio refreshes and recognizes the navX the IsConnected() value we are printing to the dashboard continues to display false.

Any ideas would be helpful
thanks!

[eddie12390]

We threw ours on as soon as we got the robot out of the bag and it worked perfectly for all of our matches. We were using Java and the NavX was powered through USB.

[pluto7443]

Originally Posted by pluto7443

We just got this board, and we are using it via USB. To get it to show up in the web interface, we have to unplug and replug in our usb camera. It seems that the only way to update the usb ports is a different device; this board will not cause an update to what usb devices are connected.

Also, once the roboRio refreshes and recognizes the navX the IsConnected() value we are printing to the dashboard continues to display false.

Any ideas would be helpful
thanks!

Just to clarify, we are using C++ and still no luck. Any teams running this board via usb/C++ successfully? If so, any insight for us?

[rich2202]

Originally Posted by slibert

Joe Hershberger of National Instruments has indicated that the USB ports on the Roborio are powered by a separate regulator with boost capability. The Roborio USB port remains powered all the way down to ~4 volts of VIN from the robot battery.

This is welcome news, as it means that to provide uninterrupted power to the NavX MXP even under brownout conditions

Are you doing testing to confirm?