PINNED - Roboteq Controller - developing for powerchairs

[Vitolds]

MIX - 2
MotorCompensation: - reads only the motor current

Disabled

Code: Select all

  IF AccelBoost > 1 THEN
'    GoSub TurnMix
'    GoSub CompMix
  END IF
'    GoSub ThrottleCrossZero

youtu.be/SbWJPTNde34

[Vitolds]

Please tell me how to best film a video. What you need to see.

[LROBBINS]

Your first test with a script looks good. However, to be sure we are talking about the same things I've attached a modified version of my analog script. It's named "Open Loop 2025_09_19.mbs". This one does GoSub MotorCompensation and I've added some code to test whether averaging internal motor current has any effect.

I've added DIM CurrentAveragingCycles AS Integer, and in the UserSettings section I added:

Code: Select all

'number of reads for smoothing internal current sensor readings
CurrentAveragingCycles = 1


Notice that CurrentAveragingCycles = 1 means no averaging.

Internal motor current is only used in two places - both in MotorCompensation:. Those two places now read:

Code: Select all

'    ILeft = GetValue (_A, 1)
'    IRight = GetValue (_A, 2)
    GoSub SmoothedInternalCurrents


and the SmoothedInternalCurrents subroutine is:

Code: Select all

SmoothedInternalCurrents:
  DIM SumILeft AS Integer
  DIM SumIRight AS Integer
  SumILeft = 0
  SumIRight = 0
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumILeft = SumILeft + GetValue (_A, 1)
  NEXT
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumIRight = SumIRight + GetValue (_A, 2)
  NEXT
  ILeft = SumILeft/CurrentAveragingCycles
  IRight = SumIRight/CurrentAveragingCycles
RETURN 'SmoothedInternalCurrents


Before using this, please make sure that the parameter values in the UserSettings section in this script are the same as the ones you have in the script you have been using. (BTW opening 2 instances of Roborun as narrow windows is handy for comparing scripts) If you make any changes, save this with a new name!

IMPORTANT: I have not tested this script with actual hardware (my hardware is only CANbus). It does build OK, but do be cautious!

I think that the most meaningful thing to film is the Run tab with this:

Set Refresh Rate to 5 msec.

If your setup works OK, you can then change CurrentAveragingCycles to 15 to see if that makes any difference at all. Save this with a new name! This will not show up in the graph because the Run tab sees only the raw MotorAmps and not the averaged values. So for this you have to use your ears and your hands to tell whether the motor moves more smoothly. But from the graphs you will be able to see if doing the averaging makes the system respond more slowly to joystick changes.

[Vitolds]

I'll do it now - 15 minutes.

[Vitolds]

Lenny, tell me, do I need to use your entire script or can I add the SmoothedInternalCurrents: block to mine and test it?
Is everything else in the script important?
I see that it doesn't matter, the test is only for current readings. Correct?

[Vitolds]

In my script, I removed everything unnecessary; it was simpler that way.

[Vitolds]

I changed it (ForeAftPower)

Code: Select all

 DIM ForeAftPower AS Integer
'   ForeAftPower = (abs(GetValue(_MOTPWR,1)+GetValue(_MOTPWR,2)))/2
   ForeAftPower = (abs(GetValue(_BSR,1)+GetValue(_BSR,2)))/2   
   DIM ExtraComp AS Integer
   IF (abs(Steering)>1) AND (ForeAftPower<TurnBoostLimit) THEN
     ExtraComp = 1
   ELSE
     ExtraComp = 0
   END IF

Here is my code

Code: Select all

MotorCompensation:
  DIM M1 AS Integer
  DIM M2 AS Integer
  DIM BattVolts AS Integer
  DIM M1Comp AS Integer
  DIM M2Comp AS Integer
  DIM M1Speed AS Integer
  DIM M2Speed AS Integer
  DIM SumILeft AS Integer
  DIM SumIRight AS Integer
  SumILeft = 0
  SumIRight = 0

  M1Speed = GetValue (_BSR, 1) 'Min: -1000 Max: 1000
  M2Speed = GetValue (_BSR, 2)   
  BattILeft = GetValue (_BATAMPS,1)
  BattIRight = GetValue (_BATAMPS,2)
  M1Power = GetValue (_MOTPWR, 1) ' фактический уровень ШИМ. Min: -1000 Max: 1000
  M2Power = GetValue (_MOTPWR, 2) ' Syntax Scripting: = getvalue(_P, cc)
'get motor current values in accord with sensor setting 
'  ILeft = GetValue (_A, 1) 'estimated current in units of deciAMPS = 10X Amps for left motor (1 unit = 100 mA)
'  IRight = GetValue (_A, 2) 'estimated current in units of deciAMPS = 10X Amps for right motor (1 unit = 100 mA)

  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumILeft = SumILeft + GetValue (_A, 1)
  NEXT
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumIRight = SumIRight + GetValue (_A, 2)
  NEXT
  ILeft = SumILeft/CurrentAveragingCycles
  IRight = SumIRight/CurrentAveragingCycles
   
'  do mixing to find motor values (DO NOT TRUNCATE - will be un-mixing later)
   M1 = Throttle + Steering
   M2 = Throttle - Steering
 'apply IR compensation; everything converted from volts to 0-1000 joystick units and *100/10 used to reduce granularity
   M1Comp = 0
   M2Comp = 0
   BattVolts = GetValue (_V, 2)
 
   DIM ForeAftPower AS Integer
'   ForeAftPower = (abs(GetValue(_MOTPWR,1)+GetValue(_MOTPWR,2)))/2
   ForeAftPower = (abs(GetValue(_BSR,1)+GetValue(_BSR,2)))/2
   DIM ExtraComp AS Integer
   IF (abs(Steering)>1) AND (ForeAftPower<TurnBoostLimit) THEN
     ExtraComp = 1
   ELSE
     ExtraComp = 0
   END IF 
 'Calculate mean back EMF as IR and motor compensation as percent (back EMF/BattVolts)
   M1Comp = (ILeft*(MotorResistance+CompTurnBoost*ExtraComp))/BattVolts
   M2Comp = (IRight*(MotorResistance+CompTurnBoost*ExtraComp))/BattVolts
  'modify motor command values in accord with motor compensation
   M1 = M1 + M1Comp
   M2 = M2 + M2Comp
  'undo mixing to get back new THROTTLE and STEER values
   Throttle = (M1 + M2)/2
   Steering = (M1 - M2)/2
  'truncate in case compensation pushed THROTTLE and/or STEER over maximum of +/- 1000
   IF (Throttle > 1000) THEN
     Throttle = 1000
   END IF
   IF (Throttle < -1000) THEN
     Throttle = -1000
   END IF
   IF (Steering > 1000) THEN
     Steering = 1000
   END IF
   IF (Steering < -1000) THEN
     Steering = -1000
   END IF
         PRINT ("   M1Comp     ", M1Comp ,    "    M2Comp     " ,  M2Comp ,"\n")   
         PRINT ("   Speed =    ", Speed,      "    Turn =     " ,  Turn, "\n")
         PRINT ("   THROTTLE = ", Throttle,   "    STEERING = " ,  Steering, "\n")
         PRINT ("   ILeft      ", ILeft ,     "    IRight     " ,  IRight ,"\n")      
       PRINT (" \n") 
       
RETURN 'End of "MotorCompensation:"

Speed end Turn I take it here

Code: Select all

ScaleThrottle:
  DIM PercentThrottle AS Integer
  PercentThrottle = abs(Throttle*100)/1000 ' used in MixAccel
  Throttle = (SpeedPot*Throttle)/100
'      PRINT ("THROTTLE/STEER scaled Throttle = " , Throttle , "     ")
  Speed = Throttle
RETURN 'End of "ScaleThrottle:"

ScaleSteering:
  DIM RelSpeed AS Integer
  DIM TurnReduction AS Integer
  Steering = (TurnPot*Steering)/100
  IF (Throttle < 0) THEN
    RelSpeed = (Throttle*100)/-1000
  ELSE
    RelSpeed = (Throttle*100)/1000
  END IF
  TurnReduction = (RelSpeed*(100-TurnAtFullSpeed))/100
  Steering = ((100-TurnReduction)*Steering)/100
'    PRINT ("THROTTLE/STEER scaled Steering = " , Steering , "\n")
  Turn = Steering 
RETURN 'End of "ScaleSteering:"

[Vitolds]

Lenny, something's not right here.

Code: Select all

SumILeft = 0
  SumIRight = 0
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumILeft = SumILeft + GetValue (_A, 1)
  NEXT
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumIRight = SumIRight + GetValue (_A, 2)
  NEXT
  ILeft = SumILeft/CurrentAveragingCycles
  IRight = SumIRight/CurrentAveragingCycles

[LROBBINS]

Dear Vitolds,

This is probably going to be a long email because I want to try to explain why what you had in the last few messages is very different from what I want you to do. Please be patient, especially since I got next to no sleep tonight and am also very busy with other things.

First, you are correct that only MotorCompensation uses motor current, but TurnMix uses MotorCompensation and MotorPower so indirectly it is also using motor current.

Second, and very important. You wrote that:

Code: Select all

In my script, I removed everything unnecessary; it was simpler that way.

Please, please DO NOT DO THAT. What you need to do now is start with something that you know works, and then make only one change at a time and test. The script I sent you yesterday has only one change, the added routine for internal sensor current averaging, from a script that we know works for brushed or brushless motors, with external current sensors, without current sensors using enhanced estimated current for controllers that don't have internal sensors, and for controllers with internal sensors. If you make other changes and something doesn't work, you won't know what didn't work. You will also have a script that may work only for your chair, but not for others. We should not do that. We need to have a script that will work in as many systems as possible. Most users don't know programming, and if someone tries to use a script designed for a specific chair they may be in big trouble. PLEASE test the script I sent you first with no other changes.

Now, I'll talk about some of the specific changes you made.

1-You moved

Code: Select all

  SumILeft = 0
  SumIRight = 0


from the SmoothedInternalCurrents subroutine to the beginning of MotorCompensation. This will work, but it is wasteful. These variables are only needed when using internal sensors, but my moving these lines they will always bbe reset to 0 at every loop cycle whether using external, estimated or internal currents. If they are in SmoothedInternalCurrents:, this little calculation will be done only when it is needed.

2-You wrote

Speed end Turn I take it here

but I don't see Speed end Turn anywhere in the piece of code in the message.

3-

I changed it (ForeAftPower)

This is a change that might cause problems! _MOTPWR and _BSR measure two different things. _MOTPWR is what the Roboteq calculates and sends (after further processing) to the motor. _BSR is the speed of the motor itself read from whatever sensors are being used. We KNOW that _MOTPWR works. _BSR might also work, or might even work better, but we don't know that. This is something that you should test later, not now.

4-

Lenny, something's not right here.

What do you think is not right here? Maybe my mind is too tired to see the problem, but I don't. This is a place where some print statements may help me understand what you mean, and to help us fix the problem if there is one. So this is a good point to talk about PRINT.

PRINT STATEMENTS
Commenting out, adding, or even deleting print statements is one change that I'm certain will not effect motor control. The printed text is not even visible unless you run a separate serial monitor at the same time as you run the Roboteq, but they can be very helpful for diagnosing problems, so I think you should leave them for now and probably even add some. If you have a serial monitor program you like to use, just set it to connect to the same serial port as the Roboteq. You can even use Arduino serial monitor with no Arduino board. I like one CtrlTerm.exe that was written (by someone else, not by me) in Pascal, but it is too large to attach here. If you want a copy, let me know and I'll share it on Drive.

So, turning back to SmoothedInternalCurrents:, you can add some print lines like this:

Code: Select all

SmoothedInternalCurrents:
  DIM SumILeft AS Integer
  DIM SumIRight AS Integer
  SumILeft = 0
  SumIRight = 0
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumILeft = SumILeft + GetValue (_A, 1)
  NEXT
  FOR i = 1 AndWhile (CurrentAveragingCycles)
    SumIRight = SumIRight + GetValue (_A, 2)
  NEXT
  ILeft = SumILeft/CurrentAveragingCycles
  IRight = SumIRight/CurrentAveragingCycles
  PRINT ("\n SumI: ",i,"  ",SumILeft, "  ",SumIRight,"\n")
  PRINT ("\n AvgI:     ",ILeft, "  ",IRight,"\n")
RETURN 'SmoothedInternalCurrents

Now, run a serial monitor at the same time as the Roboteq script. With CurrentAveragingCycles = 1, the the SumI and AvgI values should be the same. When, later on, you test with more averaging cycles, the difference between Sum and Avg values should be obvious.

If I find some free time later today, I'll send another email with some suggestions for making using Roborun less tedious. However, I am going to be extremely busy in the next few days and I may not be back to this until late on Tuesday,

Ciao,
Lenny

[LROBBINS]

My next chore for today has been delayed, so I'll add this note now. I probably won't be back at this topic again until late on Tuesday.

SOME SUGGESTIONS FOR USING ROBORUN IN WAYS THAT SAVE YOUR TIME AND GIVE YOU GOOD BACKUPS

Both the Script and Configuration profile are written to non-volatile memory in the controller. They stay stable for many months. Unless you have changed something, there's no need to download the script or send the configuration to the controller.

If you make a change in the script or in the configuration, you should save them with new names. In the script tag, do Save As and give the file a new name such as "Open Loop today's date" (and if it's the second time you are saving on the same day, "Open Loop 2025_09_19 2" and so on). In the configuration tab, use Save Profile to Disk and give it a new name such as "Open Loop Profile today's date" etc. If you do this, you have both a backup and a record of the changes you've made so you can easily go back to an earlier version if a change turns out to be bad. To do that, use Load Profile from Disk or the Open icon button for the script. There is no need to be constantly adjusting configuration items.

"Load from Controller" is of very limited use. It is not a way of checking whether the profile was written to the controller correctly unless you look at every one of the settings. When Roborun is open and the controller is powered up, Roborun will ask you whether you want to read the configuration from the controller. If you answer "Yes", that is exactly the same as "Load from Controller", so you don't need to use "Load from Controller" even then. I know of only one situation where "Load from Controller" is useful. Saying "Yes" to the do you want to read the configuration quesion is time consuming. Thus, if you are turning the controller on and off several times, you can say "No" and later do "Load from Controller" only if you need to look at the configuration values. Saves a lot of time.

You do not need to re-run the Motor Characterization items in the Run tab nor in the Configuration tab each time you change the script unless the motors (wiring, lubrication, bearings etc.) have changed. Do it once and save the configuration as a new Profile file.

Getting in the habit of doing things this way will not only save time, but it will reduce the chance of making mistakes (and you'll always have a backup in your PC).

[Vitolds]

Google Translate translates your text into Russian perfectly. The translator probably knows you. :-)
I try to write correctly for the translator, but the translator, working with artificial intelligence, makes changes, and it turns out poorly. I can see this from your messages. I will continue to try to write correctly.
I'll beg to differ.

1. A clean script allows you to test the chair's movement in different modes. It’s difficult for me to see the whole script and work with it, it’s big.
To test the motor's operation, the following checks are not required:
- POT, speed check for malfunctions
- Current sensor calibration
- Contactor activation
- Battery check
- Parking brake activation (I don't have a brake)
I understand very well that all these functions are necessary and they should be included in the script. But at this stage it is distracting and complicating (it is very difficult for me and I get confused).
I understand that the script must work in a wheelchair and must be suitable for different chairs. I understand that BLDC motors will not be used in wheelchairs and I also understand that the use of Hall sensors or encoders will not be in a wheelchair. The new controllers have internal current sensors, so using external ones is questionable. But we need to use external current sensors in the scenario; our controllers are old. We need to see what's going on.
In my tests, I can give you feedback (Hall sensors) you didn't have. You didn't know what your motors were doing. Current sensor readings aren't enough.
Example:
I noticed a difference in the motor speed. The difference was as much as 400 rpm. The motors are identical, new.
I noticed a difference in the motor current readings. The difference is significant. I haven't yet figured out who's to blame.
All of this affects the chair's control.
I understand that these problems cannot be fixed, but we must be aware of them.

2. Script error checking should be done in its entirety, I completely agree with you. I shouldn't be using my hall sensors in the script; everything should be as if I were in a wheelchair. I understand that. This applies to script error checking.

3. An important part of the scenario is motor compensation. I saw something strange going on there. I started checking the current sensors. That's how we got to this conversation.
The motor compensation was intended to improve the chair's ability to turn on the spot (right?), but I see that the motor compensation is working more and constantly when moving forward. This is without any load on the motors. I thought the "noise" from the current sensors was affecting this, but now I'm not sure. It turns out that the chair always moves with motor compensation, even when it is not needed.
You might have noticed all this if you disconnected the gearbox and left only the motor. But I don't think anyone has done that. Chairs have different gearboxes and motors, and their behavior can vary greatly. I have been telling you about this feature for a long time, I have powerful motors and powerful gearboxes. This cannot be fixed by user settings.
Maybe I'm wrong, maybe I did something wrong with the script. I'll collect more tests by Tuesday.

[JMGarage]

I see Vitolds point and agree that we have simple as possible script for testing.
This current script is huge and needs a lot for understanding. It would be good to cut in blocks.
For these new controllers it might be better to rewrite code by piece by piece. Then we have better learning curve, when we start from beginning and learn one block once. When all works, then we can add safety features and test.
Especially who uses theses BLDC-motors.

First just to work without script by controller.
Then we take only parts for steering and speed to script. Of course there is danger for testing and runaway could occur or something odd.
I tested my STO e-stop feature and it worked on bench fine.

[Vitolds]

Lenny look at this.

original

Code: Select all

 'Calculate mean back EMF as IR and motor compensation as percent (back EMF/BattVolts)
   M1Comp = (ILeft*(MotorResistance+CompTurnBoost*ExtraComp))/BattVolts
   M2Comp = (IRight*(MotorResistance+CompTurnBoost*ExtraComp))/BattVolts

changes

Code: Select all

 'Calculate mean back EMF as IR and motor compensation as percent (back EMF/BattVolts)
   M1Comp = (ILeft*((MotorResistance+CompTurnBoost)*ExtraComp))/BattVolts
   M2Comp = (IRight*((MotorResistance+CompTurnBoost)*ExtraComp))/BattVolts

[Vitolds]

The motor compensation now works as you intended.

[Williamclark77]

Most of the bugs in the rest of the script had been worked out years ago by Lenny with his daughter's chair, BM with his chair and robot, and a few other users with brushed motors. It works with brushed motors and brushed controllers.

What Lenny is helping with now is specifically for brushless motors and newer controllers to integrate properly with the working brushed script. Removing already working code and starting over is too much to ask for, especially when he has no personal reason to and no hardware to test with.

Test should be done as requested to avoid confusion and extra work so we can create one master script for all.

I can test as needed on my working brushless setups as time allows to help. I don't have much free time. Mine do not work perfect but have been in hard daily use for over a decade. I'm used to their bugs.

I am, admittely, not the greatest tester!

[Vitolds]

Will, I disagree. It doesn't matter what engines. It's math.

[Vitolds]

The problem was that Lenny wrote the code alone, and no one could check it. Code checking consisted of human perceptions (whether it works or not). Almost no one understood what was going on inside the script. People make mistakes, that's normal. Lenny did a great job, but even a professional's work needs to be checked.

[JMGarage]

I don't ask to do new code for a new controllers. Just guide and simply list what are the minimum. Then I test and try to get work code and learn.

First now I try to get work all basic setups in controller without script via joystick.
Then try to write code based on analog version.
When it works, then I'll move to can-bus version.
That would be mine goal. And just need guide and tips.

[LROBBINS]

Vitolds,

I have been reading everyone's post and didn't plan to respond until Tuesday evening or Wednesday when I'll have more free time, but the last coding change you posted is not only wrong BUT EXTREMELY DANGEROUS!

In MotorCompensation: the original script has:

Code: Select all

  M1Comp = (ILeft*(MotorResistance+CompTurnBoost*ExtraComp))/BattVolts

and you changed this, just moving a (, to:

Code: Select all

  M1Comp = (ILeft*(MotorResistance+(CompTurnBoost)*ExtraComp))/BattVolts

IR motor compensation is current*impedance In it's basic implementation this is just:

Code: Select all

M1Comp = ILeft*(MotorResistance)/BattVolts

But, impedance is not constant. It is lower when the motors just start to move, and higher after the chair is moving along. This because the frequency of motor pulses (PWM for brushed, commutation frequency for brushless) is lower at low speed, and higher as speed increases. To adjust for this we want to increase the calculation of impedance by some amount (that's ExtraComp) when starting movement with that addition going away as speed increases (ComTurnBoost goes from 100% to 0 as speed increases). Adjusting the value of ExtraComp is the last thing we do when tuning the chair, so for now CompTurnBoost = 0 in user settings.

First, what happens to M1Comp with the original code.

Code: Select all

'Before tuning and just starting movement, MotorResistance = 50 CompTurnBoost =100% and ExtraComp = 0
impedance = (50+1*0) = 50 milliOhms
'and when chair is moving
impedance = (50+0*0) = 50 milliOhms

so we have just basic motor compensation at all speeds.

Now, let's see what this does once we've tuned CompTurnBoost to a value of, for example, 20:

Code: Select all

'starting movement -
impedance = (50+1*20) = 70 milliOhms

-- impedance boosted from 50 to 70
'and when already moving -
impedance = (50+0*20) = 50 -- back to basic compensation when already moving[/code]
This is the way MotorCompensation should work!

Now, what will happen in your modified code with the ( moved?

Code: Select all

'Before tuning and just starting movement with MotorResistance = 50, CompTurnBoost = 0 and ExtraComp = 0
impedance = (50+(1))*0 = 0 milliOhms
'and when chair is moving
impedance = (50+(0))*0 = 0 milliOhms

so we have NO motor compensation at any speed.

Now, let's see what this does if we change ExtraComp to a tiny value of, for example, 1:

Code: Select all

'starting movement -
impedance = (50+(1))*1) = 51 milliOhms  '-- impedance slightly boosted from 50 to 51
'when already moving -
impedance = (50+(0))*1) = 50 '-- boost of MotorCompensation disappears when already moving< correct behavior

But now, what happens when CompTurnBoost is tuned to a reasonable value of 20:

Code: Select all

'starting movement -
impedance = (50+(1))*20) = 1020 milliOhms '-- RUNAWAY!
'when already moving -
impedance = (50+(0))*20) = 1000 '-- RUNAWAY!

YOU ARE RISKING YOUR SAFETY if you do this. And, if you do this in closed loop speed, you may not hurt yourself because the current will exceed the maximum allowed, but you will overheat the motors and controller and might even damage the controller.

[Vitolds]

Now I understand you better, Lenny.
I not only disagree with you, I categorically disagree with you.
I have been telling you for many years that something is wrong with Motorcompensation.
You say that motor compensation is assistance (amplification) for turning the chair in place. But in fact, motor compensation is always the addition of readings to the joystick, EVEN WHEN IT IS NOT NEEDED.
I have been telling you for many years that setting up a controller with a motor NOT CONNECTED TO THE GEARBOX - WHEELS - CHAIR shows completely different readings.
Take John and his wheelchair, for example.
Can you see the difference between John's wheelchair and a standard wheelchair? Yes, I can! But I'm sure you can't.
Take Will and his wheelchair, for example.
Can you see the difference? Yes, I can!
Take Rachi wheelchair, for example.
Can you see the difference? Yes, I can!
Wide wheels, a steel frame (heavy), extra equipment, voltage increase — and motors that aren't designed for that!
You bought a Mercedes 140 and installed a Renault Clio engine in a Mercedes. And you want it all to run smoothly with the help of motor compensation! And you're also relying on the readings of drivers of this Mercedes with a Renault engine.
You wrote a program for this Mercedes so that it could at least drive somehow and you offer it to Renault owners.
I don't understand how to run tests.
I don't understand what kind of wheelchair the program is written for (a standard chair or a custom chair).
I don't understand why I would buy a Roboteq for a wheelchair, do all this complicated setup, and end up with something worse than before.
The motor compensation program itself is correct, but its implementation is flawed. Motor compensation shouldn't work when it's not needed.

[Burgerman]

It doesent.
It literally does nothing.
It responds in direct proportion to load.

[LROBBINS]

Vitolds,

I do not appreciate the ill-tempered, ill-informed, almost entirely incorrect diatribe in your last posting. At first I was tempted to correct what you've written sentence by sentence, but then I wondered whether I should just not respond ata ll. Finally, I have decided to respond only to your statements about MotortCompensation.

You said that:

motor compensation is assistance (amplification) for turning the chair in place and that the motor compensation program itself is correct, but its implementation is flawed. But in fact, motor compensation is always the addition of readings to the joystick, EVEN WHEN IT IS NOT NEEDED.

MotorCompensation is not there for turning in place. MotorCompensation is there to give near constant speed with changing load. It is a classic method used for DC motors for more than 50 years. For turning in placeis CompTurnBoost is added.. The only difference between my script and what is done in an Rnet controller is that I call the user setting for this CompTurnBoost and PG calls it Torque. Given CompTurnBoost = 0 in the starting user settings, and only gets added during final tuning of the chair's parameters, turn-in-place is, for now, TOTALLY IRRELEVANT.

John (Burgerman) has alread replied, in a very abbreviated way, to the assertion that my script is adding reading to the joystick even when it is not needed. He wrote:
It doesent.
It literally does nothing.
It responds in direct proportion to load.
He is absolutely correct. The MotorCompensation: subroutine is called all the time, but the result of its calculations is not "always the addition of readings to the joystick". As you once said "it's only math", so here's a spreadsheet in which I've put some numbers and done the math to show the result of MotorCompensation: in a variety of situations

[LROBBINS]

Sorry, I hit Send when I meant to hit Preview. Here's the full message:

Vitolds,

I do not appreciate the ill-tempered, ill-informed, almost entirely incorrect diatribe in your last posting. At first I was tempted to correct what you've written sentence by sentence, but then I wondered whether I should just not respond at all. Finally, I have decided to respond only to your statements about MotortCompensation.

You said that:

motor compensation is assistance (amplification) for turning the chair in place and that the motor compensation program itself is correct, but its implementation is flawed. But in fact, motor compensation is always the addition of readings to the joystick, EVEN WHEN IT IS NOT NEEDED.

MotorCompensation is not there for turning in place. MotorCompensation is there to give near constant speed with changing load. It is a classic method used for DC motors for more than 50 years. For turning in place CompTurnBoost was added. The only difference between my script and what is done in an Rnet controller is that I called the user setting for this CompTurnBoost and PG calls it Torque. Given CompTurnBoost = 0 in the starting user settings, and will be 0 until you change it during final tuning of the chair's parameters, turn-in-place is, for now, TOTALLY IRRELEVANT.

You have repeatedly said that MotorCompensation makes your motors misbehave. I believe you. You first said this when you were trying to make closed-loop speed control work. In open loop you still say that MotorCompensation is causing motor action when it shouldn't. However, you have never done the one thing that would help us figure out why. You have never tested and graphed this with the complete script that works for Burgerman's heavy chairs with brushed motors and high voltage batteries, for Will's chair with brushless (Hall effct sensor) motors, and in Rachi's lightweight, all aluminum, chair with brushed motors and 24V batteries (or the "standard" chair she had before this one). You have always changed the script before doing your tests.

John (Burgerman) has already replied, in a very abbreviated way, to the assertion that my script is adding readings to the joystick even when it is not needed. He wrote:

It doesent.
It literally does nothing.
It responds in direct proportion to load.

He is absolutely correct. The MotorCompensation: subroutine is called all the time, but the result of its calculations is not "always the addition of readings to the joystick". As you once said "it's only math", so here's a spreadsheet in which I've put some numbers and done the math to show the result of MotorCompensation: in a variety of situations

With stick = 0 , "It literally does nothing."
With stick forward, but no external load, it does almost nothing.
In all situations, "It responds in direct proportion to load."

I have a suspicion of why your motors behave differently with and without MotorCompensation even when they shouldn't. But there's no use tryhing to deal with that until you test the script properly and show me, with graphs as well, what happens with and without MotorCompensation. (BTW, you don't have to change or comment out any code to get rid of MotorCompensation -- just set MotorResistance = 0 in user settings.)

If you now understand what Motor Compensation is and how it works, and are willing to do what I suggest, I am willing to continue trying to help. For example, I could show you how to navigate in the complete, long script, jumping right to the things you want to look at and ignoring, instead of removing, the parts that are irrelevant for your particular chair. Very little scrolling up and down, and doing this you wouldn't risk making changes that might mess up how it works. But writing that up precisely, with examples, carefully formatted, proofread and edited would be hours of work. If, however, you have decided, as your last message implies, that I am an idiot who doesn't understand wheelchairs and doesn't know what he's doing, BYE BYE.

[Vitolds]

I do not appreciate the ill-tempered, ill-informed, almost entirely incorrect diatribe in your last posting. At first I was tempted to correct what you've written sentence by sentence, but then I wondered whether I should just not respond at all. Finally, I have decided to respond only to your statements about MotortCompensation.

I'll answer briefly for now.
During all this testing, did John draw your attention to any script errors?
Errors that were quite serious.
Every time, I had to go to great lengths to prove to you that there was an error in the script.
Frankly, I'm fed up with this.
If you think John and many others will help you find the errors, let them try to find an error in the script directly related to the motor compensation.
I only test the chair's movement; I don't test the auxiliary components. I'm sure there are even more errors there.
I won't even mention the CAN system.
The errors I pointed out to you resulted in poor chair control. Where were your "testers" all this time?
All this applies ONLY to MISTAKES. Anyone can do them, even if they have your academic and well-deserved regalia.
There are many questions about HOW THE CHAIR WORKS, how it moves and stops.
But first, let your testers find the bug.
I have great respect for the work you have done, but I don’t need help with my chair.

[Vitolds]

For John personally.
John, I'll give you an example you'll definitely understand.
The nitrous oxide system on a drag car. Imagine it's always on and interacting directly with the gas pedal.
That's how the motor compensation works in your Roboteq controller. You can see all this if you disconnect the motors from the gearbox.
Put everything together on the table and you will see that the motor compensation always works, even when it is not needed.
If you can hook up speed sensors to the motors, I'm absolutely certain you'll see even more interesting things. You definitely won't like it.

[Burgerman]

The nitrous oxide system on a drag car. Imagine it's always on and interacting directly with the gas pedal.

In is.
And it does. Thats EXACTLY how it worked on mine. And on 2 wheels too.
On the car it is controlled (pulses at 25 cycles per second) as a pulsewidth and connected to the throttle.
On the bike it is the same, only here theres 2 stages, the 2nd one is applied only at times of low boost automatically. Its turnbocharged, so the nitrous fills in the low boost time before it spools up..

That's how the motor compensation works in your Roboteq controller.

No its not.
It SEES a current. And then it adds to that. No current (low load) low current added.

You can see all this if you disconnect the motors from the gearbox.

Because even a free running motor has SOME current - maybe 5A.
Thats correct. If its configured CORRECTLY it will add a small amount of additional torque (CURRENT) needed to run a motor. Its proportional. The whole point of it is to make the motor produce the same level of TORQUE not speed, regardlesss of load. Now just load ONE motor and it will continue to turn at the same speed as the other one.

So it responds to aceleration as well as deceleration. In deceleration it adds extra redardation as thats a negative load. It makes the chair respond at a predictable speed that is controlled by the joystick position and corrects this so that load (be that turning, ramp, hill, acceleration etc) does not change the speed.

Too lenny.

I have great respect for the work you have done, but I don’t need help with my chair.

Bye.

[Vitolds]

If, however, you have decided, as your last message implies, that I am an idiot who doesn't understand wheelchairs and doesn't know what he's doing, BYE BYE.

Lenny, my previous message was about work.
As for my personal feelings towards you, I don't think you're an idiot. Don't be like that. This does not paint a person in a good light. Work is work, but there's no need to get personal.
As a person who has worked in science, you understand very well what it means to do calculations on paper and test them in practice.

[Vitolds]

John, I know this theory.
But in practice, things aren't quite like that.
This only applies to this script and this controller.
I AGREE that this is how it should work!!!! But in the script, everything is wrong!
Find the error.

[Burgerman]

Works ABSOLUTELY as expected here. So pretty hard to find any error!

But I have not messed about with stuff I didnt usnderstand. I did thousands of hours of testings and helping lenny write that script long before you came along.

I even built this bot to safely test skid steer and to help develop that script. And as you can see it performs perfectly here. If I drive at 10% speed, and turn, then the speed stays exactly the same, even though it requires 10x as much current than it did to drive straight. Compensation performs perfectly. Turns, forwards, up a very steep ramp, braking, all exactly as it should.

It drives and steers EXACTLY the same, same stick feel, same control, regardless grass, loose gravel, carpets, wet, dry concrete or tarmac. Superb fine easy control.

Load or "power" required jumps up and down by 10x or more, as the compensation works in the background, while speed stays EXACTLY the same, at the same stick position. It just does as it is supposed to do. Requires zero stick skills.

Watch this very carefully. Its a small roboteq with the same script.

https://www.wheelchairdriver.com/gopro/bot.mp4

Comments?

[Vitolds]

John, not quite so. I've been seeing this for 11 years.
We've argued with you many times, John, but now it's enough to check the math.
Come on, John, you should be able to do it.