0
$\begingroup$

With a group of students we are building an exoskeleton for paraplegics. I am part of the Software & Control department and we are designing the motor controller configuration. We have several requirements:

  • Size is one of our main requirements. We want the Exoskeleton to be as slim as possible, so this is true for all the components as well. We want the motor controller to be as small as possible.
  • The motor controller has to work with a brushless DC motor
  • A setpoint will be sent from a microcontroller to the motor controller Two or three absolute encoders need to be connected, this depends on the design of the joint. **We are either going to use position or torque control We need one encoder for the motor angle, and one for the joint angle. We might implement Series Elastic Actuation in our joint and then we want to be able to measure the deflection in the spring and thus need two encoders for that.
  • A continuous power output in the range of 700 - 1200 Watt

While exploring several off-the-shelf possibilities, we came accross the Elmo Gold Twitter and the IOMI Pro. One of the problems of these boards, is the amount of absolute encoders that can be connected. Both the Elmo and the IOMI board can either have 1 or no absolute encoders connected.

We came op with a solution, so that we are able to connect multiple encoders. In our exoskeleton we are going to use an EtherCAT Master-Slave configuration. The High-Level control (e.g. state-machine) is on the EtherCAT Master and sends joint angle setpoints. Our idea is to use a EtherCAT Slave as a sort of second controller, which gets the joint setpoint and the joint encoder values, calculates the motor setpoint and sends this out to a certain off-the-shelf controller like the Elmo Gold Twitter or the IOMI Pro.

Configuration

My question is the following: Is this even a good solution? And what are other solution to this problem? Are there even better alternatives for a motor controller? Might it be a better idea to build and program your own motor controller? (please bare in mind that we have limited experience in that area)

I thank you all in advance for your reply!

Cheers!

Nathan

$\endgroup$
  • 1
    $\begingroup$ Why do you want to connect multiple encoders to a motor controller? A motor controller actuates one motor and reads feedback from one encoder to close the control loop. Having multiple encoders for one control loop doesn't make much sense. Please elaborate. $\endgroup$ – Bending Unit 22 Dec 8 '16 at 13:50
  • $\begingroup$ We use brushless DC motors due to their high power density. The problem is that you need to tell to these kind of motors which coils need to be turned on, and which have to be turned off (the task which the brushes perform in a brushed DC motor). Thus there are two control loops: joint position, motor coils. The motor coil control is also often performed using hall sensors. $\endgroup$ – ProjectM Dec 22 '16 at 11:33
3
$\begingroup$

"My question is the following"

Is this even a good solution?

No, not really. As BendingUnit22 mentions, a motor controller... controls a motor. One motor. The biggest problem I see with this is that you've got the EtherCAT slave on the feedback line, trying to do signal processing, instead of piping the feedback directly to the motor controller.

The motor controller is setup for one motor. Use one motor controller for each motor you want to use.

What are other solutions to this problem?

Open-ended design problems are off-topic (you could join us in Robotics Chat and ask there if you like). That said, you haven't mentioned how you are converting from a brushless DC motor to the joint, but I'm going to guess you've got some kind of fixed gearing between the motor and the joint.

Your options there are to either put an encoder on the joint and do processing on the feedback signal to convert to motor units (as you've depicted), or you could put the encoder on the motor and do processing on the reference signal to convert the desired joint angle to motor units. My preference, personally speaking, would be to put the encoder on the motor. This means that all of your processing (converting between joint/motor units) is done before the motor-control loop. Processing introduces delays and those delays (negatively) affect control.

Something to think about, but I'm not going to speculate on your options here beyond pointing that out. You can leverage the knowledge of the fixed gearing between motor and joint to quickly scale desired joint angles to desired motor units and vice-versa, depending on where you want to put the encoder. I believe most BLDC motors come with encoders already, though generally not absolute encoders, which you would need.

Are there even better alternatives for a motor controller?

Terms like "good" and "better" are for you to decide; they have no quantifiable meaning on their own. Once you set a list of specifications, you can rank options by how well they meet or exceed each of the items on your list of specifications. If you can rank your specifications then it should become obvious that some options are "better" for your application than others, but again that's all dependent on the list of specifications that you generate.

I'll add here that I think a lot of people put cost as a specification, which is generally advisable, but they put too much emphasis on it. What matters more to you, cost or quality documentation? Cost or that the motor utilizes industry standards (NEMA bolt patterns, standard shaft sizing, reasonable power interface)? Cost or supplier's return policy? Cost or availability?

What good is a cheap motor when you can't bolt it to any standard accessories or gearboxes? What good is a cheap motor that arrives DOA and then you can't exchange it, or when the exchange process takes 3 months?

I ask because these are all (absolutely colossal) problems I've actually faced on academic design projects. Some of these oversights nearly killed a couple (graded) projects I worked on.

Might it be a better idea to build and program your own motor controller?

Generally speaking, yeah, I think that's a great project. Unfortunately for you, that's not the project you're supposed to be working on. You stated that you're part of the software and control department. The other people on this project are counting on you to get a motor controller done and programmed so the other teams can get their portion of the project completed.

A frame that can't be actuated doesn't help anyone and looks bad on everyone.

If this was your own pet project, then I'd say go for it, but because you're working in a team environment, where there are other people depending on you to complete your work in a timely manner, I'd say save that project for when you have time and try to find an off-the-shelf product that meets your needs for now.

If your teams are big enough you might be able to split this project off for yourself, after you help acquire at least passable motor controllers. The problem with designing your own is that you need to:

  1. Interface with the motor encoder, in all the formats the commercial motor controller could (or, at a bare minimum, in all the formats for the encoders you're using).
  2. Design the schematic for the power electronics capable of providing 1.2kW.
  3. Design the PCB for the schematic, including layout and trace size. 1.2kW isn't "high power" by any means, but it's enough that you're likely to blow up a couple boards before you get the design right.
  4. Design the housing/mount footprint for the completed circuit.
  5. Actually assemble and solder the PCB.
  6. Program the PCB, including the packet processing for EtherCAT if you go that route, the input processing and conditioning for the encoder feedbacks, and then the actual control algorithm for the motor speed control.

This might "only" be a couple weeks of working full time, but there's generally a couple weeks of down time between completing the PCB design and receiving the boards, and like I mentioned I would be money you'll blow at least one board. You have to have everything perfect; all the component datasheets read correctly, transcribed to schematics correctly, transcribed to PCB correctly, components placed correctly, and then soldered correctly, and then programmed correctly, for the thing to work.

If you blow a board because you didn't place or solder or program something correctly, then you're out the turnaround time on the replacement parts.

If you blow a board because you didn't get the schematic right, then you're out the turnaround time on replacement boards, which again is probably a couple weeks.

How do you know the difference between blown by bad schematic and blown by bad construction? Good question. That'll probably take at least a week or two.

And the whole time, the rest of the project is stalled while everyone else on the team waits for the motor controllers.

You stated you or your team ("we") don't have much experience in that area. I don't know how you were thinking you might build and test your own motor controller circuit, but a breadboard is absolutely out of the question. Breadboards can only handle 0.5 to 1 Amp max, so whatever circuit you're testing with one is certainly not a 1.2kW motor controller, or even a 700W motor controller.

$\endgroup$
  • $\begingroup$ Thanks a lot for your in-depth advice. I agree that designing our own motor controller might be too dangerous if it is our only option, if we don't finish it in time (which can happen due to lack of experience), it might block the entire project. $\endgroup$ – ProjectM Dec 22 '16 at 11:21
  • $\begingroup$ We will indeed place a transmission between the motor and joint, with a ratio of ~100. I think the problem will be with using only one absolute encoder placed at the motor side, is that we still don't know the absolute position of the joint, because the absolute motor encoder will not count the rotations while being turned off, this we would need to recalibrate each time the system is turned on again. $\endgroup$ – ProjectM Dec 22 '16 at 11:22
  • $\begingroup$ The solution of placing just an absolute encoder at the joint does sounds interesting, the only problem we see here is that small errors in the joint encoder reading and noise caused by backlash and bending, may result in very large errors at the motor side, since it is multiplied by the transmission ratio. We are now considering another motor controller option which can handle two absolute encoders. Once we get things working, we can still have a look at different encoder setups which might make the overall design smaller, but it feels to dangerous to do this now already. $\endgroup$ – ProjectM Dec 22 '16 at 11:22
0
$\begingroup$
  • Is this even a good solution?

That depends on what you call good. I would certainly make sure that you can justify the role of each component in the system. Why do you need some many encoders if current exoskeletons do just fine with less? In order to decide if your solution is good or not, you should have clear list of requirements (e.g. required torques, velocities, resolution, price, etc.) including also functional requirements (elasticity of joints, etc.) If all requirments are satisfied, your solution is good.

For possible improvements, I would advise you to define each control loop you plan to have and make sure that you have the required amount of sensors and controllers to implement it. By required amount I mean no less then necesary but also no more then necesary. Each sensor you use should participate in (at lease one) a control loop and you have to be sure that the sensor is not measureing a parameter which can be easily calculated from a different sensor with the required precision. Also consider the latencys on the bus system you plan to imlement in your control loops and decide if they are acceptanble. The main idea would be to use as few components as possible, so you should be able to answer the question "Why can't the task of this component be done by an already existing one?" for each component in you schematic.

  • And what are other solution to this problem?

When you combine mechanics, electronics and software, there are probably an infinity of possible solutions to a problem. You can consider diffferent actuation types, differetn motor types, differen communication systems, etc.

  • Might it be a better idea to build and program your own motor controller?

If plan to use industrial communication protocols (such as EtherCAt, or ProfiNet) I would advise against doing your own controller If using i2c for example is an option and this is a controls assignment (not a systems assignment), I would advise you to definetly make your own controllers. It might not work perfectly (it might not even work) but the amount you learn by programming your own controller is worth far more then buying one.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.