We are having trouble getting our intake motor and roller combination to work and would like some help from anyone.
We have an RS550 connected through a banebots 16:1 P60 gearbox driving an intake roller.
Originally this worked fine, we replaced the motor and gearbox and now when we intake the motor stalls and (very oddly) the robot disables. The PDP breakers aren’t tripping, and we looked at the log file and the current goes up to about 40A, and the main voltage drops to around 11V, but there is no evidence in the log file of a brown out.
we can’t figure out why it would instantaneously disable the robot.
We are looking to replace gearboxes and motors again, but we can’t figure out what mechanism or control in the control system is causing the disable.
It shouldn’t be disabling the robot at 11V. Should go much lower.
Have you tried stalling other motors or mechs on the robot to pull 40+ amps to see if it’s always shutting off when you pull moderate current, or only when you pull moderate current on that single circuit?
I think the primary suspect in this case is the motor and gearbox that you swapped in.
Took the practice robot and used that control system (RoboRio, PDP, TalonSRX) and drove the intake motor and roller. That never disabled and worked fine. So seemingly the motor and gearbox are fine.
We the swapped out the Talons and kept the original RoboRio and PDP; with that configuration we still have disables.
That seems to isolate the problem to the RoboRio and/or PDP (?).
We put Anderson connectors on our CAN bus on the competition robot, and we are also wondering if we are getting some sort of bounce and losing data transmission and that is disabling the robot? (Our practice robot just has twisted and taped CAN bus).
What would cause the robot control system to disable?
When using the new Talons on the original PDP did you use the same breaker/output slots as you did with the competition bot? If yes, can you try a different breaker/slot?
One of the first things we tried was keeping all the original motor, gearbox, PDP, RoboRio, Talons and just moved it to a different slot on the PDP (I think that’s what you were asking). We moved from a 20A slot and breaker to a 40A slot and breaker.
I know this is a long shot, but check the motor to see if you happen to have one or other of the motor leads grounded to the motor can (which is probably connected to the chassis). Note, this is a defective motor if so. You’ll have to move the rotor of the motor to multiple spots to check all 3 windings of the motor for shorts.
But if this is happening it is possible that it is causing some odd behavior where the RoboRIO or CAN or some other electronics freaks out and causes the behavior you are seeing.
It is a long shot but it does have the advantage of the fact that chassis ground problems can manifest themselves in very very odd behavior of the robot.
Something to consider. Hope it isn’t a rabbit hole for you to fall down.
The motor and gearbox is face mounted to 1/4in polycarb; the motor is 6 inches away from the chassis.
But interesting - we did ohm out each motor lead to the motor case. And that motor seems to have values that go down to .9ohm as we spin it by hand slowly.
What should that usually be?
We were going down a path of a loose USB tether, our RoboRio. But we thought that should always manifest itself with a “communication” error, and it was just simply disabling without any noted error.
We just went through a few 550’s - we found one that runs that both leads are completely open as measure to the case. All the others measure a few kohms - to just under 1ohm as you spin the rotor.
0.9OHM? Not KOhm or MOhm? If so, something is wrong with your motor. Why did you switch to this motor? Do you have another you can use?
I like that it’s on plastic and not on the chassis proper but how is it driving? I know that in the year of the Banebot shorting motor fiasco, there were a number of teams that reported the problem when driving through chain or gears, even with the motor can itself isolated. Chain and gears are not great conductors but they do get a lot better when there is pressure squishing out all the grease/oil at the interfaces.
Maybe this explains the “it happens when we stall the motor” behavior?
Back to the resistance value of 0.9Ohm, if you DID mount this motor to something connected to the chassis frame, you may not pass inspection:
R38 All wiring and electrical devices, including all Control System COMPONENTS, shall be electrically isolated from the ROBOT frame. The ROBOT frame must not be used to carry electrical current.
Note: I was another mentor with djdaugherty as we were testing tonight.
Yes, We measured about 5 different 550’s we had around. We did not check resistance to the can prior to mounting, we simply spun it up and it ran in both directions, and seemingly well. When we compare all the motors we dug out, all ran forward and backward, and measured motor leads to the can for all. Most varied anywhere from a few ohms (yes, ohms), up to 10’s, and maybe a kohm here or there.
We had one motor that looks like it was never used before, and that was completely open between the motor leads and can (Mohm or greater). We ran that motor fine.
It seems like we should replace the one on teh robot with that one.
However - we havent changed it yet and haven’t had any disables in the last while. I’m still leaning toward a comms issue although admit the motor is a problem also. I just can’t understand what mode the is causing the disable. It seems like there has to be some trigger of a faulty somewhere…
The motor’s low resistance to the case is a compelling bit of evidence, but you’re right to wonder why it would disable the robot. Just for completeness – what control are you using to activate this motor? Is it a joystick axis, a gamepad button, a Dashboard variable, or what?
We code in C++, and we use one of the triggers on the front of an xbox controller for the intake roller.
Looking at the code though now, I see that it’s set up so one trigger is forward and the other trigger is reverse. I’m wondering if there’s some strange mode when both triggers are pressed and the code fires off two simultaneous commands, one forward driving the motor and one reverse driving the motor. We have deadbands and smoothing on the analog joysticks, nut none on the triggers.
That’s probably a code robustness issue, but I still am not aware of any reason why that would disable the robot.
Maybe put in something that checks the trigger for “pulling the boulder in” first and if that is activated, don’t bother checking the second one? Only activate the “pushing the boulder out” if that is the only trigger being pressed. This is assuming that you want a “known fail-safe” where you aren’t throwing a boulder out accidentally at a random time but holding onto it instead.
Basically pick one direction as the dominant one to eliminate the dual-trigger issue by ignoring whether the recessive is being pressed or not.