Stepper Motors

[AdamHeard]

Originally Posted by Oblarg

I do not think this is really the case. If you choose the wrong stepper for the job, yes, you are going to have problem with skipped steps and accumulated errors. But it is not that hard to pick a stepper with the appropriate torque for a given mechanism.

For many manipulators which require small, precise movements, I think a stepper is far easier to use than a DC motor in a closed control loop. Less complexity, fewer failure points.

Please, walk through the selection of a stepper motor and brushed motor for an elevator for this years game. You'll see that you end up with a giant stepper motor (or you'll leave yourself vulnerable to missing counts due to friction/wind blowing/jammed tote/whatever).

[jman4747]

I don't think that steppers should be restricted. If someone knowledgeable sees an opportunity to use one effectively than why not let them? It may just be hard to imagine how to use them in FRC simply because we haven't ever seen it.

[Scott Kozutsky]

Originally Posted by jman4747

I don't think that steppers should be restricted. If someone knowledgeable sees an opportunity to use one effectively than why not let them? It may just be hard to imagine how to use them in FRC simply because we haven't ever seen it.

The problem is that teams that can already effectively use them are likely already dominant and this would allow them to be more dominant. Or you get the consensus that it's not useful and end up with more throttle motors, but with their own entire section in the manual.

It also has the very real potential to be misused by less experienced teams and cause massive problems when it doesn't work properly.

IMHO it's a can of worms that does not need to be opened.

[jman4747]

Originally Posted by Scott Kozutsky

The problem is that teams that can already effectively use them are likely already dominant and this would allow them to be more dominant. Or you get the consensus that it's not useful and end up with more throttle motors, but with their own entire section in the manual.

It also has the very real potential to be misused by less experienced teams and cause massive problems when it doesn't work properly.

IMHO it's a can of worms that does not need to be opened.

Not necessarily. Plenty of people use them for other robots and things like 3d printers or CNC routers as well as in industrial apps so there should be a large group to draw knowledge from. Plus I'd bet there's a good bit of overlap between the above the FIRST community. Thus I would imagine several teams who aren't "dominant" could acquire sufficient knowledge to use the technology effectively.

Originally Posted by GeeTwo

If I understand correctly, stepper motors require twice as many control signals as a brushed motor. So to save an encoder feedback you add another control circuit - with uncertainty if the torque isn't sufficient to make the step. It sounds like a step backwards, or at best sideways.

That might be a desirable trade off you never know. Or a co-processor could generate the singles from instructions sent over via serial or whatever. Options are options and more is more fun.

[Oblarg]

Originally Posted by AdamHeard

Please, walk through the selection of a stepper motor and brushed motor for an elevator for this years game. You'll see that you end up with a giant stepper motor (or you'll leave yourself vulnerable to missing counts due to friction/wind blowing/jammed tote/whatever).

Clearly, steppers are not suitable for the entire problem space of FRC motion control. You're not going to lift a tote with one.

That doesn't mean that they aren't very well-suited for certain parts of it. Not all of FRC is lifting totes.

[GeeTwo]

If I understand correctly, stepper motors require twice as many control signals as a brushed motor. So to save an encoder feedback you add another control circuit - with uncertainty if the torque isn't sufficient to make the step. It sounds like a step backwards, or at best sideways.

[Oblarg]

Originally Posted by GeeTwo

If I understand correctly, stepper motors require twice as many control signals as a brushed motor. So to save an encoder feedback you add another control circuit - with uncertainty if the torque isn't sufficient to make the step. It sounds like a step backwards, or at best sideways.

Hardware and library support trivializes much of this. You can run a stepper off an arduino pretty easily (online tutorials and libraries abound). If FRC were to offer support for common stepper drivers in their control system library (which would probably be the only way this would happen given FRC rules re: co-processor controlled mechanisms), it'd be even easier.

[Tom Line]

I'd rather see the specs on allowable servos to be opened up.