17v voltage spike when rotating mecanum

We’re having a very specific bizarre issue:

  • When rotating or strafing in auto or teleop with our mecanum drive, we will quickly experience a huge voltage spike and then lose communication and robot code. This means it’s not a code error.
  • This happens only when our robot touches the ground, not when it’s on blocks
  • This does not happen when we shake our robot during autonomous or teleop
  • This does not happen when driving straight in teleop

We checked the viewer from the browser and there are no sticky errors under the pdp.

Here is the attached log from the driver station.


The huge orange block is the disconnect.
If you zoom in, the yellow line (voltage), spikes just before the disconnect:


Has anyone seen this error before?

That seems very strange. The only thing I can think of is that maybe something is shorting. I would try removing power from all speed controllers except for one and seeing if you can isolate the problem.

You might also do a thorough visual check of all points on the robot that could short as it moves.

That seems like a valid suggestion. The fact that we can go straight perfectly well, however, seems to dismiss this at least a little. Also if it shorts, why would the voltage be going up? We are going to test this tethered via Ethernet to examine whether it’s a communication issue.

I wouldn’t completely trust that voltage reading; whatever is happening could be causing the voltage sensor to malfunction as the system fails.

Could one of your wheels be “fighting” the other three at some point in time? You state that this only happens when all your wheels are on the ground (and they are coupled together mechanically). You may have to do a brute force, line-by-line review of your code to find this. You can also try disconnecting the motors from the motor controllers, one by one, to see if you can find one motor where disconnecting it makes the system not shut down. You can then focus on the code relating to that motor.

When you put mechanical energy into the shaft of the motor, it acts like a generator (regeneration), creating a voltage on the motor’s input terminals. Usually, you see people talking about this when the robot is powered off and they are pushing the robot around to transport it

Based on my knowledge of 3-phase AC motors an motor controllers, I suspect that since your robot is energized and you are already applying a voltage to the motor terminals, when regeneration happens, the voltage generated by the mechanical energy being put into the motor shaft (by the other 3 motors) “stacks” on top of the voltage being applied to the motor terminals causing a high voltage condition (> 12V) on the input of the motor. There is usually a anti-parallel diode across the MOSFETs in the motor controller. In an output over-voltage condition, these diodes forward-bias and pull your input 12V up. Your control system senses the over-voltage condition and shuts down. I can confirm this with the people in our Motor R&D Group at work on Tuesday.

This could also be true.

If I remember correcty, when the DS loses network communication with the RIO (for any reason) the battery signal goes high. That’s most likely why you are seeing high pulses, not because the battery is 17V.

Remember the RIO measures the battery and has to send it to the DS. I think you have the cause and the result backwards.

Just a shot in the dark – are your mecanum wheels mounted properly? If you have them in the wrong orientation, they will be fighting each other when you try to rotate the robot. The rollers should form an “X” pattern when you look down on them from above, and should make an “O” or diamond against the carpet.

The other thing I’d look at is whether you have each motor going to a separate speed controller. I have seen very strange power symptoms when two motors are accidentally cross-wired between two Victors.

We had this on our robot last year… took us forever to figure out why we could drive straight and turn just fine, but when we tried to strafe one side of the robot just refused to move! Swap two wires around, and it worked perfectly.

Thanks everyone for your replies. It turns out there was a loose wire in the VRM that wiggled around when we strafed or rotated. Everything works now! :]

You may want to teach your Electrical Team to do a pull test on each wire they install in a component or crimp a lug onto, immediately after they install or crimp that wire, before moving onto the next wire. Afterward, they go back and check their work, looking at the connections and doing a second pull test. We had zero electrical failures last year after I instituted this practice (other than when someone drilled through a tube into the wire running into the tube). I borrowed this from work where we do a lot of wiring in the equipment we build.

The value of 37.37 is recorded in the voltage field to indicate “bad packet”. This is rarely seen in the driver station, but is shown in FMS on the field frequently. The most common causes of this is “no code”(including comm failure due to radio power brown-outs, etc.)

Source: CSA and FTAA