PINNED - Roboteq Controller - developing for powerchairs

[LROBBINS]

I'm attaching a new file. I don't really expect it to be useful, but I need your help in trying to figure out why it doesn't do what I think it would do. It gives me very strange results when simulating, but I don't know if it's because I made a mistake in what I wrote, or whether it's because the MotorSimulation routine I wrote years ago is giving odd results. So I'd like you to download this one and test it as follows:

Adjust PowerAccel and PowerDecel, and BoostLimit if necessary, going straight forward and back.

Adjust TurnAccel and TurnDecel going straight left and write (i.e. just turn-in-place).

Now, see what happens if you accelerate into a turn, accelerate from a turn in place to straight forward, decelerate into a turn and decelerate from a turn into stick center. Just describe what it does at the start of each of these four maneuvers, and post graphs of each if you can. Then, does changing PowerAccel or PowerDecel or TurnAccel or TurnDecel - even setting all of them to 0 - have any effect at all on the start of these maneuvers?

If I can have access to Rachi's chair this evening, and my hips and legs stop hurting enough that I can do it, I'll get it up off its wheels to try this as well. But as of the moment I don't yet have a CAN version of this, and I'm really too sore to think of doing anything at all physical so I'm asking you to do it for me even though I don't expect this program to work correctly.

Ciao,
Lenny

[Burgerman]

Council officials just left after going through 2 massive boxes of receipts for wheelchair parts. They ignored it first time because they don't understand it... Now they are even more bewildered! But they have to accept these receipts as additional disability expenditure. Since that's what they are.

So I have a headache trying to explain to 2 women what all these piles of receipts for tiny parts, connectors, bolts, bearings, hobby stuff, etc is actually used for. On the plus side they like my auto mower! And allowed it.

But now I can relax, carer here in 1 hour, and she can put chair back on blocks. So test in a short bit!

[Burgerman]

Code: Select all


Accel = 1500
Decel = 1500

AccelMix = 600
DecelMix = 600

TurnAccel = 270
TurnDecel = 350

PowerAccel = 300
PowerDecel = 100
BoostLimit = 150 

Set like this, it seems pretty good.
Strange how I had to reduce decelboost by a large margin.
And turn acc needs less boost than turn dec.

Both of these are set very "sharp" and may be too high in use, to get over that initial "turn/go" lag where it keeps turning for a bit.

[Burgerman]

Turn on the spot. Then turn and go.

Note that the backward turning wheel now accelerates much better initially. And continues to do so after the 0 point. The other wheel stays level though. It should dip a little I think. But they shouldn't meet at the 0 position -- should meet at a low positive forward speed if turn and forward are "mixed" (I think!) Or am I wrong?

[Burgerman]

Now, see what happens if you accelerate into a turn, accelerate from a turn in place to straight forward, decelerate into a turn and decelerate from a turn into stick center. Just describe what it does at the start of each of these four maneuvers, and post graphs of each if you can. Then, does changing PowerAccel or PowerDecel or TurnAccel or TurnDecel - even setting all of them to 0 - have any effect at all on the start of these maneuvers?

Normal straight acc and deceleration are correct. And boost works on both.

Turning while acc or decelerating is unaffected by those settings. It affects motors symetrically. And correct.

Accelerating/turning with stick at 45 degrees is the same, and correct.

[Burgerman]

I wont post curves from the first 4 tests yet.

I can describe. Set as above, all 4 scenarios behave symmetrically and predictably and as I would want, with the exception of the take off fast from a turn on the spot. Which we all saw already.

Test 1. TurnAccel set to 0
This makes turn acc on the spot seems slow. And its more difficult to tell (unsure) but no obvious affect at speed? Does not change the curve for "zero turning and go forwards" at all. So only appears to affect zero turn acc.

Test 2. TurnDecel set to 0
Turn on spot, then GO. This makes it keep turning forever after I choose to go... See bottom part of graph. Much SLOWER turn decel, than a simple zero turn stop would be because of yellow line being flat instead of dipping (slowing) a little. Doesn't seem to make any difference at speed.

[Burgerman]

3. Setting PowerAccel to 0 has no affect anywhere I can see. Other than losing that boost initially in a straight line.

4. PowerDecel at 0 also no affect visible.

Will try setting these to high figures...

[Burgerman]

power acc set to 3000 makes it interesting. Or it will snap something...

Turn then go, results in the yellow (or both?) motors accelerating suddenly, while still turning. Probably correct but it means you accelerate forwards before turn stops.

But if the yellow line dropped to meet the red or partly so it would be better? Thats what I would expect to happen with simple mixing.

At this point previously, you said you had a better way, and we went on a wild goose chase which fixed it, but caused mixing at speed to be only on one motor... !

[Burgerman]

Something I noticed that may help.

The dec boost we get when suddenly releasing the stick at speed, is markedly greater if I am turning slightly. Note graph above. That's more pronounced that a straight single line gives. Compare to the 2nd graph above. Same setting of 100.

If this script is safe, I may use it or at least leave it on as it does most stuff right! Why do you say you don't expect it to work?
The turn and go delay? I think its the best so far. Its similar to the old script with turnboost acc/dec but has forward acc boost too. So its the most usable.

[LROBBINS]

Good morning,

I'll be sending you yet another script to test later today, but for now I want to comment on what you found yesterday.

If this script is safe, I may use it or at least leave it on as it does most stuff right! Why do you say you don't expect it to work?

I didn't expect it to work because the numerical results of the simulation are just too wild. Your tests say that this was actually just a property of the simulation, not of the MixAccel: subroutine. In other words, I actually did good, it is behaving as designed and it would be safe to use. However, that script does have some restrictions that really have to be removed and tested.

In particular, TurnAccel (and TurnDecel), as you've in fact seen, are effective only if the speed is unchanging. It works at 0 speed, and it would work at any other constant speed if a human hand could actually hold speed constant within 0.1%. The new script will have the option of making it also work while speed is changing, but that will definitely need some tuning to get it right.

Similarly, PowerAccel (and PowerDecel), again as you too have seen, work only if the turn rate is unchanging. So it works when you move the stick straight forward, and it works when you move the stick right back to center (or at least into the deadband of steering), but it doesn't work when turning unless you could hold a nearly absolutely fixed turn rate. The new script will have the option of making it also work while turn rate is changing, but that too will definitely need some tuning to get it right.

Lastly, you're quite right that boosted decel from straight ahead (which actually uses PowerDecel) is much milder than decelerating from a high-speed turn. From a high-speed turn, PowerDecel presently isn't having any effect, and the strong change in this case is caused by what DecelMix does. When we get PowerDecel working while turning, we'll also have to adjust how DecelMix gets applied. Today's script will have a first stab at that too.

I have to leave now to go get Rachi (she's about 25km from here at the moment), so I'll get back to this later.

Ciao,
Lenny

[LROBBINS]

to continue ...

power acc set to 3000 makes it interesting. Or it will snap something...

I think that this is akin to setting motor resistance to 100 for a 50 mohm motor. Don't do it.

Lastly, the matter of accelerating (or decelerating) out of a turn. Consider the following drawings:

What's the same and what's different in these two? What's the same is that it takes exactly the same amount of time to stop the turn in both cases. What's different is that in the top case you start to accelerate while the turn is going away, while in the bottom one the chair will stay immobile until the turn has gone to 0. If this were decelerating from a turn, in the top one you'd start to slow while the turn was going away, and in the bottom one you'd continue going full speed until the turn had ended. My intuition says that the top way is better.

OK, back to testing the script I'll send along later.

Ciao,
Lenny

[Burgerman]

Neither are correct as such. Or maybe they are and its me!
The point is, it should vary depending on how much go (acc) you add.

If you accelerate forwards slower (or add some super fast turn rates - acc/dec) it should do something that is a mix of the two. That is the two lines should converge above the zero point as they start to climb. It doesn't.
It always puts all the acceleration onto the one slower wheel - leaving the forward going one at constant speed while the turn ends. (I think?)

Will test that now.

[Burgerman]

Latest script.

Setting accel and decel to 500 slow...
And turn accel and decel 9900 fast...

Causes 2 things.

1. MASSIVE forward acceleration if stick not central.
2. In a Zero turn, and go: forward wheel still maintains constant speed while turn ends.

[Burgerman]

Like this.

(I obtained this by looking at motor command, rather than motor power.)

This is what we should be seeing to a greater or lesser degree depending on set turn dec, and motor acc rates. This is correct.

The thing is I am not very sure what "motor command" is actually showing us. Is it just JS input? Either way its correct. It has correct limited turn rates, but has way too much motor accel/decel rates. But the curves are the correct shape!

[LROBBINS]

MotorCommand is just joystick position modified by MotorCompensation. Acceleration and Deceleration don't enter at all. Move the joystick quickly, and the curve will go up sharply, add the effect of motor compensation and it will be curved - rising faster (if not already vertical) when there's lots of current draw, following hand movement when there's not.

If you look very closely at your real curves from yesterday, not my drawing, you'll see that, although the horizontal (outside wheel) MotorPower line does not dip downwards, the two lines actually do curve a tiny bit at the end to join up with the final straight-ahead acceleration. Although the crudeness of my motor simulation doesn't actually let me demonstrate this, I think that the script I'm sending with this post will have a much more prominent curvature to those converging lines - but you'll have to tell me as I can't see that here.

With the script you've been using yesterday and today, the turn boost only works when speed is constant, the speed boost only works while turn rate is constant, and initial changes are exaggerated if both are changing, such as from decelerating to center stick from a fast forward curve. The new one lets turn boost work even if speed is changing, and speed boost work even if turn rate is changing, and partially evens out the difference in amount of boost when only one is changing vs. when both are changing (partially, because it's a fixed approximation to what's needed, rather than something that adjusts itself on the fly - that would be hard to code, and probably impossible for me to verify without a controller and motors).

Because there are a number of things to check out, I've added four TRUE or FALSE parameters to let you turn various behaviors on and off. They are:

Code: Select all

SpeedBoost = TRUE
UseSpeedMixAdjust = FALSE
TurnBoost = TRUE
UseTurnMixAdjust = FALSE


and these particular TRUE/FALSE values make it behave exactly like the script you've been using. That is, there's speed boost at the start of acceleration and deceleration (as long as turn rate is 0 or otherwise constant), and there's turn boost (as long as speed is within the BoostLimit band and quite constant), but there's only the old mixing if both speed and turn rate are changing. You can turn off either or both of these by setting SpeedBoost and/or TurnBoost to FALSE, and with both of them off it will behave the way things were a few weeks ago before we started on all of this - just the mixing of acceleration and deceleration.

UseSpeedMixAdjust and UseTurnMixAdjust are set FALSE, but if you set one or both to TRUE you will get speed boost even when turning (which should be less aggressive than what you have now decelerating from a fast forward turn), and/or TurnBoost even when speed is changing (which should improve turn-in-place if the stick is not quite centered fore and aft).

My suggestion for testing is to start with these TRUE/FALSE parameters as set in the attached script, but adjust the other parameters to the values you've found most congenial in the "a" version you've been testing yesterday and today. Then change SpeedBoost and/or TurnBoost to FALSE, to see what changes with those procedures inactive, then turn them back on.

Finally, change UseSpeedMixAdjust to TRUE, leaving UseTurnMixAdjust at FALSE. Then do the reverse. Then change both of them to TRUE. Let me know how things behave in these three different conditions WITHOUT CHANGING ANY OF THE NUMERICAL PARAMETERS. If these cause problems, I may need to make coding changes before you can successfully tune the numerical settings, so I absolutely need to know what happens with these just turned on with the same parameters that were best when they were off. And, even if coding changes aren't needed, I may be able to take a look at how the various settings interact (they WILL interact) and suggest a particular order in which to make adjustments.

After checking behavior without changing values, and letting me know how that goes, feel free to adjust the values as you deem best. By now the routine should be pretty familiar (presuming there are no coding changes needed, and the interactions are manageable) -

Accel and Decel to set final acceleration and deceleration straight ahead,

PowerAccel and PowerDecel to get the initial acceleration and deceleration you want,

BoostLimit to avoid either spike or sag of acceleration just after setting out (will almost surely need to be changed when actually driving),

TurnAccel and TurnDecel during 0-throttle turn-in-place.

Then, adjust AccelMix and DecelMix to get good turn response while going at an intermediate speed.

Finally, describe what's happening as you start to accelerate into a forward turn, start to accelerate straight ahead out of a turn-in-place, start to decelerate from straight ahead into a turn, and start to decelerate from a forward turn to center stick. Any changes needed for these will have to be made in the code.

Have fun,
Lenny

[Burgerman]

Will be in 1 hour before I can get to it then I will test!

[Burgerman]

My suggestion for testing is to start with these TRUE/FALSE parameters as set in the attached script, but adjust the other parameters to the values you've found most congenial in the "a" version you've been testing yesterday and today.

Done that. Its behaving extremely oddly... I cant put my finger on what its doing.

Right stick ONLY, brake clicks, wheels don't move... Right stick + a tiny touch of forward or reverse, and it turns, one wheel. Right stick and a touch of reverse and it turns the other wheel. Once wheels are turning with right stick, then they keep turning as I acc/decelerate.

Forward stick ONLY. No movement. Tiny bit of stick turn and we get forward acc.
Reverse, the same. No movement unless some turn.

Expected behaviour? Or some error? Very hard to do anything useful. Should I continue?

[LROBBINS]

No use doing anything further. I'll cross check the file I sent you against the one I used for the simulation and against the last one I had sent you to see if I can spot the problem.

[Burgerman]

Left turn seems to work... Right turn nothing without some forward or reverse...

[LROBBINS]

John, could you post the user settings that were in the last program and that are in this one? So far, I've just run the simulation version with UseSpeedMixAdjust = FALSE and UseTurnMixAdjust = FALSE and it's behaving exactly as expected.

Another thing to try at your end is to reload the older script and make sure it's still working. If it is, reload the new one again and re-check. i.e. double check to be sure the problem's in the script and not in the download thereof.

[Burgerman]

OK User settings from the older one that works. "John 12-01-2015 temp2a revised"
This is a TXT file.

USER SETTINGS A WORKS.ZIP

(5.95 KiB) Downloaded 201 times

Just retested, John 12-01-2015 temp2a revised working fine.

And re downloaded and tested John 12-01-2015 temp2b revised not working...

[LROBBINS]

I am completely flummoxed.

I ran the current program in the simulator version with UseSpeedMixAdjust = FALSE and UseTurnMixAdjust = FALSE; works as expected

Used WordPerfect to compare the simulator and regular versions of "John 12-02-2015 temp2b revised" - the only differences are in the stuff for simulation, the motor control stuff is all identical

I used WordPerfect to compare "John 12-02-2015 temp2b revised" with "John 12-01-2015 temp2a revised". I did find one mistake in the new one, but it would only affect left turns with UseTurnMixAdjust = TRUE. Otherwise, the only differences are in the segments that are only active if UseSpeedMixAdjust = TRUE and UseTurnMixAdjust = TRUE.

I compared the parameter list you posted from the working program with what I had in "John 12-02-2015 temp2b revised". Other than differences in numeric values, all was the same EXCEPT for AlarmPin: it's 6 in mine and 5 in what you posted. I think the "5" is a typo because SpeedPotPin = 5!

I downloaded the copy posted on the forum and compared it with mine. There were no differences in the text, but I did not run a binary compare so there could be some hidden corruption.

I am attaching a new file with that one error (in left turn with UseTurnMixAdjust) corrected and parameters matching what you posted (except for AlarmPin = 6). Download this to the Roboteq and see what happens. If it too doesn't work, I am completely at a loss.

Buona notte,
Lenny

[Burgerman]

Alarm pin is unused at the moment but it is 5. DOUT 5
SpeedPot is Analog in 5

One script works, one doesn't...

[LROBBINS]

I'll go through and change that pin number in my files.

Have you tried the file I just posted?

[Burgerman]

New script works, pin 5 or 6 for alarm...

And those new false/true things are doing interesting stuff. Will need to do a lot of testing.

So will test. Trouble is I now have to go out as I am meeting my friend in the pub. Will test ASAP tomorrow.

[LROBBINS]

OK, so the one that didn't work had somehow been corrupted. Whew, I was beginning to think I had done something supremely stupid. I have to load the dishwasher and get to bed, so signing off till tomorrow.
Ciao,
Lenny

[Burgerman]

Maybe that 1 error you fixed? I downloaded it twice. Either way its making sense.

I wont test. Back from the pub. Need logic and sharp brain to figure things out.

One thing. Does this have the errors that you said existed still in it regarding acc and centralised stick?

In other words is it usable? I have to keep moving the chair back out of my room by RC and generally resort to the safe one I used for ages.

[LROBBINS]

Maybe that 1 error you fixed?

Exceedingly doubtful. A line that should have been:
PercentDiff = (TurnDiff*100)/abs(targetTurnRate)
was
PercentDiff = (TurnDiff*100)/targetTurnRate
so PercentDiff would have a negative value if accelerating (it's in a part of the turn-boost segment that is IF acceleration) and turning left, and would affect nothing else at all.

One thing. Does this have the errors that you said existed still in it regarding acc and centralised stick?

I don't know what you are referring to. Perhaps the "approximate" correction of overly exuberant initial deceleration when going from forward turn to center stick? This should be improved when you turn UseSpeedMixAdjust = TRUE and UseTurnMixAdjust = TRUE, just probably not exactly identical to deceleration from straight ahead.

In other words is it usable? I have to keep moving the chair back out of my room by RC and generally resort to the safe one I used for ages.

You already know what its behavior is like with UseSpeedMixAdjust = FALSE and UseTurnMixAdjust = FALSE, because that's equal to the last one that you'd decided was pretty good. I would do a first check with those parameters changed to TRUE, because it should be even better, but, of course, until tested there could be surprises. Once you know that just turning those on doesn't cause mayhem, I'd consider it safe to use, especially with the speed pot turned down and going slowly.

I am still curious to try to know why the previous script didn't work. Could you e-mail me (not post here) a copy of the file in your PC that you had downloaded to the Roboteq that didn't work so I can take a look at it?

Ciao,
Lenny

[Burgerman]

Yep. As soon as I get off this bed/dressed/ etc. Waiting for carer. As long as I didnt delete it. I may have done. But theres a copy on here.

[Burgerman]

Don't like that!

UseSpeedMixAdjust = TRUE.GIF