Gyro Issue, Voltage Spike

Technical Control System
1

After running practice matches at our current event we’re seeing an issue that we can’t seem to explain for fix, even after consulting with a number of knowledgeable field staff, including going up the chain to HQ. What we are experiencing is our gyro not returning proper values about 3 seconds into our autonomous routine, which seems to correspond to a voltage spike of up to nearly 16 V, according to our driver station logs. This spike corresponds with a period of aggressive negative acceleration as we approach the scale. We’ve reviewed the electrical configuration of the robot with a highly experienced CSA and he found no issues there.

Here is a match video that describes our symptoms:https://www.thebluealliance.com/match/2018inpla_qm59

For reference the drive is a 6 wheel on black higrip wheels powered by 8 redline motors geared for approximately 21ft/s limited to 18ft/s. We’re currently using 2 Talon SRX’s and 6 Victor SPX’s to control the drive motors. We’re using a NavX installed on the MXP port on the roboRIO. Our autonomous routine uses motion profiling on the roboRIO to drive the paths toward the scale and other locations on the field. As of right now it seems the only viable solution available to us is to reduce how aggressively the robot runs the auto path, which may be acceptable for this event, but will ultimately limit what we’re capable of achieving in autonomous in the long run.

What we’re looking for is feedback from teams that may have experienced similar problems relating to the control system and what they’ve done to correct the problem.

1 Like
2

As you’re seeing the voltage spike on the driver station logs, I’m presuming that this is the supply voltage, caused by the motors regenerating kinetic energy into electricity. Perhaps you could do some/all of the deceleration by placing your motor controllers in brake mode, and giving them a zero command. This would cause a good bit of deceleration, but would not dump the energy onto the mains bus. Of course, it would heat your motors up… You would probably only have to do this until the speed drops to ~2/3 or 1/2 of your cruise speed.

Edit: another possibility - A gyro is a custom circuit, so there are no rules preventing you from putting a voltage regulator ahead of it.

3

A loss of navX-MXP data for about 3 seconds is very likely due to the board being reset. Thanks for including the period of data loss, that really helps narrow things down.

The telltale sign of reset in the software is the IsConnected() method of the AHRS class will return false. At the board level, a reset looks like this: the two green S1/S2 LEDs on the board will go out as it shuts down, then all 4 LEDs (Red 3.3V, Orange CAL and 2 S1/S2 LEDs) flash on for half-a-second, then a few seconds later the Green S1/S2 LEDs should turn solid-on (indicating that the board is fully operational).

As to the cause, there are few possibilities to review:

(a) It’s not likely, but has been seen before, that the reset button is being pressed somehow during motion. This is low probability.

(b) Ensure the navX-MXP board is securely mounted to the RoboRIO via the two screws (if it is moving enough to lose the 5V input to it from the RoboRIO momentarily, it’ll reboot).

© The RoboRIO is for some reason momentarily not providing power to the MXP Port 5V “User” Rail. The visible sign of this (which can happen quickly) is that the RoboRIO Power LED will go red during the event. At that time, the navX-MXP and anything else powered by the MXP port will lose power.

Note that © could be caused by loose wires in the electrical system, which correlates with acceleration change. It could also be caused by a RoboRIO Stage 2 brownout (although this case occurs when the battery voltage drops).

I’m thinking © is the most likely issue. Your mention of 16V being reported at that time implies some sort of power-related event (I realize the wiring was inspected, but I didn’t hear an explanation for this and it seems odd, given the batteries can charge up to a maximum of somewhere about 13.5V). You might find more evidence of a RoboRIO power fault (enough to keep running, but also enough to decide to drop power to the MXP Port power rail) in the Driver Station Logs.

As a rather important note, there’s a Best Practice that could help w/(b) and ©: connect an auxiliary USB cable between the RoboRIO and the navX-MXP USB port. This cable is not used for data transfer at all - but rather to provide backup power. More description can be found in section 2 of the navX-MXP Best Practices page.

4

It looks like the roboRIO and VRM are speced for 16 volts max. How close to 16 are you getting?

5

Maybe the reading saturates at 16V?

6

Hello, I was one of the CSAs working with 1747 on the issue.

They were getting close to 16v. Their log was showing roughly 15.5v at max.

7

I’m going to throw out a hypothesis that could very well be wrong, but perhaps would stimulate some discussion.

A key thought behind this is: if you agree the battery chemistry won’t realistically allow voltages above about 13.5 V, this implies that the onboard sensor that measures the voltage is incorrect by at least 2V.

If we further assume that this voltage is being monitored in order to react and respond accordingly by the RoboRIO, here’s a hypothetical scenario that might lead somewhere:

  • Battery current delivered to RoboRIO drops suddenly due to rapid deceleration, causing measured voltage to rise rapidly (Ohm’s Law)
  • Voltage sensor (which is inaccurate by 2-3 volts?) measures a very high voltage spike
  • RoboRIO responds to excessive voltage by shutting down the power to the MXP Port

I making a number of assumptions here, but offer this at least a thought experiment.

  • scott

P.S. One thing I wonder - with a fresh battery, and with robot idling, what voltage is displayed at the Driver Station?

P.P.S. As to GeeTwo’s Kinetic Energy explanation, that actually seems to make more sense than a flaky voltage sensor. The part about that not intuitive to me is that the kinetic energy would discharge back through the motor controller and back into the battery system - but if that is indeed occurring then we’d just need to understand if it’s possible the RoboRIO is trying to protect itself (by cutting power to external devices during that period).

8

Powering the navx over USB from the roborio as well as the mxp port appears to have solved the issue. Will report back if the issue resurfaces. Thanks for all the help

9

Good news. Keep in mind that other devices powered off of the RoboRIO might be getting reset, as well. From a system perspective it’d be good to ensure the RoboRIO doesn’t experience a power fault, if possible.

10

Did this remain reliable? We’re running into the same issue.

11

It resolved the issue on the 2018 robot for the extent of the season and through off-season. This year’s robot doesn’t seem to have the same problem because of changes to the drive configuration.