The following is an email I sent to REV concurrent to this post. Has anyone else see anything like this?
REV,
Today we tried out our two REV NEOs for the (mostly) first time (we did test one through the client the day before).
We were swapping a pair of CIMs on a 2012 b-ball shooter and noticed a weird behavior with one of them. The CIMs had been mounted to AndyMark CIM Motor Brackets; when the one NEO was brought near to the bracket, the motor would occasionally jerk or sometimes run at full power with intermittent jerks even when commanded at 10% voltage over PWM.
The other NEO behaved just fine (correct speed, no jerking), and this NEO would also work fine when located in free space or when mounted to a different aluminum CIM bracket (though this other bracket we couldn’t actually mount to the robot because of sizing problems).
Any ideas on the cause? Electrical short? Hall sensor interference? Both were updated to the latest firmware in the latest client version.
Unfortunately I didn’t take any video today.
P.S. Even with only the one NEO, the shooter was outperforming the two-CIM shooter.
The robot was enabled, and I could, while commanding a constant 10% over PWM, have a smooth running motor, move it while still running to near the bracket, have it running smoothly, then get really close or touch the bracket and then see the jerking behavior.
There are a couple of things that could be going on here. I’m sure the REV support team will get back to you with a more complete answer, but a couple quick things to check .
is the sensor cable completely plugged into the max?
you mention pwm but also the client, can you confirm which one you were driving the motors with?
If it is from the rio are you running the 2020 REV APIs and the new software from WPI?
If you have any electrical setup photos that would also be helpful.
Have you tried swapping the MAX to help isolate it to either the motor or motor controller? If the issue follows the motor it is likely a different problem than if it follows the controller
Interference on the pwm or sensor lines is something we have spent a lot of time looking at and is not likely the culprit.
Did some more testing tonight - it actually occurs when touching the front face of the motor to the robot frame (or the back face, though the behavior’s a bit different there). Here’s some video:
I’ll bet the side of the motor is insulated, it’s plastic. The front is conductive.
The old Robot inspector in me thinks there is a short to the frame somewhere!
It’s actually painted metal, and the sides appear to be less worn than the backside of the motor.
I’ve seen the backside of neos get the paint worn off faster than the sides, just because people leave them sitting on that face. The front side has exposed metal from the worn screw holes.
Get a multimeter (with the motor disconnected!) and check for any shorts between any of the phases AND the encoder wires.
Additionally, check if your frame is grounded to the battery negative, or even worse live at 12V.
Exactly what I was going to say. Get out the multi- meter and check for a frame short. My suggestion is stop testing with it until you test for shorting to the frame as using a NEO direct to battery without that speed controller in the loop actually controlling that brushless motor can damage it (that was never done with that motor even momentarily was it?)
We got out a multimeter, and there was continuity between the robot frame and the motor casing, but only in the moments when it was jerking (i.e. electrical continuity was very intermittent).
We also tried swapping the motor controller and using the PWM cable instead of the CAN cable without effect to the motor behavior.
Have you tried using the getAppliedOutput() function for the Spark Max (I believe it only works over CAN or in-client graphing via USB) to graph the applied output to the NEOs during the times when you are seeing this odd behavior?
Also, did you ever try re-flashing the firmware to the Spark Max and/or using multiple different Maxes or NEOs as @Greg_Needel suggested?
Re-flash firmware, no, except that we updated them to the most recent the day before/of finding this issue.
Multiple NEOs/maxes → The other NEO on this robot has no problems, and we swapped the MAXes with no change in motor behavior for either.
Ok, I was just wondering because REV has pushed about 3? new firmware patches in the last short while (we’re on DFU v1.5.1 now and Client v2.1.1). I would guess that there may be something wrong with that particular NEO as a remote hot take, but that’s just speculation. I would strongly recommend graphing your output in either the client or ShuffleBoard (or similar) and posting here for people to take a look. This would help confirm as to whether it is strictly an issue with the motor.
This feels like there is something electrically wrong here.
It could be a short to the frame or maybe two different ground planes.
It also could be some of the insulation has come off one of the wires inside the motor (most likely a sensor wire) and is touching the case. Have you ever taken the back can of the motor off? Would you be able to to check the wires?
I assume you see something on the front and back of the motor because you have more surface contact than the line contact on the side. The whole case is made of aluminum so there is no material difference in the contact.
By any chance, when you had it on the mounting plate, were you folding or positioning the data wires in an awkwardish position. We’ve had similar issues when the data wires were compromised. BTW it takes next to nothing to damage them sometimes. Also if the data wires are bad or whatever, the lights will go kinda haywire why the motor is acting up.
Look at the entire electrical wiring system on the robot first then, there should not be. That frame is receiving current from somewhere. It has in the past happened to our team 3 times, it can be an old style camera where the mount needed to be electrically isolated, the second was nasty and an on practice field created issue (a long bolt facing up on the practice field at champs, caught fabric on lower side of our bumper, pulled out a staple from fabric on the rear of a bumper, and flipped it up into the sidecar which proceeded to cross 10 full pins on the sidecar burning that board out internally, so swarf needs to be checked in all electrical components like Robo-Rio, PDP, etc), and the other time with an older Robot controller, on the controller with the plug in modules before the robo-rio there was a grounding screw that was never used in any capacity on our robot builds, low on the side that bright shiny screw came in contact with the frame during a too quick replacement by students (removed the screw, isolated the screw hole and frame grounding was instantly fixed), your frame grounding issue could simply be 1 stray strand of wire out of a wago connector touching some part of the frame or something much worse. (You would be amazed what can get inside the the plastic cases of our electrical components). Also, check all wire colors on every circuit to make sure each is proper.
I agree about pulling the can off the affected NEO and just take a look, it is part of the process of press mounting the shaft spline gear, so there is a process laid out in the NEO literature and therefore legal to open it up at least that far to inspect it. Have multiple people look at the entire electrical system very carefully, the more eyes the better.
Follow every wire of every circuit from battery to the end, find out where that short to frame may be. Fix it, then test again. It is critical your frame not be a part of the electrical circuit.