Chassis Burning Out

Hello! We are currently preparing our robot for worlds, but we found an issue with our chassis. After 30 or so seconds of continuous movement, especially turning, two of our motors stall out, and the chassis begins to turning. After 10 or so more seconds, the whole drive stalls out. Our chassis runs on 4 high-speed motors on 4 inch omni wheels.

Right now, we have our left drive on ports 8 (front) and 9 (back), and right drive on ports 2 (front) and 3 (back). The two back motors (ports 9 and 3) are on the power expander.

I know some people like to keep all the chassis ports on the power expander, but we found it best to divide the motors.

Does anyone have any recommendations to fix this issue and port placement? Thank you.

First look for friction in your drive. That’s most likely the problem. Then check your motor controllers to make sure they are working properly. We had one that broke and caused excessive burning out and when we touched it it was extremely hot to the touch. Your port placement is fine.

By “high-speed” do you mean speed (160RPM) or turbo (240RPM)? If you’re running turbo, that’s you’re problem. Managing 4" turbos is a massive pain, you basically need a can of air to cool them down after every match. :slight_smile:

There definitely is friction when we drive it, but since our robot is a dump-claw hybrid, it tends to drag things on the floor a lot, which is inevitable, I think. This problem is recent, though, and only happened during the state championship games. Since we didn’t change our robot at all the week leading to state, I don’t think it would be a problem in the build.

Thanks for the input though, I’ll definitely keep that in mind when coaching :slight_smile:

@FrozenInTime Here is a recommendation. Are you using PID for you’re arm right now? If so, you could quite easily implement a “holding position” like my team did. We run everything through macros, so we have button for grabbing (claw at the ground), a button for holding (arm about 1/3 of the way up, to reduce drag on the ground and move our center of mass back into our support polygon) and finally a throw macro that brings the claw and arm all the way back.

@ethan_matlack We’re not using PID, we rely on our rubber bands to do that for us haha. Our driver just isn’t used to lifting to a midway position.

I have a question though, what’s a macro?

@FrozenInTime A macro is a pre-scripted list of actions that are executed when called. We don’t manually control anything, so our code is a bit interesting, but here it goes.

To start we define a bunch of variables, saying that claw_open means the claw potentiometer reads abc, that claw_close means it reads xyz, etc, etc. This is of course a bit complex since it is actually routed PID, but you get the idea. After defining all of this for the claw and arms, we can now script these actions to buttons. We simply say “when the button is pressed, run the task”. This means we just press a button and claw “locks” open or closed using a small amount of motor power to maintain its position. The same with the arm. Now the fun part - macros.

Mapping actions to buttons thru PID is relatively easy when the code is optimized using these “groups” of actions. Think of macros as a “commander of tasks”. When called, it doesn’t just run one task, but rather multiple tasks together or sequentially. Here is a real-life example. We press a button and a macro called “throw” is started. The macro then calls up “arm_dump”, a task that brings the arm back to its dumping position at abc pot reading. At the same time, the macro calls up a task called “release” that waits until the arm pot hits a certain angle then opens the claw.

All of this combined means we press one button and get the same exact throw every time. It also makes auton and prog skills easier because we can just call one macro instead of writing out a bunch motor commands.

@ethan_matlack Wow, okay thanks! Sounds like a void function.

@FrozenInTime Similiar, but you can only run one void at a time and we sometimes combine macros to create… idk “super-macros”. :slight_smile:

Check for friction around the axles that each wheel is on. Spin each one by hand, it shouldn’t be that difficulty to turn. I’d recommend taking off the motors and spinning it freely by hand to get a good feel for it, unless that’s too much of a pain. I kind of doubt that it’s friction caused by the lift, but that still could be it. How heavy is your bot?

You could have a bad power expander. We are on our fourth one this season. If you have bearing flats on your drive, the screws could’ve come loose and now the motor rods are rubbing metal. If it’s not one of these, try replacing all four motors and controllers.

We’ve tried changing the motors many times, and the left side just keeps on burning out, no matter how many times we change it. Don’t know how heavy our robot is, though.

That isnt normal. Have you checked to see that none of your motors have shorts in them? There was a team at AZ States that had a short and it would pull too much current and trip the power expander.

Our motors are fine. Bad power expanders are par for the course in this area. At almost every competition this season, someone was changing their power expander.

What I would try is disengaging all the shafts from the motors (still in the bearings) and just spinning it with your hand. The wheels should spin freely for a while. If not, check all your bearings and make sure they are perfectly centered.

@FrozenInTime We had similar issues with a 2:1 drive ratio on 4" wheels. You have spaced the motor ports appropriately so I don’t think that is the problem. Assuming that you have checked for any electrical issues suggested above, let me share some mechanical issues from my experience.

The simplest, yet effective test I can think of is to run both sides of the drive at the same speed for 5-10 seconds with no PID, or velocity control.


motor[leftFront] = 100;
motor[leftBack] = 100;  //set left and right side of the drive to the same speed
motor[rightFront] = 100;
motor[rightBack] = 100;

wait1Msec(5000);

motor[leftFront] = 0;
motor[leftBack] = 0;
motor[rightFront] = 0;
motor[rightBack] = 0;


Elementary? Yes. Effective? Yes. Run this code on your robot and see how it behaves. Based on what you have said above, the left side of your drive will not move as fast as your right side. This is a good indication that you have too much friction in the bearings, gears sprockets, etc.

If you do experience what I described above, but can’t find the cause of the friction I have some suggestions. Bent Axle? Too many spacers? Interference with the wheel? Motors internally geared inconsistently? (Definitely worth opening the motors and checking to be sure). Misaligned bearings?

Once you think that you have isolated the issue(s) and fixed them, try the test again and if it drives straighter, then you may have had a mechanical issue and fixed it. As you increase speed and decrease torque, you will be affected by friction much more.

A mechanical issue turned out to be our issue and we were able to fix it this way. Good luck :slight_smile:

Does this happen even when you just start driving it? What if you haven’t driven it for a while? If that is the case, then the problem could be residual heat from previous rounds. One way to combat this is by getting air duster (see image below), turn it upside down, and spray it on your motors. It will form a layer of what I believe to be dry ice on the surface of what you spray it on, this could help cool your motors down. If you do it as your robot is being placed on the field, the ice layer could last into the match, keeping your motors cool while you are driving.https://images-na.ssl-images-amazon.com/images/I/41vMH43PecL.jpg

To make sure it isn’t a short (I had it happen to me in elims at State, yay me), open the back green plate of all the motors on the power expander. Make sure the wire’s insulation is still there in each one. Good luck.

I deleted my last post because it was almost practically what was said on the main post. How heavy is your robot, and are the bearing flats bending, weaving, or being damaged?

What we do when we have a burnout problem is check all mechanical aspect to ensure everything is fine (friction), then we try switching the motor controller, then we try switching the motor port on the cortex/power expander, and finally we switch the motor out. Normally it always seems to be the motor controller. Hope this helps.