PINNED - Roboteq Controller - developing for powerchairs

[LROBBINS]

*****************************************
CRITICALLY IMPORTANT WARNING!
*****************************************

Vitolds has informed me that some newer Roboteq controllers now have motor current sensors. For example, the GBL2660 spec sheet says:

Measured Amps
The controller includes Amps sensors in line with the motor terminals and on the battery
ground terminals. Both Motor Amps and Battery Amps are therefore measured with precision.

The scripts I've written, both the analog and CANbus versions, do not take this into account.

There are three things to consider:

(1) With brushless motors you cannot connect external sensors so you MUST set "UseCurrentSensors = FALSE".

(2) The "FindEstimatedCurrents:" subroutine improves motor compensation for controllers that ESTIMATE motor current from battery current sensors. If your controller has motor current sensors, you MUST NOT use this option either.

(3) For controllers that do MEASURE motor current, we need a third option. These need to use the Roboteq motor current values directly without any corrections. I will modify the programs so that they give this third option. But please be patient. This should not be a difficult programming task, but it will take me some time.

If you have a controller that has built-in motor current sensors, DO NOT USE MOTOR COMPENSATION until I add the third option. The easiest way to do this is to comment out the line:

Code: Select all

GoSub MotorCompensation

in the MainLoop section of the scripts (both the analog script and the CANbus script).

Using MotorCompensation without external motor current sensors in a controller that MEASURES (rather than estimates) motor current could damage the controller and/or the motors!

[Vitolds]

Again the Russian are to blame

[Burgerman]

Not every time! Only much of the time.

[LROBBINS]

I (tediously) went through all of Roboteq's current data sheets to find out which DC controllers (both brushed and brushless) now have motor amp sensors. It's not just "some", but a long list. Some of you may already be using controllers that do have internal motor current sensors and could have problems if UseCurrentSensors = FALSE.

Hence, I have given top priority to getting the third current sensor option into the scripts. I have tested the revised script to make sure that the logic works and that the external-sensor failure detection (slightly modified) still works, but that was without real motor loads. This evening, when Rachi isn't using her chair, I will test that the motors respond properly to the three choices (CurrentSensors = external, internal or none) and that the external sensor failure routine gives driveable but obviously noticeable results with both failure at startup and failure after already running.

Here are the two lists, but be sure to check the latest data sheets at the Roboteq site in case there are any changes or I've missed something:

controllers WITH built-in motor current sensors
FBL23xx
FDC32xx
GBL26xx
GDC36xx
HBL23xxA (but only the "A" version)
KBL1xxx
MBL1xxxA (but only the "A" version)
MDC1xxxA (but only the "A" version)
RGDC18xx
SBL13xxA (but only the "A" version)
SBLM23xx
SDC32xx

Controllers WITHOUT internal motor current sensors
GBL18xx ("prelininary" spec sheet)
GBL19xx
HBL16xx
HBL23xx (non-A version)
HDC24xx (the series Burgerman and I have been using)
LDC14xx
MBL1xxx (non-A version)
MDC1xxx (non-A version)
MDC2xxx
XDC2xxx
SBL13xx (non-A version)
SBL23xx (but see spec sheet for situations in which estimated motor current is said to be accurate)
SB43xx
SDC21xx
VSX18xx
VBL16xx
VBL23xx
VDC24xx
Note: a few of these say that they have "real time" battery amp measurement and that this gives accurate motor current estimates, but
I don't know what this means. Talk with me about what CurrentSensor setting to use if you have one of these.

Once again, I'd like to thank Vitolds for telling me about this!

[woodygb]

Lenny ..Is there anyway to poll/query the Roboteq for it's I.D. / Build and incorporate the answer (has or has not sensors ) into the script?

[LROBBINS]

I don't know, but I'll try to find out. I can also easily write something to find out whether functional external sensors are installed. So, if I can do both the choice of how to read motor amps could be automated. First goal, however, is to create the three choices: external, internal or none.

[LROBBINS]

Woody,

I've searched through the Roboteq manuals (they've now separated stuff into separate manuals: Roboteq Controllers User Manual v2.0, MicroBasic Scripting Manual, CAN Networking Manual and Roborun+ Utility User Manual). There is a command that returns identifying information:

TRN - Read Control Unit type and Controller Model
...
Example:
Q: ?TRN
R:TRN=RCB500:HDC2460

but it returns a string and MicroBasic has no string manipulation or comparison ability so I don't know how I'd parse it into anything usable in a script. So, I'll just let your idea percolate for a bit without doing anything about it.

[LROBBINS]

NEW UPLOAD TO GOOGLE DRIVE

Testing went smoothly and I've uploaded the new files to GoogleDrive. The link is still https://drive.google.com/open?id=1ysOoYG8mwlvJy0023XwJUgclYXbO1ulS

Instead of UseCurrentSensors, the scripts now have:
'******************************************************************************************************
CurrentSensors = internal 'choices are internal, external or none
'If you have added two external motor current sensors, you can use "external". Brushless controllers can not
'have these, so DO NOT SET "external" for brushless controllers.

'If your controller does have internal motor current sensors (at the moment, only some controllers have this) set this to
'"internal" unless using brushed motors and prefer to use external sensors.

'If your controller does not have internal motor current sensors, and you do not have external sensors, set this to "none".
'******************************************************************************************************

I have also changed what happens if you've set CurrentSensors = external and there's a sensor fault.

If there's a fault at startup, there will now be NO motor compensation at all. You will be able to limp home, but the chair will behave badly indeed. This will also happen if you set CurrentSensors=external, but there aren't any sensors (a little extra protection for you brushless folks).

If there's a fault after startup, while the chair is running, MotorCompensation will use the motor current values returned by the Roboteq. If the controller actually has internal sensors, Motor Compensation will be OK. If the controller just gives estimated motor current, motor compensation will be poor at low PWM.

DO NOT SET CurrentSensors=none UNLESS YOU ARE SURE THAT YOUR CONTROLLER DOES NOT HAVE BUILT-IN MOTOR CURRENT SENSORS. If you set "none" and there are built-in sensors you may get unstable behavior if CompTurnBoost is greater than 0. (Start with CompTurnBoost = 0 and be cautious increasing it in any case.)

[Vitolds]

I wanted to point out another setting of brushless motors.
Before you download the script, configure your motors and rotate in the program RoboRun.
This parameter is very important. Configure it like your motors (each motor).
Then calibrate the diagnostics tab (see manual)
Only then do the settings in the script.

[LROBBINS]

Vitolds is quite correct - at least if you are using sinusoidal mode! I don't know if a seek routine is actually run if in plain Hall-effect controlled trapezoidal.

[LROBBINS]

Minor change. I have changed the response to an external sensor failure at startup in the CAN version. Because the CAN system already posts a fault message to Display, I have now set it to just use CurrentSensors = internal if you had set it to external but there's a sensor failure. That will give good motor compensation if it's one of the newer controllers, and poorish compensation if it's an older one, but it, in any case, be easier to drive than with Motor Compensation completely turned off.

For the analog script things remain the same. There's no on-screen warning message, so the only way to know that there's been a sensor failure is from a change in chair behavior.

[LROBBINS]

It's me again. I think I've figured out a way to know whether a controller's motor amps is the "old" poor estimate or a "new" accurate measure and automate the CurrentSensors value without knowing what controller is involved. Here's a pseudo version of a MicroBasic subroutine to run during startup (i.e. before MainLoop):

Code: Select all

SET_CURRENTSENSORS:
  CurrentSensors = external
  GoSub STARTUP_SENSOR_CHECK (existing subroutine that detects missing or failed external current sensors)
  Set brakes (just in case)
  Throttle = 10 (1% of full throttle - I hope enough to show some motor current with the new controllers but not enough to give anything in the old ones even though stalled)
  ILeft = GetValue (_A, 1) (motor 1 current)
  IF ILeft > 0 THEN
    controller has internal (or otherwise accurate-at-low-current) motor current measures
    IF (external sensor fail or absent)
      CurrentSensors = internal (use "raw" estimated motor currents)
    END IF
  ELSE
    IF (external sensor fail or absent)
      CurrentSensors = none (use "enhanced" estimated motor currents)
    END IF
  END IF
  Throttle = 0
  Release brakes
  Return

The only problem I can think of offhand is that there'll be little or no change in driving feel if there are failed current sensors at startup, which is not a problem in the CAN system because there will be a fault message on Display, but might be a problem with the analog only version.

Any thoughts?

Vitolds, if I go ahead with this I'll need a bit of help from you since you do have one of the newer style controllers. I put Throttle = 10 in the above just guessing that this would show some motor current with a controller that has internal sensors, but I don't actually know this. Could you do the following:
(1) motors connected
(2) no script running
(3) set Roborun graph to show Motor Amps and Motor Control
(4) move slider to find minimum Motor Control that gives >0 in MotorAmps (SET_CURRENTSENSORS needs to set Throttle > this, but less than what's needed to give MotorAmps>0 in the older controllers)

[Burgerman]

The only problem I can think of offhand is that there'll be little or no change in driving feel if there are failed current sensors at startup, which is not a problem in the CAN system because there will be a fault message on Display, but might be a problem with the analog only version.

If its not working, it will be EXTREMELY obvious, withing the first 12 inches of movement. So no worries. If its not extremely obvious its not set correctly or its not working to start with.

[Vitolds]

Lenny is no problem.
Only after 2-3 days.
I will put everything on the table and any tests will be possible.
But tests in motion will not be useful to you. I have powerful motors and gearboxes powerful.

[Vitolds]

I observed that the motor current is always displayed, even when the throttle stick is zero.
0,1 - 0,2
something like this

[LROBBINS]

If its not working, it will be EXTREMELY obvious, withing the first 12 inches of movement.

That's true for controllers that don't have internal sensors (like our HDC24xx) without my improved estimation routine (you've not yet tested that on a chair - just on the bot with an extreme power to weight ratio), but certainly won't be true on controllers that already have built in motor current sensors that really don't have any need for separate sensors in any case. The difference is also quite subtle in Rachi's chair with the enhanced estimation vs. using the external sensors.

[Williamclark77]

Vitolds is quite correct - at least if you are using sinusoidal mode! I don't know if a seek routine is actually run if in plain Hall-effect controlled trapezoidal.

This does not apply to hall and trapezoidal.

[Vitolds]

correctly
but sinusoidal mode is better.

[Williamclark77]

Vitolds, what type of encoders are you using? Sin/Cos, absolute, optical? Mine are optical and connected to the sin/cos or encoder pins in the 25 pin connector.

[Vitolds]

hall sensors

[LROBBINS]

With just 3 Hall sensors sinusoidal/FOC is essentially trapezoidal at low RPM. FOC will improve efficiency and give increased torque (once RPM has increased), but it will not prevent shuddering at low RPM. You may not notice the shuddering when starting out because your high-reduction gearbox means that the motor is quickly at higher RPM, but Will already knows that trapezoidal makes starting up pretty noisy in his Will2.

BTW-I see that I missed seeing your message about motor amps > 0 even at 0 power. Thanks. That means that my "internal sensor" detection scheme can use an even lower detection level than the 1% power I'd guessed at. Better for those who don't have brakes as at low enough power the chair won't move anyway.

Ciao,
Lenny

[Vitolds]

Lenny, you're right.
But I would say in another way, "not low speed" but "at the start of the engine."
The trapezoid mode is noisy, but I see in Roborun that the trapezoid mode is less than the peak current. A lot less.
What do you mean "no brakes"?

[Williamclark77]

What do you mean "no brakes"?

Mechanical parking brakes.

The trapezoidal noise is unnoticeable until you're in a very quiet place like a library, funeral home, or hospital hallway trying to be hidden. Then it sounds like a coffee grinder!

[Vitolds]

No Lenny, the noise is very loud. The difference between the modes is big.
Although probably it all depends on the power of the motors.
I do not understand here is this phrase

Better for those who don't have brakes as at low enough power the chair won't move anyway.

Do you mean that the chair will not slide down the hill if the brake does not turn on?

[LROBBINS]

No, without brakes it definitely will slide down a hill. What I meant by this specifically refers to the routine for automatic setting of CurrentSensors.

It starts with "external" as its default, then if there are no external sensors (or if there's a faulty external sensor) it applies a small throttle value and from the value of Roboteq motor amps decides whether to switch to CurrentSensors = internal (if the controller, like yours, has them) or CurrentSensors = none (in which case it uses my enhanced estimation subroutine). It then sets throttle back to zero. If there are no brakes, the chair might move for the few milliseconds that throttle is > 0; the smaller the value of throttle, the less likely the movement.

So far, I've written a draft auto current sensors script for the CAN system (because it's easier for me to test it there) and it's working nicely except that I have some bugs in showing the sensor fault message on the Display screen - it shows, then disappears. I know what causes that, but haven't gotten around to fixing it yet. I also have to remove CurrentSensors from the Programmer's user settings since it's now automatic.

It does not display a sensor fault message during startup, but that's as intended, because if there really aren't any external sensors not having them isn't an error. In my system I do have an audible warning if external sensors are faulty or absent during startup - in that case, the contactor relay clicks on and off while it's deciding whether to use "internal" or "none".

The CAN system does display and log fault messages if a fault is detected while running - and just uses whatever motor current the Roboteq gives (without enhancements).

[LROBBINS]

Vitolds,

You said that you show a tiny motor current even when motor power is zero. I assume that this is the noise level of the sensors, and I'd rather make decisions based on a value a little bigger than that because different controllers might have different noise level readings. What motor amps do you see in the Roborun Run tab text box if you set MotorCommand to 5, 10 and 15?

[Vitolds]

I need a couple of days

[Vitolds]

Lenny is 0 - 5 - 10 - 15 commands the motor
Motors without gear.

[LROBBINS]

Great and THANKS. Looks like MotorCommand = 5 (1/2% of full PWM) gives a quite definite motor current with the internal sensors. On controllers that estimate from battery amps, this will be solidly 0 whether motor command is 5 or 10 or 15. Doing the automation test at MotorCommand = 10 will give lots of margin, and I doubt that any chair will actually move with that little power. (The test lasts only milliseconds, so being stalled isn't a worry.)

Some controllers now say that

Including Amps sensors on the wires allows for fast and efficient collection of information. Battery amps can be measured in real time and which allows precise calculation of motor amps.

, but what does that mean? Perhaps they are "precise" once battery amps is measurable - which will still give a solid 0 at motor command = 5 or 10 or 15 because battery amps will be 0, or perhaps they will be "precise" down to much lower battery currents, in which case they'll behave like having internal sensors. My code will, in any case, handle these as well, using my "enhanced" estimates if the first meaning is correct, and "internal" for the second interpretation of what Roboteq says.

I'm almost ready to upload new files, but am waiting for Rachi to get home this evening to run some final tests in the real chair.

Thank you Woody and Mike Stewart for independently suggesting automation of the CurrentSensor setting, and Vitolds for telling us about the new controllers and getting me these data.

[Williamclark77]

Vitolds, if I go ahead with this I'll need a bit of help from you since you do have one of the newer style controllers. I put Throttle = 10 in the above just guessing that this would show some motor current with a controller that has internal sensors, but I don't actually know this. Could you do the following:
(1) motors connected
(2) no script running
(3) set Roborun graph to show Motor Amps and Motor Control
(4) move slider to find minimum Motor Control that gives >0 in MotorAmps (SET_CURRENTSENSORS needs to set Throttle > this, but less than what's needed to give MotorAmps>0 in the older controllers)

Lenny, see video here: https://www.willsjunk.com/WillChair-3/n-LLLZxT/i-RNZXNt2/A

This is powering on, the startup seek routine, no input to show motor amp noise, input by x5 amounts until the motors start turning, full throttle, then return to zero so you can see the noise. I included the encoder counts to show when the motors actually started turning. No script. This is fully assembled with my very new, very tight gearboxes.

Vitolds is quite correct - at least if you are using sinusoidal mode! I don't know if a seek routine is actually run if in plain Hall-effect controlled trapezoidal.

The seek routine is only done once at initial setup and does not run at every power up with hall sensors or other absolute positioning hardware. It only does with incremental encoders.