---

Remember that everyone owns this documentation and if you find any errors or out of date information you should fix it.

Contents

• Prerequisites
• Motor selection
  • Motor recommendations
  • REV motors and controllers
  • CTRE motors and controllers
  • Electric skateboard motors and controllers
    • Flipsky motors: a mechanical problem
    • ODrive Motor Controllers: a software nightmare

Prerequisites

To understand some of the content on this page, you'll likely need a basic understanding of systems engineering. However, some content requires no understanding of SE.

Motor selection

Deciding what motor to use is absolutely a system decision: it affects mechanical (mechanical interfacing (mounting, output shaft, gearbox?, etc.), its torque, RPM, etc.), electrical (peak current draw, average power draw, voltage (power and data), etc.), and software (motor controller compatibility, built-in control systems, etc.).

In the past, the team selected motors based on mechanical needs only, which ballooned controls integration time. If you've skimmed the 2022-23 year-in-review, you may have wondered why the team chose to use Flipsky (electric skateboard) motors and the ODrive (electric skateboard) motor controller in the first place. The answer: a too-casual decision that did not seriously consider alternatives nor the ramifications on the Controls team. Trade studies may be an appropriate method to guide this decision.

Motor recommendations

Based on our experience, here are the recommendations we have for the future:

• Select motors with more power than the team expects to need because power can always be reduced. Yes, it costs more money and mass, so within reason.
• Design with adjustable planetary gearboxes to easily account for unexpected changes in torque and speed without affecting the rest of the system.
• Determine the exact motors before PDR, likely using trade studies. Review this decision at PDR. Stick to it.

REV motors and controllers

Seems to be mostly focused on FRC teams, but beginning to be a little more open. They actually sent another team their CAN protocols, and we got it through that team.

CTRE motors and controllers

Seems to be friendly to non-FRC teams.

Other teams have shared that you cannot use different versions of Phoenix Tuner (i.e. 5 and 6) on the same system. This means no Talon SRX and TalonFX.

Electric skateboard motors and controllers

Some teams use electric skateboard motors due to their compactness, high speed, and relatively high torque. If these motors are strong enough to propel a human being at 25 mph, they should be about right to drive a robot.

They're also frequently fit with sensors that can help electric skateboards detect whether they are losing traction or in a crash, which is useful for robots as well.

In 2022, one of the team's leads, who had built their own electric skateboard using Flipsky motors and the ODrive motor controller, recognized these benefits and figured they'd work well for the robot. Based on our experience with them, we do not recommend using electric skateboard motors in the future.

Flipsky motors: a mechanical problem

Flipsky motors, and electric skateboard motors in general, are not designed to interface with gearboxes. The team has always found it necessary to output more torque than an electric skateboard motor can produce, and gearboxes seem to be the best way to achieve large reductions.

In fact, these motors are designed to interface solely with rubber belts. We found these tended to ride off of the drive shaft and/or shred the teeth, resulting in a dead robot.

They were also difficult to dust-proof because the entire motor housing rotates.

ODrive Motor Controllers: a software nightmare

As bad as the Flipsky motors were, the majority of the hatred towards Flipsky and ODrive motors from the 2022-23 team came from this board. At a high level, the board is designed for an electric skateboard, which has very different needs than a robot, especially when the team was using it for a tracked vehicle on a granular lunar simulant.

The documentation looked good from the outside, but when it came to actually using it, we ran into many issues with no documentation at all. It was also extremely difficult to find documentation, even if it did exist. There were several safety settings that we had to manually dig around to discover to override in order to get the motor to work for us. This took weeks. It's not easy when there's no documentation for this and we have no idea what's wrong. Again, it's not designed for this purpose.

We eventually did get it to drive in the lab, but then at the competition, it stopped working. After a few all-nighters, the system again worked at the competition in the pit, elevated on a table. The robot was placed on the ground and it suddenly did not work. The ODrive never worked again. We do not know why it broke, but this was absolutely the last straw. No one from the 22-23 team was willing to touch an ODrive ever again. Not even to get the robot to work for testing or outreach events. So, in F23 we changed the control system to use NEOs and Spark MAXes, and they worked well.