Is there any setting for motor compensation?

Looking to build a 2 motor system with a joystick. Is there a motor compensation setting that can be configured without writing a script? Say when going over a rock with one motor more power would be applied to that motor?

If you operate the motors in closed loop speed mode, the controller will automatically increase the power to compensate increase in resistance.

Can you explain more? The manual says It would need an optical encoder.

Closed Loop Speed mode
In this mode, an analog tachometer or optical encoder measures the actual motor speed. If the speed changes because of changes in load, the controller automatically compensates the power output. This mode is preferred in precision motor control and autonomous robotic applications

dev.roboteq.com/dev1/technology/roboteq-...ontrolers-technology

I\'m confused? Please explain more.

In closed loop what does
-Proportional gain
-Integral gain
-Differential gain
-Integrator limits ......DO?

You would need a speed sensor. An optical encoder is the best solution.

Without speed sensor the controller has no way to know if the motor has slowed down.

THe manual gives a fairly long explanation. You can also look for closed loop speed control articles on the net.

roboteq wrote:

If you operate the motors in closed loop speed mode, the controller will automatically increase the power to compensate increase in resistance.

OK so this is not correct. With my setup I won\'t be able to add a sensor. oh well

Another, classic, approach to load compensation is IR compensation. This adds (a bet less than) the motor voltage drop, that is I * R, to the command voltage. I do not know if the motor current estimates that the Roborun software provides are accurate enough at low PWM, but, if so, it would be helpful if Roboteq added this to the software. IR compensation can be scripted, either using the motor current estimates if they\'re good enough, or using current sensors.

LROBBINS wrote:

Another, classic, approach to load compensation is IR compensation. This adds (a bet less than) the motor voltage drop, that is I * R, to the command voltage. I do not know if the motor current estimates that the Roborun software provides are accurate enough at low PWM, but, if so, it would be helpful if Roboteq added this to the software. IR compensation can be scripted, either using the motor current estimates if they\'re good enough, or using current sensors.

Lenny..I have the script you wrote for Bergerman. The whole script thing confuses me. I would like to order the unit soon, but keep going back and forth with the 150A unit or a 120A R-NET. I\'m going to use it for a offroad buggy so power is a must. I just wish Roboteq would build it into there unit. An optical encoder is out of the question for my setup.

I can think of two reasons why Roboteq might not want to build in IR compensation:
(1) If the internal motor amp estimates are too inaccurate, external current sensors would be needed and it may be difficult for Roboteq to write something generic enough to work with a wide variety of sensors one might chose to use. Of course, closed-loop control also involves external components, yet Roboteq has included firmware for that. And they have also included firmware for torque feedback (the reverse of IR compensation) and note that external current sensors may be needed for that too.

(2) Because IR compensation is POSITIVE feedback setting too high a value for motor resistance can create a dangerous, runaway situation; maybe they\'re concerned about this safety issue. Of course, attaching a closed-loop sensor (encoder or other) backwards will also create a runaway, and there are repeated warnings about that in the Roboteq users manual.

In other words, Roboteq could build in IR compensation, with advice about possible need for external current sensors and warnings about what happens if you set motor resistance too high. They just have to want to.

Ciao,
Lenny

IR is not sufficient to estimate the speed of the motor. The voltage that is applied to the motor is also needed.

The voltage to the motor is the actual battery voltage multiplied by the PWM ratio.

Measuring the motor speed then comes to estimating the motor back EMF. The motor speed is proportional to BEMF.

The formula is then

Applied_Voltage = Back_EMF + Voltage_Drop_in_Motor_Resistance

The voltage drop = Current * Motor_Resistamce

And

Applied_Voltage =Battery_Voltage * PWM_Ratio

So

BEMF = (Battery_Voltage * PWM_Ratio) - (Current * Motor_Resistance)

The difficulty here is that our controllers measure the battery current and the motor current is computed. The motor current measure is therefore not very accurate at low PWM. It is not measured at all when PWM is 0%. Nevertheless, the BEMF could still be measured with reasonable accuracy over most of the PWM range.

Using an external sensor, like the Allegro we recommend in the manual, would allow to measure the motor current directly and with good accuracy.

The motor resistance also changes with the motor temperature, which will affect the speed calculation somehow.

We have plans to incorporate the above in an upcoming revision of the firmware.

In the meantime, it is possible to do it already using the scripting feature of the product.

Glad to see that you intend to add this!

I think that we are actually on the same wave length, but speaking from slightly different perspectives.

If one wants to use IR compensation in a closed loop, you indeed have to estimate motor speed using back EMF.

If, however, you just want to create an open loop rough compensation, I think that you can just do:

New command value = JS command value + I*R (suitably underestimating R to avoid runaway).

For wheelchairs, tight, closed-loop control can be unpleasant while sloppy, partial compensation can really improve driveability. Same for motor resistance vs. temperature. Current WC controllers do not correct for this as the effect is relatively small compared to the \"slop\" in the open loop and the headroom one creates by using a milliohms value well less than measured resistance. (Usual recommendation is to start with a value 20-30% less than measured, increase in small increments until behavior gets \"twitchy\", then back off from that.) I\'ve also noticed that the R estimate needed decreases a bit as a new motor loosens up with use. If brand new motors had R set as 105 milliohms, after a few month\'s use 100 milliohms felt better (especially at very low speeds). The thing with the biggest effect on the usefulness of IR compensation is having motors with enough reserve torque and wiring with low enough resistance - otherwise, compensation does no good no matter how hard the controller tries to say \"GO\". It also helps to do things like get rid, as much as possible, of mechanical hysteresis in caster swivels etc. - a non-vertical caster barrel can really overwhelm things.

In any case, either calculation can be easily scripted and if one really wanted the \"closed loop feel\", then encoders on the motors or, even better, on a caster barrel as that would directly say where the chair is pointing, or a gyro would be better than IR compensation.

Just how important compensation accuracy is at very low loads, or how \"loose\" or \"tight\" one wants the feedback to be, will depend on the application and some real world testing. It may very well be necessary to add external current sensors, but it may be possible in the real world to get away without them. The script I wrote for Burgerman has NOT been tested as I don\'t own a Roboteq, he didn\'t want to take time to set up a bench test and he hasn\'t yet gotten his new chair assembled. I don\'t know whether this \"long distance\" collaboration is going to work out well at all. I would feel much more comfortable if there were someone involved who both had an HDC2450 and script-writing skills, but so far no one has volunteered.

I am considering using a Roboteq for my daughter\'s next wheelchair, but there\'s a lot to do and test before I decide to spend the, for us, not insignificant sum. Her control needs are complex, e.g. she drives, controls tilt and lift, and controls her voice-output computer with a non-proportional switch array, but there\'s also an attendant joystick. With this complexity, a decent information display is also required. I think that the HDC2450 has, at it\'s evolved state, pretty good fail-safe/safe-fail characteristics, but I don\'t want to compromise things by, for example, running noise-sensitive analog signals from control modules to controller, nor do I want complicated ad hoc cabling to connect, for example, a PWM joystick and lot of digital pins. So my present project is making some (Arduino NANO + MCP2515 + MCP2155 CAN nodes to learn how to use that bus. If that works out well, I might then be ready to shell out the $$$ for the Roboteq.

Ciao, Lenny