PINNED - Roboteq Controller - developing for powerchairs

[Williamclark77]

I may just 3d print something like those out to test. Dividing by 2 certainly makes mowing by radio much easier - which is not easy as is! I need an overhead view like in rc car racing. Video will be added one day. Time doesn't allow much.

[Burgerman]

Quadcopter hovering at 50 feet, video cam pointing down, goggles.

[Burgerman]

I added the damping fix a week ago, and all seems OK although I have it set to 1

It still responds about 1/30th of a second after I whack the stick left/ or right or forwards though. But that's just the time taken to run everything I suspect. Its not much different to the typical mobility device, maybe a fraction slower.

[LROBBINS]

Hi John,

Glad to see you're back in the saddle so to speak.

Setting the damping to 1 is exactly the same as not having any. If you want to try 2 or 3, you will probably have to increase accel and decel values to keep from getting sluggish - that will allow the chair to quickly reach intermediate values as the stick averaging proceeds. On the other hand, 1 may be just right for you.

A 1/30th sec delay surprises me. I'd expect at most a couple msec before the chair starts to respond. On the other hand, I have noticed a peculiarity of the Hall-effect joystick. If you move it quickly from forward to reverse (from high output voltage to low in my setup), the output will briefly overshoot the value you're headed for, and might even momentarily trigger an out-of-range condition; the same thing happens with any quick movements. That might be the delay you're feeling. I have mostly gotten around that by setting my out-of-range (in the Arduino code) to half-way between steady-state end-of-travel calibrated voltage and 5V or 0V instead of 50 mV over or under end of travel voltage. Still overshoots enough to say "out of range" once in a long while. So, you might try setting your out of range triggers (in your case in Roborun) a bit further out.

I am worried some about your recurrent pressure sores. If your gel cushion is more than a year or two old, you might want to replace the gel pad - they get stiffer over time. Or, you might think about going to a Roho. I know you don't like the lack of stability, but that can be lessened. On Rachi's chair I have a ca. 70 mm high strip of 3mm polyester bent into a U that goes around the side and back of the Roho. Doesn't change the "immersion", but does limit the side-to-side squishiness. (BTW, someone on WCJ linked a new Roho with electronic "ideal pressure" sensing. Sounds like a good idea to me, though Rachi's cushion has not had any change of pressure, except when in an airplane at altitude, in about 8 years!)

Ciao,
Lenny

[Burgerman]

In my case its through laying on my bed on my back overnight instead of turning as I should. And now and again it catches me out. I don't think its the cushion. But it is old. I may just buy a new one. Don't like the Roho ones personally. Had a quadro for a bit. Didn't get on...

[LROBBINS]

Bed is the one place Rachi, who also doesn't move - can't without one of us doing it, is unlikely to get a pressure sore, or her more usual friction burns -- it's a water bed. Would be an absolute impossibility for transfers, but sure does distribute the pressure. Ciao, Lenny

[Burgerman]

I have thought about that. But I wouldn't be able to get off!

[ex-Gooserider]

I have thought about that. But I wouldn't be able to get off!

Yup, it's important to be able to get off.... (wish I still could.... )

I use a 'Select Comfort' "sleep number" air mattress on our bed - we purchased it back before I was hurt, as an aid to getting off... Experts on the subject advise that the optimum surface firmness for getting off is much harder than what most find comfortable for sleeping. The Select Comfort is an air bladder with firm foam edges that allows one to adjust the firmness as desired, including having different settings for the two sides of the bed... It also allows one to set it to a comfortable level for sleeping, and but crank it up to maximum pressure when you and your partner are getting off....

Post injury, I've found it works quite well at conforming to the shape of my body and giving good support without high pressure points (I do still wake up and roll over every few hours anyway, but I always used to do that, it's just harder now...

Even at the pressure I use for sleeping, it is pretty stable, I don't have any trouble moving around on the bed and transferring on and off without help (I do use a slide board to bridge the gap between the bed and my chairs) it doesn't have the same squish-around problem that I had with the Roho that I tried....

ex-Gooserider

[Burgerman]

Is there a link? I may be interested.

[stevelawiw]

Burgerman I'd be very grateful if you could provide a link to your Roborun profile created with the latest firmware, the old one you provided doesn't work with the latest firmware

[Burgerman]

My profile may not work for you, as it uses specific pins, calibration etc. But it SHOULD work with the latest firmware.

[stevelawiw]

Sorry I should have said it won't load, It's a feature of the latest firmware that it won't read profiles saved with an earlier firmware version as reported by Lenny on the RoboteQ forum!
http://roboteq.com/index.php/forum/11-pc-software/29528551-roborun-v-1-2-8-26-2014-build-has-an-problem

[Burgerman]

I updated firmware, and reloaded profile, all without issues. Although I did have to restart the roboteq.

Ver. 14b-033115

[LROBBINS]

Steve,

What you've probably run into is this. When Roboteq changes Roborun+, not the firmware, the formatting of the profile xml file changes. Thus, an older profile XML file can't be opened in a newer Roborun. What you have to do is uninstall the newer Roborun, install an older one, open the old profile and write it to the controller. Then, install the newer Roborun and read the profile from the controller. You can now save this profile to disc (with a new name!) and it will be readable by the newer Roborun. I consider this a ROYAL pita. The reason to update Roborun is that newer controller scripting commands, such as the current commands for handling incoming CAN messages, aren't recognized by the older Roborun which will give you a compile-time error trying to build the script - if the script is actually correct, however, it actually will write to the controller anyway. You just can't check its syntax properly first.

I don't know which versions of Roborun+ are still available at the Roboteq site, but I have zips of the following on my HDD:

roborunplussetup-v12-010614.zip
roborunplussetup-v12-082614.zip
roborunplussetup-v14-051515.zip
roborunplussetup-v14-112714.zip

If you want one of these PM or email me your email address and I'll attach it.

Ciao,
Lenny

[stevelawiw]

Thanks Lenny, I've got an old version I can try tomorrow, I'll let you know how it goes

[Burgerman]

READ THE FOLLOWING VERY CAREFULLY.
2 NEW SENSOR MODES.
REMOVED NOISE ON STARTUP?
More too...

1.5 10/02/2015
--------------
- Fixed sporadical USART crash.
- Fixed USB LED in FBL2XXX and FDC3XXX.
- Implemented Sin/Cos sensore mode.
- Added CTRIM command.
- FIxed SCRO, CR and BCR commands.
- Implemented Stall Detection when Encoder is disconnected.
- Fixed Hall Speed fluctuation.
- Implemented Hall Sinusoidal mode.
- Fixed DI for CANOpen interface.
- Removed noise on startup for BL motors.
- Support of more than one MagSensors in single Controller.
- Implemented Sensor Offset calculation when idle.
- Implemented Amps Limit during BIND process.
- Adapted default configuration for digital outputs.
- Implemented CANOpen for all supporting boards (STM32F30X).
- Fixed USB Serial Number(board type dependent).
- Implemented FOC.
- Fixed Script download overflow bugs.
- Fixed crash when configuring SPI Sensor Mode.
- Fixed overflow and several bugs in Count Position mode.
- Fixed Overvolt error in F3SDC2XXX.
- Fixed motor squeal when enabling encoders and Encoder Counters in FDC3XXX.
- Fixed crash when configuring to Encoder Sinusoidal in MBL1XXX/SBL1XXX.
- Fixed delayed pulse in capture.
- Fixed Short problem for MDC2XXX rev.3.2
- Implemented MiniJ1939 CAN mode.
- Fixed CANOpen bugs concerning node id 32 and TPDOs 3-4.
- Fixed angle adjust and added stall detection in Encoder Sinusoidal mode
- Fixed Battery Amps for single channel boards with only one sensor.
- Fixed deadtime in PWM in FBL2XXX.
- Implemented unified RoboCAN for all boards, RIOX and Magsensor.

1.4b 03/31/2015
---------------
- MCU overheat error no longer sticks
- Remove Short fault when powering up from power control.
- Fixed Battery Amps for single channel boards
- Added error logs for SDCard
- Fixed Amps averaging on FBL2xxx
- Added Inverted USART support
- Added %sopen, %swrit SDCard functions
- Fixed MOSFETS Off on MDC1xxx, XDC2xxx
- Fixed knocking on FBL2360
- Added support for FBL2360v21
- !AC now works same as in ^MAC
- Progressive Angle Advance in Sinusoidal mode
- Patched Motor Amps sign in Sinusoidal mode
- Fixed CANOpen TPDO Send
- Fixed Short Circuit disable on XDC2xxx
- Added MDC1230
- Removed zero search on Sinusoidal with SPI feedback
- Fixed channel 2 speed capture on FBL2xxx
- Fixed abrupt speed change in Position Count mode
- Fixed negative number of brushless poles in Speed Position, and Position Count
- Sinusoidal with SPI sensor mode
- FDC3xxx support

[stevelawiw]

I didn't notice any difference noise wise or any other way when I installed this new firmware

[stevelawiw]

Lenny I tried loading the profile with rev 1.4 - it didn't work. Thanks for the offer of sending me other versions but I'm giving up on this now it's not worth it!

[Burgerman]

Set everything the same from scratch.

And install version 1.5!!!

[LROBBINS]

Roborun 1.4 (not to be confused with firmware revision 1.4) is too new for the profile John posted. I think that you would have to go back to Roborun+ roborunplussetup-v12-082614. Side note to John and Will: if you ever update your Roborun+, make sure the controller has a good profile in it and then read it from there into the new Roborun and save it to a file.

Off to download the firware 1.5 revision.

Ciao,
Lenny

[Burgerman]

Roborun 1.4 (not to be confused with firmware revision 1.4) is too new for the profile John posted. I think that you would have to go back to Roborun+ roborunplussetup-v12-082614. Side note to John and Will: if you ever update your Roborun+, make sure the controller has a good profile in it and then read it from there into the new Roborun and save it to a file.

Thats what I did last time.

There may be some useful changes in 1.5. For brushless and for your bus system?

[LROBBINS]

There may be some useful changes in the new firmware, and to be able to compile a script offline using the new features will probably require the updated Roborun. Unfortunately, the user's manual hasn't been updated in a long time so none of the newer features are actually in there, and there are a few error that need correcting too.

Ciao,
Lenny

[Burgerman]

If I am turning left, or right on the spot, then suddenly centre the stick, and aim for a gap, it doesn't work. The chair continues to rotate on the yaw axis, and I go forwards at a different angle to what I intend. Taking out people, tables etc...

Turn on spot, release, stops fast.
Turn on spot then instantly aim for a spot ahead, continues to turn and still goes forwards, to a spot you were not expecting...

I have steermixaccel and dec set to 600.

What can I do to change that?

MY CURRENT SETTINGS:

Code: Select all

SpeedPotPin = 5            'Analog input number in Roboteq setup.
LeftCurrentSensorPin = 7   'Analog input number.
RightCurrentSensorPin = 8  'Analog input number.
AlarmPin = 6               'Digital output number in roboteq setup used for low voltage alarm.
Brake1Pin = 1              'Dig output number of brake operating in setup.
Brake2Pin = 0              'Dig out number as above, both brakes controlled by pin 1 if 0 choosen.

'JOYSTICK AND SPEEDPOT SETTINGS
Damping = 2                'Number of joystick readings to moving average. 1 to 20 acceptable figures.
SpeedPotInstalled = TRUE   'Is speed potentiometer installed? (TRUE/FALSE)
SpeedPot = 90              'Default if SpeedPotInstalled = FALSE. 90, allows speed headroom for steer/mixing.
SpeedPotLowFault = 30      'Chair speed used if pot fails giving too low voltage.
SpeedPotHighFault = 60     'Chair speed used if pot fails giving too high voltage.

SpeedPotFwdMax = 100       'Percent max forward speed at max speedpot setting. <100 for turn headroom at speed.
SpeedPotFwdMin = 17        'Percent max forward speed at min speedpot setting.
SpeedPotRevMax = 26        'Percent max reverse speed at max speedpot setting.
SpeedPotRevMin = 13        'Percent max reverse speed at min speedpot setting.

TurnPotFwdMax = 22         'Percent max turn rate going forwards at max speedpot setting.
TurnPotFwdMin = 14         'Percent max turn rate going forwards at min speedpot setting.
TurnPotRevMax = 17         'Percent max turn rate going backwards at max pot speed setting.
TurnPotRevMin = 14         'Percent max turn rate going backwards at min pot speed setting.

TurnAtFullSpeed = 100      '100=no reduction of turn rate with speed, 0=turn rate zero at max speed.

' DRIVING CHARACTERISTICS
'the following override the settings in the Roboteq configuration:
M1Accel = 2300             'Max motor 1 acceleration.
M2Accel = 2300             'Max motor 2 acceleration. (Set both the same!)

M1Decel = 2500             'Max motor 1 deceleration.
M2Decel = 2500             'Max motor 2 deceleration. (Set both the same!)

AccelMotorComp = 0         'Adjust accel & decel for motor compensation 0 = no effect,
DecelMotorComp = 0         'but I have no idea of how sensitive this parameter will prove to be
                           '20 makes a noticeable difference in initial acceleration in bench test

AccelSteerMixWeight = 600  'Turn Acc. 0 = no effect of M1-M2 motor power on accel/decl, 100 = full effect
                           'if 100 is not enough, it's OK to try values > 100
DecelSteerMixWeight = 600  'Turn dec. 0 = no effect of M1-M2 motor power on accel/decl, 100 = full effect
                           'if 100 is not enough, it's OK to try values > 100
' BACK STICK BRAKING
DecelBoost = 140           'Back stick braking. Percent of added deceleration to use if Throttle crosses 0.
                           'effect of this is proportional to how far past 0 the stick is moved.

MotorResistance = 55       'MOTOR COMPENSATION. (SETTING THIS TOO HIGH IS DANGEROUS AND WILL CAUSE A RUNAWAY)
                           'Set to less than motor mOhms, then adjust based on response a little at a time.
                     
UseCurrentSensors = TRUE   'Set to TRUE if using external current sensors on analog inputs
                           'Set to FALSE to use Roboteq's internal motor current estimates. (Erratic results).
                     
'parameters added to allow motor compensation boost at low estimated motor current; irrelevant if
'equipped with motor current sensor
BoostStart = 5             'No boost below this to avoid drift at small or no joystick movements
BoostEnd = 500             'Safety limit - make sure there's no boost at 50% or more stick throw
MaxBoostFactor = 1         'Increase MotorCompensation by this factor at low currents; 0 = no boost
BoostEndCurrent = 100      'Taper boost to zero when this value of motor current (10X amps, e.g. 60 = 6 Amps)
                           'is reached
' PROGRAM TIMING
MainLoopWaitTime = 0       'Milliseconds to wait for each cycle through MainLoop: set to 0 for max loop speed
CyclesPerSpeedPotRead = 200/(MainLoopWaitTime+1) 'Number of cycles between each read of pot
                                                 'Reduce number of cycles if there is a wait time in main loop
TimeBetweenAmpHrReads = 1000     '1000 mSec = 1 second - time interval between checking current draw
TimeBetweenAmpHrOutputs = 10000  '10000 msec = 10 seconds - time interval for sending current used to display
                                 'device
' MISCELLANEOUS
SuppressPrinting = TRUE    'Set to TRUE to suppress printing to speed and smooth controller/PC
                           'interaction; PRINT of current used will not be suppressed, but is sent only
                           'once every vTimeBetweenAmpHrOutputs msec
AllowSerialInput = FALSE   'Set to TRUE if using serial joystick or emulation
FullRechargeVoltage = 449  'Ten times battery voltage; 44.9V = 3.45V/cell - voltage present only
                                 'immediately after recharging -- used to reset AmpHrs-used measurement to 0
LowVoltsAlarm = 400        'Tenths of volts, E.g.410 = 3.14V/cell for 13s pack
NoLoadCurrent = 30         'Current with no motors running (20 = 2 Amps) YOU SHOULD CHECK THIS ON YOUR CHAIR AND
                                 'SET THE VALUE JUST OVER WHAT YOU MEASURE
NoVoltReads = 50           'No. of times to read quiescent volts before averaging

[Burgerman]

If you watch on the roborun screen, the motor current for turning, when turning on the spot, is very high, and it takes it much longer to decay to zero than the motor command.

That is motor current takes a long time to drop away after you release the stick.

You may use 10 percent as a motor command, or less, while compensation rises to maybe 100A to start the turn. But is slower to drop away to zero than your 10% stick command is.

So it keeps turning longer than you want. I need it to stop turning the moment I let go.

[Burgerman]

DecelSteerMixWeight = 600
AccelSteerMixWeight = 600 doesn't affect turn acc or dec if you are stationary.

Or moving slowly?

I need a separate way to set forward (and reverse?) acceleration/deceleration.
And a separate way to set turn acc/dec that needs to be much higher.

If I set forward acc or deceleration higher, it tries to flip me out, under acceleration, which seems to build gradually after jamming stick forwards. And initial deceleration from speed is quite low, but it "builds" until the tyres squeal and I am falling out of the front.

M1 and 2 Accel = 2300
M1 and 2 Decel = 2500

So I have to set these quite low. Because while initial acc/dec is slow, it builds with speed quite noticible. This is where my delay, or my turn on the spot acc/dec delays are. I get accidental 8mph wheelies set like this during acc. And I get tyre noises during deceleration starting as it slows to about 8 to 6 mph or so. I got a sudden wheelie when coming back as I accelerated and passed the red car on one attempt. Had to pull stick back at 10mph.
And I didn't ADD more braking here at about 8mph on slowdown, if you watch carefully you can see I ADD some power to lose some deceleration. But deceleration increases over time as I slow till tyres protest:
http://www.wheelchairdriver.com/BM3-con ... /15mph.mp4

In other words, acceleration rate, (and deceleration rate), seem to increase over time, and it means setting them too low to avoid excess. It means a delay at the start, and getting flipped out over the rear as they build and you don't notice! Is this some maths thing? (Or the affect of 45V and full stall current available at half pulsewidth and 8mph?)

[LROBBINS]

This sounds like a complicated problem that's going to take me quite some time to dissect - if I'm able to. I'll try to get on it tomorrow. Unfortunately for this I no longer have a Roboteq on the bench - it's driving Rachi's chair, so testing things is going to be pretty limited. I do have a fresh set of CAN nodes on the bench undergoing testing, but that's with just a Roboteq emulation script sending fake data back on the bus. These are problems that I'll probably never feel with Rachi's chair at the walking speeds we go.

A couple comments right off the bat:

If I am turning left, or right on the spot, then suddenly centre the stick, and aim for a gap, it doesn't work. The chair continues to rotate on the yaw axis, and I go forwards at a different angle to what I intend. Taking out people, tables etc...

Turn on spot, release, stops fast.
Turn on spot then instantly aim for a spot ahead, continues to turn and still goes forwards, to a spot you were not expecting...

Code: Select all

Damping = 2                'Number of joystick readings to moving average. 1 to 20 acceptable figures.


First off, set damping back to 0 for now to get the fastest possible response to the joystick. Does this make any difference for this problem?

If you watch on the roborun screen, the motor current for turning, when turning on the spot, is very high, and it takes it much longer to decay to zero than the motor command.

That is motor current takes a long time to drop away after you release the stick.

That is as it should be. Current depends on PWM and load, but Motor Command is not the motor output, it's where you're aiming to get to by accelerating or decelerating. In Roborun, PWM output is Motor Power. If you plot Motor Power it should increase or decrease in much more the same time frame as Current (they won't match because of compensation, but the timing should be similar). If (perhaps easier to see with motor resistance set to 0) you just push the stick straight forward, the Motor Commands will go up nearly instantaneously, but the Motor Power will go up as determined by Accel and current will initially rise sharply because of starting load, then fall away to a steady value as your reach a steady speed.

You may use 10 percent as a motor command, or less, while compensation rises to maybe 100A to start the turn. But is slower to drop away to zero than your 10% stick command is.

I'm not quite sure what you are saying here, but I'll assume that "your 10% stick command" refers to dropping from 10% to 0. I think the problem may start with Motor Compensation. Let's assume that you move the stick from 0 to 10% straight forward (10% = 100 out of 1000 motor command units), that starting current is 100 Amps, that motor resistance is set at 50 milliohms, and that battery voltage is 30V (to use a round number). The MotorCompensation subroutine will do the following:
M1Comp = (10*ILeft*MotorResistance)/BattVolts = (10*1000*50)/300 = 500,000/300 = 5,000/3 = 1666
and then the motor command will be modified by:
M1 = (10*M1 + M1Comp)/10 = (10*100 + 1666)/10 = 2666/10 = 266 (boosted from 100)

Now, suddenly center the stick to 0% motor command. Assume that strong initial deceleration also draws (negative) 100 Amps. Then:
M1Comp = (10*-1000*50)/300 = -1666, but the compensated motor command will be:
M1 = (0 -1666)/10 = -166.
This is the same difference from uncompensated as when accelerating, but of smaller absolute magnitude. Not really of any importance when going straight ahead, but I don't see offhand how this will interact with the acceleration mixing algorithm when turning and decelerating. I hope I can puzzle it out. One idea might be to give an extra "pulse" of compensation when changing motor direction (not chair direction, but motor direction), but that's an idea that could easily be totally useless.

But, also see the next section. With -100 Amps deceleration, you have reached the current sensor's measurement limit.

In other words, acceleration rate, (and deceleration rate), seem to increase over time, and it means setting them too low to avoid excess. It means a delay at the start, and getting flipped out over the rear as they build and you don't notice! Is this some maths thing? (Or the affect of 45V and full stall current available at half pulsewidth and 8mph?)

I'm wondering if you aren't running into some "limits", either those set in your profile or an important limitation of the current sensors. I'll assume that you are not running into the Roboteq's limits (though I could be wrong), but the current sensors are another matter. They read only to +/- 100 Amps. If you are drawing over 100 Amps when you start accelerating or start decelerating, you will get too little compensation for the real current draw, then as the current falls to less than 100 Amps the compensation gets larger as a fraction of the compensated command. One test for this would be to drop your accel/decel values way back, so that you are drawing less current, and see if the response becomes more linear over time. It won't be as jackrabbit, but may not have this change in acceleration with time. I have accel/decel at 5000, but with 5 mph gearing that's the same g accel as you would get with 5000/3 = 1670 -- a good bit lower than what you have set.

I need a separate way to set forward (and reverse?) acceleration/deceleration.
And a separate way to set turn acc/dec that needs to be much higher.

But that's what the MixAccel algorithm does, at least when increasing or decreasing turn rate. That is, if going from a forward turn to straight ahead or center stick, the deceleration of the inside wheel is reduced, and the deceleration of the outside wheel is increased. Of course, deceleration of the inside wheel can't be reduced below 0, but deceleration of the outside wheel (when using MixMode 2) is increased first proportionately to the commanded change in turn rate and then by adding in the amount that the inside wheel should have been decelerating at less than 0. Deceleration less than 0 should really be an acceleration, but the Roboteq decides whether you are accelerating or decelerating by whether the new motor command is less than or greater than motor power. If we wanted the inside wheel to actually speed up (further sharpening the turn deceleration) we'd have to tell it to actually change the motor command value rather than the applied deceleration. I'll think about this and see if I can come up with a safe way to do so (I think it would be easy to get a runaway turn-reversal out of trying to do this).

Alternatively, we could have add a TurningAccelerationIncrease parameter, so that if the chair is turning accel and decel are just turned up higher when turning than when going straight. This would probably be pretty easy to do. Perhaps something like this pseudo-code:

Code: Select all

TurnAccelBoost = a user set number from 0 to 100 (percent of base acceleration by which to increase it while turning)
Turning = abs(M1Power-M2Power) 'abs because we don't care whether we're steering
TurningPercent = (Turning*100)/(abs (M1Power)+abs(M2Power))
AccelBoost = TurningPercent*TurnAccelBoost/100
Accel = Accel + (Accel*AccelBoost)/100

or to give an example, suppose M1Output is 500 and M2Output is 200 - a fairly fast, forward right turn and that we've set
Accel set by user to 2000
TurnAccelBoost = 50 '50% of maximum increase during turns
Turning = 300
TurningPercent = (300*100)/700 = 300/7 = 42
AccelBoost = (42*50)/100 = 21
Accel = 2000 + (2000*21)/100 = 2000 + 420 = 2420

or, for a stronger effect, with TurnAccelBoost = 100 and all the rest the same, during this turn Accel is increased from 2000 to 2840


Might want to add yet another parameter so that the amount that accel is boosted for turning goes down as speed goes up (especially for FWD drivers).

Give me a few days.

Ciao,
Lenny

[LROBBINS]

Hey John, I really could use more edit time to clean up these long complicated posts!

[Burgerman]

As its set at the moment, if this helps, the stick is very sensitive and responsive in all 4, 45 degree segments.

So initial acc/turn in all 4 corners is sharp. However. The other 4 corners, that means back, forwards, left and right (12, 3, 6, 9 oclock) are much softer.

Turning on the spot takes a while, (3 or 9 o'clock) to gather speed. And when released it continues to turn for maybe 1/3 to 1/2 a second. I need it to stop turning instantly or close to it. If moving forwards and initiate a turn, or release a turn (setting 600 steermix acc/dec) is very sharp and instant. It has no affect when stationary.

And its odd that forward speed or forward deceleration rate increases over time.

Damping? No affect on this.
Limits in profile? No, I disasbled everything that could affect it, so reaching endpoints, or amp limits etc just "sits" at max Amps for eg.

>>> But that's what the MixAccel algorithm does, at least when increasing or decreasing turn rate.

When not moving back or forward, this has zero affect. Turn acc or dec remains very slow. It has the greatest affect at all four 45 degree stick positions. Where its very sharp if turned up high like 600 or 800.

[LROBBINS]

Yes, this information is helpful and makes me think that the first thing to work on is boosting acceleration for turn-in-place with the boost decaying as speed increases. You are quite correct that MixAccel only affects turning accel/decel when there is also forward/backward movement. It's purpose was to avoid equal accel/decel of both motors with the turn rate not changing at all.

I'll keep this msg brief as ping time here right now is running around 200 msec with fairly frequent time outs (i.e. > 400 msec) as well. Frustratingly slow.

Ciao,
Lenny

[LROBBINS]

John,

Here's a script to try out - no guarantees as I have no way to test it.

Please go through the user settings segment. Note that I have it set to double accel/decel for turn in place when at max turn rate, declining to normal at lower turn rate and as speed increases toward max.

I have set accel and decel to lower values for safety's sake in the face of this boost.

This file still doesn't have a pin number for Brake1.

All of the new code is within the MixAccel subroutine.

It may actually be better to increase accel/decel for turn in place by the same amount at all turn rates, declining only as speed increases. It certainly would be simpler to code, but try the one I've done first.

Ciao,
Lenny