SPARK MAX Critical Safety Warning: motor controller causes unintended, unexpected motor activation

Technical Motors
1

During individual motor testing on the robot’s four wheels (four NEO brushless motors with SPARK MAX controllers) we discovered that as we stepped through the list of individual motors to test, the previous motor that was tested would turn on simultaneously with the next motor to be tested although the previous motor was no longer in the Java code.

That is, for example:

test only motor #1 by coding it alone in the Java code.
deploy and enable code and motor #1 runs correctly.
disable code.
change code to only motor #2 (change the single digit “1” to a “2”) and deploy the code.
enable code and both motors #1 and #2 run.
disable code.
enable code and only #2 runs which is now correct.

The pattern seems to be whatever motors that were previously running when the code was disabled will start to run again after deploying new code, if the new code does not set a new speed for them. It appears that a background process that isn’t cancelled with the new deploy has memory of the old speed and is used for the first enable after deployment, if a motor’s speed is not updated in the code. The second sequence of disable / enable finally clears that old motor speed and the previous motor is turned off and just the new motor runs as expected.

Issue appears with firmware update 1.0.385 and earlier versions that we had. Visual Studio Code Java library SparkMax-Java 1.0.28

Code snippet for motor #1:

private static CANSparkMax motor = new CANSparkMax(1, CANSParkMaxLowLevel.MotorType.kBrushless);
motor.set(0.5);

Then motor #2 by changing the “1” to a “2”

private static CANSparkMax motor = new CANSparkMax(2, CANSParkMaxLowLevel.MotorType.kBrushless);
motor.set(0.5);

This brings home the best practices for motor testing:

  • All wheels in the air to prevent robot movement
  • Stay away from anything that could move such as wheels, belts, intake/discharge mechanisms, elevators - expect the unexpected - motors can run at any time for inexplicable reasons
1 Like
2

Thank you for providing detailed information to recreate this corner case issue. We’ve released an update to the API to address this case. I would recommend upgrading to this API version (v1.1.5) with the beta firmware v1.1.26. We will be sending out more information to teams about this update.

Thanks for posting these recommendations! I would take this a step further and say you should follow this type of safety procedure any time you are running the robot with it enabled. For example on Team 3005 it is the requirement that the following steps are taken any time any robot is enabled, and only done so by a qualified operator (i.e. student who knows these rules).

  1. Before enabling the robot, the operator makes sure the robot is in a safe place to be operated in, nobody is near any moving mechanism, and anyone in the area has safety glasses on and knows a robot will be operated
  2. Before enabling, make it known you are about to operate the robot by saying loudly and firmly ‘clear’
  3. Enable the robot through the driver station, making sure the robot is behaving as expected
  4. Know and be ready to use the ‘enter’ key to disable the robot at any time
  5. Make sure somebody is always at the driver station and paying attention

These general rules have worked well for us in our shop, at the practice field, in our pit, at demo events etc.

2 Likes
3