A question re interpreting something in user's manual

In its description of torque mode, the manual says:

Furthermore the resolution of the amps capture is limited to around 0.5% of the full range.

Does "full range" refer to 0-1000 units (i.e. 150A for an HDC2450) or to -1000 to 1000 units (i.e. 300A for that controller)?

You might also note that in either case this is better resolution than that given by an unfiltered 100A Allegro sensor.

Ciao,
Lenny

Thanks Blake.

Given that I and several others have successfully used IR motor compensation with unfiltered Allegro sensors, and the Roboteq battery current is more precise than that, it's only estimated motor current when PWM is less than 200 (20%) that poses a problem. Given that a recent controller failure damaged and eventually destroyed the Allegro sensors, leading to a 500 msec runaway in reverse, and that I haven't been able to think of a way to make them "safe-fail", I have been re-thinking use of estimated motor current for this purpose. At this point I have gotten motor compensation using estimated current to work smoothly and precisely. It involves three things:

(1) If (abs(Throttle) + abs (Steering)) > 0 and BatteryCurrent < 20 (0.2 Amps) add 20 to the battery current so that there will be some compensation even when just starting out.

(2) If PWM < 200, boost BatteryCurrent by a small multiplier (3 works out well on my daughter's chair) at 0 PWM declining linearly to 0 at PWM = 200. This partially removes the increasing underestimate of low motor currents one gets with MotorCurrent (for PWM < 200) = BatteryCurrent/0.2 without the wild excursions toward infinity that one gets with the basic MotorCurrent = BatteryCurrent/(PWM fraction).

(3) Because turning with neither forward nor backward movement has a high torque demand, especially on difficult surfaces such as carpet or rough concrete, an R value that gives safe motor compensation at high speeds (IR motor compensation is positive feedback, hence requires caution) can give very sluggish behavior in a turn-in-place. This is strongly dependent on the weight and CG of the chair, but increasing R when not moving forward or back safely overcomes this hesitation. Because the extra compensation needed will vary a lot for different geometries, I have used two parameters: first, the increment of R to apply when ForeAftPower = (abs(GetValue(_MOTPWR,1)+GetValue(_MOTPWR,2)))/2 = 0. Second, a limiting value of ForeAftPower at which the additional R disappears, with a linear decrease from ForeAftPower = 0 to ForeAftePower = TurnBoostLimit. (Note: this turn-in-place strategy is needed with current sensors as well for chairs with heavily loaded casters.)

I don't know if the same strategy would work for torque (constant torque, variable speed) mode, but for IR motor compensation (constant speed, variable torque) it seems to completely eliminate the need for motor current sensors and we're getting both near constant speed with changes in loading and nice, precise response to joystick inputs.

Ciao,
Lenny

P.S. I still haven't gotten a failure analysis for the unit I sent back to Roboteq. I'll not send new board designs to the fab house, nor install the replacement HDC, until I know whether that teardown points to the same cause as my "black box" guess from the failure symptoms. For now, Rachele is using the spare unit, damaged but still usable, with a manual brake on/off switch rather than digout control.

I wrote something misleading in yesterday's note. For turn-in-place boosting of motor compensation, only the added R needs to be adjusted for different vehicle geometries. The other parameter, TurnBoostLimit, is the same PWM = 200 used by both Roboteq and in my script for transitioning from EstimatedMotorCurrent = BatteryCurrent/(PWM fraction) to a function that doesn't go infinite at PWM=0.