Motor Selection and Software

[pinkfloyd]

I have a system which doesn’t require too force and it should be opened 90 degrees. So which permitted motor in FRC 2019 season should I select? Why I would select it and what are the advantages for finance and control? What extra recruits should electronic team should link/couple (or is it necessary)? What methods should I use for software? Where or what from I’ll get help for optimizing these methods?

[oscarfonseca · Accepted solution]

Hello pinkfloyd,

That's one interesting question. I would take the following approach:

1. Each motor must be wired to a motor controller. I would check the allowed motors and motor controllers in the game manual here: FRC Game & Season Materials (For 2019 you want to check section 10.6).
2. After having the allowed motors, I would check their price and specifications. You can also rely on community-made resources such as the JVN calculator.
   1. Some controllers have more capabilities than others depending on the manufacturer and the interface they use. For example: a PWM controller will not have as much functionality built-in as CAN controllers. This will depend on the manufacturer's API and interface.
3. The software methods to use will depend on the control interface. PWM controllers are built-in with the WPIlib VIs, while the CAN controllers require the vendor's API (Phoenix or REV usually).
4. Optimization will also depend on the controller, and usually the motor controller's documentation will have a reference or procedure on how to tune their devices.

I hope this information gives you good steps to take this endeavor. All the best,

[pinkfloyd]

---

@oscarfonseca wrote:

Hello pinkfloyd,

That's one interesting question. I would take the following approach:

1. Each motor must be wired to a motor controller. I would check the allowed motors and motor controllers in the game manual here: FRC Game & Season Materials (For 2019 you want to check section 10.6).
2. After having the allowed motors, I would check their price and specifications. You can also rely on community-made resources such as the JVN calculator.
   1. Some controllers have more capabilities than others depending on the manufacturer and the interface they use. For example: a PWM controller will not have as much functionality built-in as CAN controllers. This will depend on the manufacturer's API and interface.
3. The software methods to use will depend on the control interface. PWM controllers are built-in with the WPIlib VIs, while the CAN controllers require the vendor's API (Phoenix or REV usually).
4. Optimization will also depend on the controller, and usually the motor controller's documentation will have a reference or procedure on how to tune their devices.

I hope this information gives you good steps to take this endeavor. All the best,

---

You helped me a lot, thank you very much. Can you explain how to do optimization of PWM COTS?

[mjshafer93 · Accepted solution]

The methods (software commands) available for the PWM controllers vary a little, some of the controllers support having limit switches or encoders wired directly into them, others do not (see specs again), but the basic setup is an 8 bit speed output with direction (so, 255 * 2 possible values from full reverse, stopped, full forward - here the motor and controller are going to have a huge impact whether that grade is linear or not).

If you're trying to make the arm go exactly 90° and back, you might consider using either an encoder (digital, relative to startup) or a potentiometer (analog, but absolute) to detect the arm position and either use PID (a control theory that the software has built in methods for, but also the more advanced motor controllers have built into the hardware/firmware on them) or move the arm slow enough that your software can constantly check if it is at the desired position and move it if not.

How slow should the arm move?
  Depends on what you're trying to do (what is the acceptable speed to perform the action?)

How much should you gear down the motor?

  At least enough that your expected load won't stall the motor - see manufacturer's specs/JVN calculator for this

You might also consider a servo (if what you're doing does not require a lot of torque) as they provide positional control easily (and much less wiring since the controller is built into the servo).

[pinkfloyd]

And I have one last question, thanks for standing me. Where or what from I’ll get help to optimizing these methods?

[mjshafer93]

What type of optimization are you hoping for?

Software? (as in fast response time on the controller)

Motor speed? (as in the arm moves quickly)

Motor precision? (as in the motor hits the 90° accurately)

[pinkfloyd]

---

@mjshafer93 wrote:

What type of optimization are you hoping for?

Software? (as in fast response time on the controller)

Motor speed? (as in the arm moves quickly)

Motor precision? (as in the motor hits the 90° accurately)

---

Software optimization 

[oscarfonseca]

pinkfloyd,

The PWM signal is generated in the roboRIO's FPGA and there is no way to optimize more this portion of the system as it is not accessible to teams. Moreover, the Teleop.vi is set to run every ~20ms (50 Hz), which is also the fastest I would recommend updating the value that is being sent to the motor controllers.

Usually with optimization questions, the correct question to ask is the problem you're having that is making you consider optimizing. For example: my robot responds slowly, therefore I want the code to run faster. If you provide this context it's easier to recommend what to do, instead of using a generic optimization terminology (which means different things to different people).

Regards,