PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

My doctors are useless. Yes they will do that. But they use a simple solution thats cheap, not long enough, and not strong enough. All hey are doing is making bugs that are resistant... They need 2 or 3 different antibiotics at once. and a cont low level one to keep it at bay. All paraplegics have a low level of infection continually. But trying to discuss this with them is impossible.

Right now I feel crap and will stay on my bed till later tonight, see if I feel OK again.

Good find with the error!

[Burgerman]

Still I can watch 4K movies on the worlds best monitor from my bed! My ISP will go mental. I am currently downloading about 35 full UHD 3840 X 2160 HDR blueray movies at between 20GB to 85GB each! At around 90 to 110mbit! I am using more bandwidth than half the town for 24 hours so far. I got a letter last time for doing a quarter of that!

[arikimau]

regarding my F55 rebuild project, as a non-techie, I have 160 plus pages to read through on the roboteq controller

in short, re their site

they sell model HDC2460 for US$ 575 (!)

they also offer

25 pin to rc radio cable
6'dsub 9 pin cable
break outboard
rs232-iso
usb-iso
data logger

do I need any or all of these ?

as I can then place a single order

please advise

[Burgerman]

Before attempting to get some "engineer or mechanic/electrician" to build everything, or order any parts, you MUST read and understand the thread on lithium, and on roboteq well. If not this will end up as a pile of parts and a massive expence. They will never understand or have the time to understand hundreds of pages, you wont know this till it begins to get expensive and there are complex problems. This is not a project for the non tech type of person you claim to be. And it rules out most so called tech minded people too. Think of it as a build quality and IQ test, and allow around 1000 hours of concentration to learn/build something to a better standard than the real manufacturers 1st time.

Its not a construction kit, theres no instructions, and you must understand it properly. On a dificulty / learning scale of 1 to 10 its an 11.

I also suggest you read the roboteq 2450 or 2460 manual in full and if you dont understand anything go back and re-read. Or ask. As far as the scripting pages at least.

Then ask questions. THEN consider ordering parts.

[arikimau]

thanks, appreciated

i wish it wasn't so

but i was indeed hoping it would be (in effect) a kit project

(like some commentators the roboteq programming thread went way, way, way over my head)

[Burgerman]

Lennys code goes over my head too, but you need to undertand at least what its doing and why its needed (the physics). And have an analytical brain.

[Vitolds]

Even I agree with you, Lenny genius

[Vitolds]

The novelty of the roboteq GBL 2660

[LROBBINS]

I want to point out that there is still some unfinished business re. programming for the Roboteq controllers. I have incorporated some new things in the CANbus system for Rachi's chair, but they've not made it into the analog-only script or are there but have not yet been tested adequately. They are:

(1) Adjusting acceleration rate at different speeds or mechanical loads. (This DOES NOT apply to brushless motors.) Brushed motor acceleration (and deceleration) in Roboteq-ese is not physical acceleration but change of PWM per change of time. This results in slower physical acceleration when under load, for example, when starting out. Particularly on the BM3 which has a very large speed range, setting accel and decel to give comfortable mid-speed acceleration gives sluggish behavior starting out, and setting them high enough for low speeds makes it too harsh later on. I was working on an algorithm to compensate for this based on rate of change of current when the BM3 suffered a motor failure, followed by Burgerman being out of commission with repeated pressure sores. It works on Rachi's chair, but her chair does not have that wide speed range. It still needs to be tested on the BM3. If it does not work as intended there, I will have to re-think how to do this, probably using (commanded PWM - actual PWM) to control a boost of accel & decel when starting out.

(2) Motor compensation without current sensors. There is no simple way to sense motor current in brushless motors. Current sensors can be added for brushed motors, but, though I've since figured out how to make it safe-fail, a sensor failure can lead to a runaway. Hence, I tried to improve on Roboteq's motor current estimation to allow sensorless motor compensation. It actually works pretty well on Rachi's chair, almost as well as with sensors, but in Burgerman's mobot it's awful. The mobot has such a high power to weight ratio that it is actually moving at a goodly clip before the Roboteq sees any battery current draw at all - so there's no motor current estimate and, without motor current sensors, no compensation at all until then. The BM3, or the WILLchair for that matter, in this respect are more like Rachi's chair; they have more power, but also weigh more. So I suspect that this new sensorless compensation scheme will work reasonably well on most chairs, but that's not been tested at all.

(3) Current sensor safe-fail operation. I have figured out a way to detect current sensor failure and have incorporated this in Rachi's CANbus system. If a sensor has failed before startup, the chair works without any motor compensation (of course, sluggishly so you know there's a problem). If it fails after the computer has been turned on it auto-switches to sensor-less compensation (which, on Rachi's chair is not at all obvious). This has not been ported to the analog-only script and I will do so only after (1) and (2) have been settled.

So, some volunteers are needed. For (1), that means Burgerman, so I hope he's up and about soon, and not tied up with myriad other projects. If there's someone else using the Roboteq with brushed motors, please raise your hand. (2) should be tested with both brushed and brushless controllers. Will has modified his script, and I don't think it includes many of the updates made along the way on John's (such as a vastly simplified, and much better, turn compensation algorithm). I don't relish the idea of juggling two majorly-different programs, but Will - if you want to get involved in testing this, let me know and I'll try to harmonize your script and John's. Anyone else interested in helping with this is absolutely welcome to join in, but we're going to have to start with scripts that mostly share their code or I'll get things royally screwed up.

[Burgerman]

Every time I get off this bed for a few hours a day, back it comes. Been going on for 2 years. I have a million things to do before I can get that chair in and swap a motor and start testing again. And right now am highly frustrated. And trying to heal the same 2 sores again.

[Williamclark77]

No need to juggle two different scripts on my account. Yes, I use a heavily modified version of a very old script. My modified version works great on both of MY 48v brushless setups with zero lag. I have no idea how it would work on brushed or with current sensors. Quite frankly, I'm not confident enough in my code writing ability to let others use it. I almost killed myself once with a typo in the motor compensation routine. It's been several years since I messed with it. Haven't needed to.

I did test some later revisions but had the same issues Burgerman had.

One thing with mine that I haven't figured out: On my W1 chair, when you first power it on, moving the joystick does nothing for 4 to 5 seconds. It's as if it is disconnected. I ASSume it's until the Roboteq is fully booted with the script running. THIS IS THE BEHAVIOR I WANT. My W2 chair that I use daily does not do this. The joystick works immediately, which is not good. It (seems to) be working without the script until the Roboteq is fully booted. No big deal as long as you don't touch the joystick for five seconds after powering it on, but still not the optimum behavior.

I honestly have not tried to figure out why in well over a year and did not really troubleshoot a lot. If I recall correctly I copied the W1 Roboteq profile to W2 and the same script to both with no change in the behavior of either. I can't recall if I checked to make sure the Roboteq firmware version of both were the same. I THINK I updated both but can't remember.

[LROBBINS]

Will,

Working on the script for your chair would be to help me. It would be for you to test script revisions in a brushless system, not because you need a new script. If you don't want to engage in that project, don't worry about it, but if you do I would be happy to try to create a script with the revised routines that incorporates what you've changed.

For the joystick active on startup problem in Willchair2, I suspect that the same thing happened to your profile as happened to my copy of the analog profile. Take a look at "configuration tab/analog startup/center command to start" -- this should be ENABLED (and it's disabled in my analog profile - a goof that crept in I don't know when - yet it is enabled in the profile for John's mobot). That parameter is irrelevant for the CANbus system as the joystick is read by the Master module, not by the Roboteq, and I probably used the CANbus profile at some point as the basis for my analog profile that I use only for bench testing.

The delay for script start up (at least for the HDC2450) is 2 seconds, but it should be up and running only milliseconds after that. It takes my CANbus system 5 seconds - about 300 milliseconds for Master to come alive and trigger power on for the other modules, some milliseconds for the Roboteq's computer to be live and 2 seconds for the script to start, a few milliseconds for handshake check among all the modules, and 2 seconds for the display to fully paint the initial screen after the whole system is actually running - I can, however, start driving as soon as the screen starts to paint, so at about 3 seconds from pushing the button.

Ciao,
Lenny

[Williamclark77]

I'll check that in the next few days.

And of course, I'll test revisions of the script if needed. It'll be simple to use my W1 as a test mule.

[LROBBINS]

Great. It will probably be sometime in Sept. before I have a fully-updated "generic" analog script ready. At that point, I'll ask you for a copy of your script so that I can incorporate your changes.

[eugenech]

Lenny,

I will test brushless analog version as soon as its ready. I will also send you my version. I did some changes for potentiometer handling resulting in much smoother acceleration and more control at high settings and low speed.

Eugene

[LROBBINS]

Thanks Eugene, that will be most helpful.

How have those Chinese geared-brushless motors been working out? Have you monitored current draw under various loads and speeds? (You can do that either by adding a line in the script to print battery current and copying the text from the Run tab, or with a clamp meter on a battery lead - not on a motor lead because of the square-wave commutation of the brushless.) I ask because those motors, as many, use a worm gear and I'm wondering about their efficiency.

Ciao,
Lenny

[Burgerman]

The way to work out motor current which may be up to 10x the battery current depending on impedance and load and also speed, is battery Amps, x pulsewidth (or power). So if 50% motor pulsewidth, then combined motor current is double the battery current.

Because I dont know of a way to measure it directly on a brushless motor. Unless you take a reading via a clamp meter (true RMS) and then multiply by 2 (or 3?). And divide by 1.5?

This is of course why low impedance motors are way more efficient. Or why higher voltages are, (same result) because you can half the gearing and so reduce load by 50 percent and still get same top speed. In other words the lower the motor impedance, the lower the battery current is for the same torque/Amps at the motor.

[LROBBINS]

is battery Amps, x pulsewidth (or power)

Yes, except that "x" should be "divided by". I don't know if even a true RMS clamp meter would work correctly with the waveform of brushless commutation.

[Burgerman]

Yes, except that "x" should be "divided by".

My bad...

Battery amps = 50
Pulsewidth = 50.


I hate maths.

Either way at half the pulsewidth you get double the motor amps compared to battery amps!
And at 10% pulsewidth, you get 10x the battery current, at the motor.

[eugenech]

Thanks Eugene, that will be most helpful.

How have those Chinese geared-brushless motors been working out? Have you monitored current draw under various loads and speeds? (You can do that either by adding a line in the script to print battery current and copying the text from the Run tab, or with a clamp meter on a battery lead - not on a motor lead because of the square-wave commutation of the brushless.) I ask because those motors, as many, use a worm gear and I'm wondering about their efficiency.

Ciao,
Lenny

Motors work great! We build two identical chairs. One with Permobil M300 motors and one with brushless. Brushless have better ride, very smooth. I monitored amps using Roboteq Motor AMP and Battery AMP variables. Most I got was 35A. I will modify script, print values and let you know if it goes higher.

Here is my routine for SpeedPot:
ASpeedPot:
DIM TempPot AS Integer
IF (LoopCycles MOD CyclesPerSpeedPotRead) = 0 THEN
IF SpeedPotInstalled=TRUE THEN
SpeedLeft = GetValue (_BSR, 1)
SpeedRight = GetValue (_BSR, 2)
Pot = GetValue (_VAR, 1) + 10
IF Pot > 100 THEN
Pot = 100
END IF
IF Pot < 0 THEN
Pot = 0
END IF
TempPot = Pot
IF SuppressPrinting = FALSE THEN
PRINT ("SPEED POT set to " , Pot , "% \n")
END IF

ELSE 'speed pot not installed
Pot = DefaultPot
TempPot = Pot
END IF 'end of IF SpeedPotInstalled=TRUE
TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))
IF (Throttle >=0)THEN
Min = SpeedPotFwdMin
Max = SpeedPotFwdMax
ELSE
Min = SpeedPotRevMin
Max = SpeedPotRevMax
END IF
'PRINT ("TEMPPOT set to " , TempPot ," Pot ",Pot, "% \n")
SpeedPot = ((Max-Min)*TempPot)/100 + Min
IF (Throttle > -150) THEN ' use Fwd turn values when at or above "turn in place"
Min = TurnPotFwdMin
Max = TurnPotFwdMax
ELSE ' use Rev turn values only when definitely going backwards
Min = TurnPotRevMin
Max = TurnPotRevMax
END IF
TurnPot = ((Max-Min)*TempPot)/100 + Min
END IF 'end of IF (LoopCycles MOD CyclesPerSpeedPotRead) = 0
RETURN 'End of "SpeedPot:"


VAR 1 holds the value for Potentiometer (I use software vs hardware).
By reading speed from the motors I dynamically change SpeedPot value. That way Pot defines maximum value and SpeedPot changes with the speed allowing for smoother ride and automatic adjustment of joystick commands based on speed.

[LROBBINS]

Hi Eugene,

Though I've been thinking on and off about the smoothing code you posted it took me a while to get my head around it and I've been very busy so this is the first chance I have to tell you my take.

I LIKE IT, though of course I have some changes to suggest. I haven't done any "real world" testing, so there may also be some unintended consequences yet to be discovered.

First, lets see graphically what it does. The following was generated by a spreadsheet, not a Roboteq, and just shows what happens when the stick is held full forward with SpeedPotMin = 20.

The green line shows what Throttle does if pushed forward moderately quickly without any smoothing - it would be quite a bit steeper if one slams the stick forward. The yellow line shows how your algorithm adjusts the Throttle value that actually goes to the motors. The blue line shows the effect of moving-average damping (and I'll get to that later).

At speed below SpeedPotMin (20% of 1000) the yellow line overlays the green, but after 200 it is much shallower, but always above the speed line. This has two effects, both beneficial. First, brief changes in stick position will have a much more damped response than without this routine. Suppose you had reached speed = 600 and the stick jiggled back to 550. Without the damping Throttle would go from 1000 to 550 very quickly. But, with the damping routine, at speed = 500, the adjusted throttle is 680 (rather than 1000), and the change toward 550 will not only start from a less extreme value, but will take more time because it's following a shallower slope. Second, although there is substantial damping with the adjusted throttle value always > speed, the chair's acceleration is determined by the accel/decel parameters and the smoothing doesn't introduce any sluggishness. We get tremor or bump damping without any loss of responsiveness.

The amount of damping is not user adjustable, however - it's determined by the PotMin and PotMax values and the division by 20 in the line

Code: Select all

TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

The values you've chosen seem good to you, but I don't know whether they'll work for all chairs and all users.

There's also no damping if you just release the stick to center. Then, Throttle = 0 and adjusted Throttle = 0 despite the other calculations. This probably isn't a serious limitation though because with hand off the stick you can't be jiggling it anyway.

Compare this to what happens with moving-average damping (blue line). With this, the slope of the Throttle line with the stick held steady at 1000 is just as steep as when there's no damping, except at the start and end of the acceleration. There, the slope is curved, but much shallower than the unmodified joystick value. Damping happens whenever the stick is moved, not when it's held steady, but the same S curve will be generated if the stick is moved at any speed - under 200, in the middle, at the top. It's easy to adjust the amount of damping - - average more cycles and you get more damping. But that's also exposes the worst "feature" of moving-average damping. If the number of cycles is too high, the damped change of throttle is slower than what accel/decel would do to speed and the chair gets sluggish. This was most obvious if I just released or centered the stick - deceleration got delayed, yuck.

So, I like what you've done so much that I'd like to put it in my system, test it out on the bench with dummy loads, and then in the chair. I have to solve a couple problems, one minor, one more interesting, in order to do this. The minor problem is that with a brushed controller and no encoders I do not have motor speed values. It's a minor problem because motor PWM is, for this purpose, an adequate stand-in for speed. The more difficult problem is that I don't do these calculations in the Roboteq but in the Joystick pod (MASTER module) and just send Throttle and Steering to the Roboteq over the CAN bus. The only connection to the Roboteq is the 2 wire CAN cable and there's a division of labor; MASTER handles all driving calculations and Roboteq handles all motor control calculations. To implement your code in my system exactly as you've written it would mean either moving the SpeedPot calculations to the Roboteq (and sending a Pot value message repeatedly from Master to Roboteq) or leaving the calculations in Master, but repeatedly send PWM1 and PWM2 values from Roboteq to Master. Neither solution is very elegant and the first is too much work, so I started thinking about whether the same kind of damping could be done in Roboteq after the final Throttle and Steering values have arrived, without involving the pot at all. The answer is yes; I can get exactly the same curve as generated by your routine, and get some advantages, by doing the following:

Code: Select all

DampingStrength = 5
ThrottleAdjust = abs(Throttle) - (abs(Speed1)+abs(Speed2))/2)
Min = abs(Throttle/DampingStrength)
ScaledThrottleAdjust = ((abs(Throttle)-Min)*ThrottleAdjust)/abs(Throttle)
IF (Throttle >= 0) THEN
   AdjustedThrottle = Throttle-ScaledThrottleAdjust
ELSE
   AdjustedThrottle = Throttle+ScaledThrottleAdjust
END IF

SteeringAdjust = abs(Steering) - (abs(Speed1)+abs(Speed2))/2)
Min = abs(Steering/DampingStrength)
ScaledSteeringAdjust = ((abs(Steering)-Min)*SteeringAdjust)/abs(Steering)
IF (Steering >= 0) THEN
   AdjustedSteering = Steering-ScaledSteeringAdjust
ELSE
   AdjustedSteering = Steering+ScaledSteeringAdjust
END IF


This makes incorporating the smoothing algorithm into my system simple. I can just add this at the start of the SetMotors: subroutine and send AdjustedThrottle and AdjustedSteering to the motors (instead of Throttle and Steering). But there's another advantage.

Because pot values are neither used nor modified, I can now have a parameter that sets the strength of the damping without having to change pot min and max (which I might not want to do for other reasons). If DampingStrength = 1, there's no damping. If DampingStrength = 5, it duplicates what you get. If DampingStrength > 5 the damping gets stronger, with the AdjustedThrottle line getting asymptotically closer to the speed line as DampingStrength is increased. With DampingStrength = 10, it's twice as strong as with your routine (and damping starts at speed = 100 instead of speed = 200). With DampingStrength = 200, the AdjustedThrottle differs from Speed by no more than 5 (out of 1000) units, and movement is so damped that the chair may not move at all. HOWEVER, even at ridiculously strong damping the AdjustedThrottle curve is always above the Speed line so there's no change in acceleration/deceleration if the stick is deliberately moved. A "do what I say when I say it".responsiveness is not compromised.

I am going to be pretty involved with other things until mid September (and will be in Seattle for a couple weeks of October), but I will try to test this out before posting revised analog and CANbus scripts.

[Burgerman]

If DampingStrength = 1, there's no damping.

[LROBBINS]

Yes John, I too like being able to adjust damping strength, including turning it off, but the beauty of this algorithm is that it should just damp very brief jiggles that might result from a tremor or driving over gravel - it should have no effect whatsoever on how the chair responds to deliberate stick movements. No delays, no reduced acceleration, no attempt to hide the effects of poor joystick position and control. Pudding stirrers will still get into trouble.

Everyone,
Someone may eventually notice that there's a bug in the code I posted yesterday. With Throttle (or Steering) = 0 there's a divide by 0 in the line

Code: Select all

ScaledThrottleAdjust = ((abs(Throttle)-Min)*ThrottleAdjust)/abs(Throttle)

Easy to solve. We can either not damp when Throttle = 0, just like Eugene's original, or we can assume that Throttle = 1 rather than 0 until speed has largely decayed, then skip the damping.

Years ago, a technician who had worked in my lab for many years told a newcomer "When Lenny tells you the next experiment to do, wait a day before starting. By then he'll have thought of most of the mistakes he's made in the design." I guess I have the same habit doing programming as I did doing fruit fly genetics. Instead of divide by 0, I may have drawn a mating scheme where two females had to mate.

[Burgerman]

it should just damp very brief jiggles

Those jiggles may be my intended input to steer correct as I wheelie through a doorway!

[LROBBINS]

Point well taken - you may want to the damping down low or even off.

[Burgerman]

I will do. I also always want more turn response. And stop turning response.

I want it to turn and stop turning as fast as I move the stick, so it follows exactly. As such you would be surprised at quite how instant I want that! I dont mean turn speed which can be set low, just low latency. So the stick is directly connected like mechanical connection. If I choose 30% of left stick, it should hit that point as soon as the stick does. And back to zero just as fast.

Hobby some people who fly very fast planes or 3d helis swear and bitch and crash because 6 to 10ms latency is too slow for them and causes over corrections and overshoots in manoevers... They spend a fortune on super low latency rc links, ultra fast servos, etc. The average cheap RC is about 25ms which is very noticible even by me. It makes flying fast stuff harder and less accurate. My system does 6ms, and I cant feel that.

[eugenech]

Thank you Lenny. I am happy to be able to contribute to your work.

What I did when you release stick to 0 was intentional. I was trying to keep stoping distance to minimum. Decaying maybe too slow when you are going top speed.
Great suggestion to make DampingStrength as a variable.

[LROBBINS]

IMPORTANT

Eugene, please do the following test as soon as possible.

Change the line:

Code: Select all

CyclesPerSpeedPotRead = 10/(MainLoopWaitTime+1)

(you may have a set number different from 10 in your script) to

Code: Select all

CyclesPerSpeedPotRead = 1/(MainLoopWaitTime+1)

Do not make any other changes, but test the chair for "smoothing". My best guess is that there will be NONE even though your algorithm is still working.

Now, increase CyclesPerSpeedPotRead to 2, 3, 4 --- till you get back to the number you originally had and check again at each step for smoothing. I suspect that There will be NONE until you get back to the original number, or very close to it.

ONLY DO THE FOLLOWING WITH GREAT CAUTION, or skip this if the results above are already clear. Increase CyclesPerSpeedPotRead above what you had originally. You may get a bit more smoothing if very close to the original number, BUT beyond that the motor will not just stop accelerating but will try to reverse direction every CyclesPerSpeedPotRead'th cycle. As John can tell you, this can soon break a motor. Make the changes in CyclesPerSpeedPotRead in very small increments, and don't move the stick very far so that everything stops quickly if you take your hand off.

I was up much of the night worrying over this because of the clue in your comment

What I did when you release stick to 0 was intentional. I was trying to keep stoping distance to minimum. Decaying maybe too slow when you are going top speed.

The beauty I thought I saw in your algorithm is that those curves simply cannot produce any delay. If you are getting slow decay, then those curves are not the full picture. I eventually realized why. I had neglected to take account of this conditional in your implementation within the SpeedPot routine:

Code: Select all

IF (LoopCycles MOD CyclesPerSpeedPotRead) = 0 THEN

Both my simulation of your code, and the code I wrote, adjust Throttle and Steering by the Speed at every moment. With this conditional, you are using the current Speed only when (LoopCycles MOD CyclesPerSpeedPotRead) = 0. On every other cycle, you are using the adjusted pot value from 1 to 9 cycles back in time (assuming CyclesPerSpeedPotRead is 10). If you could magnify the command curve enough, what you'd see is not a smooth curve, but a sawtooth, which is actually touching the speed curve once every 10 cycles - and with command = speed (or power) there's no acceleration. There's smoothing AND DELAY.

Using an "aging" adjustment will cause exactly the kind of driving unpredictability that John worries over. On top of that, unlike the running-average damping produced by "Damping" in my script, there's no simple way it can be adjusted. There's only 1 (or a very narrow range because of rounding errors) of CyclesPerSpeedPotRead that can give any smoothing - below that, there's no smoothing, above that there's repeated motor reversal.

The plot I showed, re-doing the adjustment with current Speed at every cycle, will not cause any delay. I've also just about convinced myself that it won't give any damping either. I hope I'm wrong on that, but I won't know until I physically test it - I'm not enough of a mathematician/logician to really figure it all out from the numbers, but I fear that this is just another example of "There's no free lunch".

Please, please do that test - I can't - and tell us the results before anyone invests time in reproducing this, or any motors get damaged.

[eugenech]

Hi Lenny,

In my script I use CyclesPerSpeedPotRead = 20/(MainLoopWaitTime+1) and MainLoopWaitTime = 0.

In real world you have to deal with inertia. Chair is heavy and motor power is not infinite. Motor needs time to change speed. Adjusting it too fast and often is not necessary and sometimes can be harmful.

I think key is this line of code:

TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

Pot defines relative top speed. If set Pot to a 100, motors will reach speed of 1000, if 50 motors will reach 500. Changing Pot changes range of the joystick command.
Idea of this algorithm is to dynamically change value of TempPot (causing change in SpeedPot and TurnPot) based on motor speed until you reach Pot value (speed limit).

To find out speed you add relative speed of both wheels and divide by 2. Given that relative speed is from 0 to 1000 and Pot is 0 to 100, you divide speed by 10. So, number 20 is explained.

I will try to produce graphs from real chair Tuesday or Wednesday and will post them.

[Williamclark77]

I think key is this line of code:

TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

Pot defines relative top speed. If set Pot to a 100, motors will reach speed of 1000, if 50 motors will reach 500. Changing Pot changes range of the joystick command.
Idea of this algorithm is to dynamically change value of TempPot (causing change in SpeedPot and TurnPot) based on motor speed until you reach Pot value (speed limit).

I had set my speedpot up this way, making the joystick input proportional to the top speed. It worked fine. PERSONALLY though, I did not like it. It made the acceleration rate altered as well. Maybe "acceleration rate" isn't the best term for what I'm describing.

For example: I want to do a slight 1" or so high wheelie to hop over a board. With the speedpot maxed out I blip the joystick quickly 1/4 of the way forward. I get a 1 inch high wheelie with the chair barely moving forward. With the speedpot at 50% I now need to move the joystick exactly the same but twice as far forward to get the same result. I later forget that I maxed out the speedpot, do the same quick movement of the joystick expecting the same slight wheelie, and almost flip over backwards.

Clear as mud? It's probably much less noticeable on a chair that's less "tippy" as mine. I just want the joystick to always feel the same regardless of the top speed.

Don't modify on my account. I'm just bringing up something that may be an issue.