Menu

Topic-icon NEW RELEASE: Wheelchair multi-node CANbus and analog hardware and software

  • Gabriel_Isko
  • Gabriel_Isko's Avatar
11 months 2 weeks ago #29534362 by Gabriel_Isko
Thanks Lenny! This will make it much easier for me to collaborate on. Drop me a line if you ever need help supporting it and I will see what I can do.

Please Log in or Create an account to join the conversation.

More
3 months 3 weeks ago - 3 months 3 weeks ago #29534733 by LROBBINS
x
*********************************************
CRITICALLY IMPORTANT WARNING!
*********************************************

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 one-per-motor external sensors so you MUST set "UseCurrentSensors = FALSE".

(2) The "FindEstimatedCurrents:" subroutine improves IR motor compensation for controllers that ESTIMATE motor current from battery current sensors. If your controller has built-in 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:
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!

PLEASE NOTE: At Gabriel Isko's request I set up a Github repository to make collaboration easier. However, no one has contributed there while many have downloaded the files from Google Drive and there has been a lot of feedback at WheelchairDriver.com and/or by e-mail. Having tired of trying to synchronize two separate repositories, I have deleted the one on Github. The latest files are available at: Wheelchair CANbus Controller . Any and all feedback is most welcome, and any testing observations you make are really important. You can contact me either here, or on the WheelchairDriver forums, or by e-mail.

Please Log in or Create an account to join the conversation.

More
3 months 3 weeks ago #29534734 by LROBBINS
I have now looked at all of the current data sheets and see that many, not just "some", controllers now have internal motor current sensors. I have therefore made re-writing my code to take this into account my highest priority, and should have an update posted soon.

However, in some of the data sheets I see:

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.

Can someone explain what this means? Does it mean that motor current estimates for controllers that measure "real time" battery current are accurate at less than 20% PWM? In that case, my scripts will have to treat these controllers the same way as those with internal sensors.

Please Log in or Create an account to join the conversation.

More
2 months 3 weeks ago #29534754 by dttrusko
HI - New to the forum and RoboteQ. I am working with a HDC2460S for my application and would like to read through the documentation for your wheelchair, but the google drive links send me right to "Error 404 (Not Found)". Would you be able to post an updated link? Thank you!

Please Log in or Create an account to join the conversation.

More
2 months 3 weeks ago #29534755 by LROBBINS
Please have a little patience as I'll be posting a major update within the next few days (and I'll post a fresh link). The new script includes automated selection of external motor current sensors, internal motor current sensors (for controllers that have them) or my "enhanced" motor current estimation, plus an automated check and correction of current sensor polarity and detection of sensor faults with motors quiet and while running.
The following user(s) said Thank You: dttrusko

Please Log in or Create an account to join the conversation.

More
2 months 3 weeks ago #29534758 by LROBBINS
I got the new files uploaded to Google Drive faster than I'd expected, so here's the link:

drive.google.com/open?id=1ysOoYG8mwlvJy0023XwJUgclYXbO1ulS

FIRST, the usual warning. The CANbus version has been tested on the bench and on the chair. The analog version has had only minimal testing, so do be cautious.

At startup, the script now automatically checks for whether there are external motor current sensors and that they are working properly (the STARTUP_SENSOR_CHECK subroutine). Then, the AUTO_CURRENTSENSORS subroutine checks that the polarity of external sensors (if there are any) is right and corrects that if necessary, and checks for whether there are internal motor current sensors and chooses to use either those or my "enhanced" estimated motor current if there are not. The default user setting is CurrentSensors = external as all is handled automatically, and the only time you might want to set this to CurrentSensors = internal is if you have working external sensors but don't want to use them.

During the sensor checking, the motors are commanded to 10 (1% of max output) for about 50 milliseconds (shorter if accel is set higher than on Rachi's). On Rachi's chair, the script also disconnects the brakes during this, so it certainly can't move, but at motor power = 10 it probably won't move even without brakes in 50 milliseconds. Took me a while to figure out how to do it, but the script avoids any brake clicking during all this. I also cleaned up how the script removes any drift or offset of sensor zero point. I'd been doing it by reading the sensors once every ca. 5 seconds when the chair is not moving, calculating offsets, and subtracting them every time sensor current was read. The CheckSensorZero: subroutine now uses the Roboteq SetConfig (_ACTR ...) command to re-configure the zero point to actual reading, so no subtracting offsets is needed elsewhere. Uncertainty of the zero point between calls to CheckSensorZero is (2/1000)*100 <= 0.2 Amps, but usually actually zero or sometimes 1 (0.1 Motor amps).

Lastly, a note for those using brushless motors. I want to emphasize once again that Accel means different things in Roboteqese for brushed and brushless controllers. For brushed motor controllers it is change of PWM per second rather than actual change of RPM per second. The chair's actual physical acceleration is greatly dependent on inertia. Hence a heavy bloke in a heavy chair who likes sharp accel and decel will need much higher Accel and Decel values than a pipsqueek like my daughter.

For brushless controllers, accel is change of RPM per second (commutation frequency) and the only time you won't get that much physical acceleration is if the current limit of the controller has been reached. Hence, inertia has much less effect. An acceleration value that Pinco Pallino likes on a brushed-motor controller could well be a rubber-burning experience with brushless. Please be cautious.

All feedback and suggestions would be most welcome.

Ciao,
Lenny

Please Log in or Create an account to join the conversation.

Moderators: tonysantoni
Time to create page: 0.125 seconds
Go to top