PINNED - Roboteq Controller - developing for powerchairs

[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

[Burgerman]

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.

I agree... To almost zero delay! Because when chair is set to low speed its still a problem. And that reduces steer command too. To around 14% at full stick.

I need chair on blocks to test this I suspect. So monday!
Thanks.

[LROBBINS]

John,

Hold off for a few days on testing the file I sent you. I'm putting this stuff into the CAN version so that I can test it in Rachi's chair (with her not in it). \

Two reasons: (1) it's the only way I can actually test it, and (2) because I specified EXPLICIT in the CAN script, it will make sure I don't use the same variable name for two different things - and I've already found one case of that in the file I sent you. With EXPLICIT every variable has to be declared with a DIM statement or it won't compile, and if you attempt to put in two DIM for the same variable it won't compile. Makes for a bulky file with a long series of DIM at the top, but since all variables are global in MicroBasic (that is, they are seen in every part of the program) it's the only way to make sure there are no conflicting uses in different places.

But, we have guests here now so I may not get any time with Rachi out of the chair until Tuesday.

Ciao,
Lenny

[Burgerman]

OK. Will do, cant do much without someone here that can help anyway. So no hurry.

It behaves, in the 12, 3, 6, 9 o'clock positions as if the stick or set to low acc/dec and instead of controlling speed of forward or turn speed, it controls quite low acc rates, that build over time.
The other 4 "corner" stick positions, are quite sharp and instant even from a standstill.

An example of this is when accelerating from standstill. Full stick, no wheelie, and gentle smooth takeoff after say .3 of a second. Accelerates harder over time until it tips you out at about 8mph or so! Thats the opposite to a PG system, where initial acc is quite instant and acc is fast (wheelies from standstill), and acceleration decreases with time/speed as the motor starts to pull less amps due to RPM.

If you decelerate from full speed, by releasing stick, a PG system, almost instantly decelerates at constant RPM/SEC rate. Deceleration is constant. Roboteq shows a relatively slow initial "delay" then increasing deceleration as you slow down, chair slows and the tyres start to get noisy. It makes it smooth! But laggy, and hard to set correct acc/dec rates. And it does the same thing with turning on the spot. But its slower to acc/dec because you are using much lower motor pulsewidth at full stick.

The other four 45 degree (mixed input) corners, show quite fast sharp response. Steering at speed is reasonably predictable (steermixacc set to 600) but gets worse at slow speeds. To the point of being very unpredictable at low speed, and dangerously so on zero turns.

Doing this for eg (link below) as I do all day, is not remotely impossible with the roboteq at the moment, as it responds too slowly initially on forward acc. And too slow to initiate turns at the "ends of the run". Worse, it doesent stop turning after doing the 180 degrees to point the opposite way, as I then centre the stick and gun it forwards again. The result is I will hit a wall because I end up going 15 to 20 degrees more than 180 I expected to get! I know this isnt what most people expect to do but it highlights the control difference issue.
http://www.wheelchairdriver.com/gopro/control.mp4 (PG control)

This is as clear as I can describe it!

The result is it feels a bit unsafe and unpredictable compared to a zeroed out non delay PG system. And feels like one with accelerations/decelerations built in in north/south/east/west stick movements. But not in the corners!

[BounderGimp]

OK. Will do, cant do much without someone here that can help anyway. So no hurry.

It behaves, in the 12, 3, 6, 9 o'clock positions as if the stick or set to low acc/dec and instead of controlling speed of forward or turn speed, it controls quite low acc rates, that build over time.
The other 4 "corner" stick positions, are quite sharp and instant even from a standstill.

An example of this is when accelerating from standstill. Full stick, no wheelie, and gentle smooth takeoff after say .3 of a second. Accelerates harder over time until it tips you out at about 8mph or so! Thats the opposite to a PG system, where initial acc is quite instant and acc is fast (wheelies from standstill), and acceleration decreases with time/speed as the motor starts to pull less amps due to RPM.

If you decelerate from full speed, by releasing stick, a PG system, almost instantly decelerates at constant RPM/SEC rate. Deceleration is constant. Roboteq shows a relatively slow initial "delay" then increasing deceleration as you slow down, chair slows and the tyres start to get noisy. It makes it smooth! But laggy, and hard to set correct acc/dec rates. And it does the same thing with turning on the spot. But its slower to acc/dec because you are using much lower motor pulsewidth at full stick.

The other four 45 degree (mixed input) corners, show quite fast sharp response. Steering at speed is reasonably predictable (steermixacc set to 600) but gets worse at slow speeds. To the point of being very unpredictable at low speed, and dangerously so on zero turns.

Doing this for eg (link below) as I do all day, is not remotely impossible with the roboteq at the moment, as it responds too slowly initially on forward acc. And too slow to initiate turns at the "ends of the run". Worse, it doesent stop turning after doing the 180 degrees to point the opposite way, as I then centre the stick and gun it forwards again. The result is I will hit a wall because I end up going 15 to 20 degrees more than 180 I expected to get! I know this isnt what most people expect to do but it highlights the control difference issue.
http://www.wheelchairdriver.com/gopro/control.mp4 (PG control)

Are you thinking of making a wheelchair for diving? Can't get link to work. Your bm3 is looking good!

[Burgerman]

Driving?

Link works now! My bad...

[LROBBINS]

John,

I did get some time to try the CAN version of the revised script on Rachi's chair so here's an updated script to try. You will have to go through the user settings section, including defining the brake1pin. The parameters to play with are, the accel and decel values which should be seriously lowered, and the new ones TurnAccelBoost and TurnDecelBoos which I've set at 100 as that's what I've tested on Rachi's chair.

What they do is boost accel/decel during turning, especially turn in place, with this effect going away as forward or reverse power go up and the mixing already in the script gives proper turn performance. I have changed the routine from the first version so that they are effective for even smaller turn values. To give you an idea of how effective this is -- accel and decel on Rachi's chair had been set at 5000 to get decent turn-in-place. With TurnAccelBoost and TurnDecelBoost at 100, I reduced accel and decel first to 2500, then to 1500, and finally to 500 (fully 10-fold less than where it was) and turn in place is still snappy; in fact better than with accel/decel=5000 without this boost. I really can't feel any great difference in fore-aft acceleration to the low speeds we go, but it seems a more uniform process from start to end. This was, however, just for a speed I could feel comfortable with in our living room. Tomorrow afternoon I'll see how it feels going up to 3 or 4 mph, but I do feel safe having Rachi (and you) use the chair with this programming.

Ciao,
Lenny

[Burgerman]

Will test on blocks Monday and on Wednesday will alter seating angle and hopefully test wed evening.

Thanks!

[Burgerman]

On blocks.

Speed pot set to min, or max on my setup results in 14 or 18 % turn command. So both very similar.

OK, new script, or existing one.
I push stick "right" (3 o'clock) suddenly, and it takes a almost a full wheel revolution to reach full turn rate (wheel speed). It doesent just follow the stick. So turn is accelerating over about 1/2 second. It needs to be instant or almost so. Or I dont turn when, or as hard as I wanted, and then jam more in in panic! Much like a commercial chair!

Likewise, when doing a zero turn on blocks, I release the "right" stick, the slowly contra rotating wheels take about a half revolution each before it smoothly stops. That means the chair continues to turn for about 90 degrees seen from above... I need it (the wheels) to stop almost dead when turn is released, so I can punch the forwards stick and go towards the door/gap I am aiming at.

Now, I dont know why but I do not think the new turn acceleration / dec increase when set to 100 does anything at all. And I then tried figures up to 10,000! The wheel still rotates after I release the stick in a zero turn.

So something is wrong I think. Its not doing anything I can detect, and in fact "seems" worse than before. But its not easy to compare on blocks.

[LROBBINS]

I wonder if it would slow down faster under load. However, the effect of these new parameters may also be obscured if you don't lower the basic accel/decel values. 100 for these boosts will double acceleration for turn-in-place, so I'd start by halving the base accel/decel values. Putting in a number like 10,000 for these makes no sense at all - haven't checked, but it might even be exceeding 32 bits at some points in the calculation, which will end up giving a negative number! I think that you are going to have to try this on the wheels, preferably via RC and with some sand bags in the seat. Weight might not make as much of a difference on yours as on Rachi's which has heavily loaded rear casters, but the feel is quite different if she's in or not in the chair and she only weighs ca. 30 kg. In both cases, turn in place on hers stops instantly, just a bit more hesitant starting with her weight on board. Do a bit more testing and if it's not working at all, I'll go over the math and logic again.
Ciao,
Lenny

[Burgerman]

I wonder if it would slow down faster under load. However, the effect of these new parameters may also be obscured if you don't lower the basic accel/decel values.

I lowered them to 500 from 2400. Acceleration and deceleration is really slow. Turn acc/dec seems to be exactly the same. Its made to feel more extreme, because the four 45 degree corners are pretty much lag free, so feel very instant.

What is needed is something that means that there's no delay at all on turn axis. Because even with my 13 stone carer sat in it, and me driving it by RC on my drive, (safer than sandbags because there a kill button!) it shows the same behaviour as I see on blocks.

What's needed, is for its steer axis to be as instant as possible. Any amount of acc/dec or delay is wrong. Needs to be like a car steering wheel.
Because even 1/4 of a wheel revolution delay in either turning, or not turning, or stopping turning after I release the stick, is very much noticeable. The chair takes off in the wrong direction. Its not as noticeable when moving - but really noticeable when manoeuvring in tight areas, or trying to fly around through doorways and doing U turns like a lunatic in the house. I cant!

The steer axis, should only control wheel speed directly, and its acceleration should be as short as it can be. It should achieve the turn rate I pick with the joystick, instantly. Or at least as fast as my fingers on the joystick. Because I can get it to keep turning left while I have got a lot of throttle and some right stick in as I accelerate away! Hence the door frames are going to get it. Turn rates (not acceleration rate) must keep up with the joystick directly to maintain directional control.

If the steer axis has double the acceleration/dec of the forward/reverse, when set to 100, then its a great many times too slow.
It takes 5 seconds to get to 16mph. But it needs to take, 0.1 sec max to achieve the turn (rotation) speed you desire.
That's a difference of 50x ?

I bet you wish I was still on my bed!
This has been worrying me for a bit, but I presumed I could dial it out somehow, and never got around to testing because of people, and my dog dying, a mass of problems with local authority care budget cuts and assessments and arguments, and a 5 week session stuck on my bed amongst a load of other stuff... Makes me wonder how will hasn't had these problems. I suspect that he hasn't experienced a properly programmed chair, and so thinks its good, because its better than his permobil etc. But there's a fundamental control issue here somewhere I think.