PINNED - Roboteq Controller - developing for powerchairs

[Bearded_Blunder]

That link http://www.precisionmicrodrives.com/app%20...%20m-back-emf describes how one can calculate RPM of a rotating motor under steady load. It does not describe the situation of the stall-to-near stall state when the motor just starts turning (where we need to strongly boost PWM change per unit time=what Roboteq calls acceleration), nor does it describe what happens when the load suddenly changes, such as climbing over an obstacle like a tree root.

We can calculate the back EMF by measuring the current in steady state with no load (emphasis added) and comparing it to a calculated value for the stall current. We can then use this value with the no load speed and the motor’s constants to calculate the speed for the given back EMF.

and

We now have a way of calculating the back EMF and then in turn the speed of the motor from the measured current draw.

That is, if stall current is not contributing to the "measured current draw".
Ciao,
Lenny

There's no need to calculate or measure backEMF for a stalled motor, or one running at negligable speed, in that situation, it's zero/negligable, therfore if backEMF < (some low value you set) then motor is stalled or running slow ... apply boost / don't accordingly as determined by the backEMF at the time and what the controls are calling for, this solves stalled / stopped / very slow.
For the other situations you need rate/direction of change of backEMF as well as the value now if it's falling rapidly, you just hit an obstacle and got slowed, if the operator wasn't throttling back compensate. A sudden rise from one motor would indicate a loss of traction that side (wheelspin) you'd see a drop in current at the same time, and could base your control script decisions for that situation off either, you can determine lots of things from backEMF, if you choose to.

By using the existing instant value of backEMF (which is nothing exept a measure of spindle speed, directly proprtional, at least with permanent magnets things get weird with field coils where you can alter the field strength) and the rate and direction of change, you can pretty much apply boost or remove it in any situation you can define.

If you want boost (for example) below 2mph road speed determine the value for 2mph, which is a constant for a given motor at that rpm, and apply it when the value is lower & the operater is calling for more "go", apply more/less/none at whatever other break points you want.

Just because you're already using it for motor compensation (mimic more stick when it spikes down until it recovers then remove extra boost) doesn't mean the value is useless for anything else, any more than the output from a sensor on yor car's flywheel can't be used both for engine management and to drive a dashboard rev counter at the same time. BackEMF is potentially one of your most useful parameters for all kinds of things, if you have it sensed with sufficient accuracy and resolution you can base lots of your control off it, should you choose to.

It's also a less than ideal parameter to use for motor compensation, because the situations where you really need compensation are the ones where it has tiny/negligable values, you're not going fast enough, generally, when climbing thresholds etc., for it to be significantly > 0 without massive accuracy and resolution on the measurement, though the historic value *just before* you hit the bump might be useful as an indicator on what speed to not exceed when you compensate .. i.e. when to cut the extra motor input off.

It's not the only parameter you can use to make the determination to boost or not, you can have a perfectly controlled motor without ever referencing it directly for any purpose at all if you reference other parameters instead, or base nearly everything off it if you have it accurately and in realtime, designer's choice, but it certainly can be used to determine your motor's spindle speed, and you could base control logic off it for if things should or shouldn't happen above and below certain speeds. Or you can fit a hall sensor on the spindle and use measured RPM, neither of which will be very accurate at really low speeds/stall, there's a reason wheelchair controllers do motor compensation the horrid way they do, it's less horrid than the easy alternatives.

[Burgerman]

There's no need to calculate or measure backEMF for a stalled motor, or one running at negligable speed, in that situation, it's zero/negligable, therfore if backEMF < (some low value you set) then motor is stalled or running slow ... apply boost / don't accordingly as determined by the backEMF at the time and what the controls are calling for, this solves stalled / stopped / very slow.

Back emf on my motors/voltages/controller reach the controllers max amp limit right up to 8mph, dropping only afterwards. If allowed.

[Bearded_Blunder]

How much current you *can* stuff through your motor is irrelevent to this, backEMF is an opposing voltage (generator effect) when the motor is spinning, yes you can stuff the current through by increasing pulse width (effective applied voltage) or actual applied voltage at 8mph on your chair, but you do have to do one or the other to do it, the same minimum pulse as pulls max current stalled won't do it, there's an opposing voltage effect which isn't present at stall (backEMF).

So you tell 8mph by the fact backEMF is non-zero, and twice what it was at 4mph. Assuming of course, as stated in my first post on this thread, that you can determine the value in realtime, since a later reply stated you're using the value in your compensation, I'm assuming you know/monitor the ongoing value and it can be checked by your control script. If not, then you either need to, or to add an alternate method to determine spindle speed and use that instead. Which requires extra hardware you don't actually need.

[off topic] DC motor speed control is horrible, now AC motors simply vary the speed the field rotates. Shame they hate stopping and starting. [/off topic]

[edit] and if that makes little sense, it's because I replied to a post that got edited while I was responding. [/edit]

[Burgerman]

the same minimum pulse as pulls max current stalled won't do it

Obviously.
Not real figures but for clarity lets say:
At stall, they take 150A each at 22V which is about right. I have 44V battery. So that's a 50% pulsewidth.
At this point battery Amps are half of motor amps.

Chairs max speed is 16 so that means it will (could) still pull 150A at 100% pulsewidth at 1/2 speed, 8mph, at which point battery Amps = motor amps.
From now on pulsewidth remains 100% and Amps fall to zero (about 6 in reality) at full speed.

[LROBBINS]

The only way we have to estimate back EMF is from the measured current and (known) motor resistance. If that current is limited by the controller, or the measurement is limited by the sensor, the estimate is not exactly useful. In any case, calculating speed itself doesn't do us much good. What we have to do is modify Roboteq's "acceleration" (deltaPWM) in accord with RPM, but as RPM is proportional to current we might as well just use current without calculating RPM, which takes care of the stall/near-stall situation as well without making it a special case. We actually have to eliminate the boost in the part of the curve where current is rising with increased speed. (Of course, as you said I'm using the current measure for two different things, but I have no problem with that.)

In any case, that's what I'm trying to do at the moment and, JOHN, I'd like you to take a look at the following graph that shows the results of a simulation of my latest code:

I think that the "knees" in the circles are what you are aiming for.

On acceleration, initial boost tapers off as current falls followed by constant acceleration until full speed. The shape of that knee depends on the actual current curve, and my simulation of that is probably not very accurate, so the curve and transition will be different with real motors, it's just the "shape" of this to consider for now.

On deceleration, where current is decreasing from beginning to end, I've assumed a shallower curve to the decrease of current than during acceleration from 0, so the knee is softer.

(Ignore the little joggle in the turn=0 stretch; I can get rid of it, but it probably wouldn't be noticeable anyway - it's equivalent to 0.7% of stick throw.)

These results come from an algorithm that uses only current (and not the command-PWM difference) for applying PowerAccel/Decel, uses only the difference between targetTurnRate and currentTurnRate for applying TurnAccel/Decel, and holds off changing speed at all until any change in turn rate is nearly entirely completed. It's much simpler than anything we've had before, including what was done for going e.g. from right-forward to left-back, and because it doesn't use the command-PWM difference for speed it won't have the hyper-crossing-zero problem. TurnPot is used to scale the turning accel/decel, but SpeedPot is no longer involved and as current is max. when accelerating even to low speeds, initial acceleration should be the same for small as well as large stick movements. There may be a problem with the start of turn-in-place at small stick movements, but maybe not because turn boost is quite high. However, if there's trouble starting turns with small stick movements, I can also change that to use only current for calculating the boost - when starting, current is nearly independent of size of stick movement.

Time for lunch, then a nap.

Ciao,
Lenny

[Burgerman]

Yes, that is what I am after. I would like a way to fix the wild back stick brake though. Because it will cause locked wheels and a crash even set to 1 and with a tinyest bit or back stick...

The latest algo is already quite usable, other than the back stick braking...

[LROBBINS]

Yes, that is what I am after. I would like a way to fix the wild back stick brake though.

The algorithm used in that simulation will SHOULD also fix this problem.

Just to check my thinking, I re-wrote it a bit to use current for TurnAccel as well as PowerAccel. Whether it really works with controller and motors attached depends on whether my guess about the shape of the current curve has any relationship to reality. Hence, we'll really only know when I get a test script to you, probably later today. In the meantime, however, as you can see here it does seem that one can use current instead of (targetTurnRate-currentTurnRate) to apply TurnAccel.

There's no longer any need to scale TurnAccel to TurnPot because it no longer depends on stick position, just on current. The location and shape of the acceleration knee is a bit different because I moved the transition from curve to straight up from 100 (1.5 steady-state mph) to 200 - I'll make this a user setting in the trial version. I also got rid of the jog in the turn=0 line by delaying starting speed change until change in turn was closer 0 (was at 15 units out of 1000, now at 5 out of 1000). I doubt that it will make any noticeable difference at all in how it drives if acceleration starts 5 msec before reaching final turn, instead of 15 msec before reaching final turn.

This is the one I'll now re-work into a script for you to try.

Ciao,
Lenny

P.S.

From now on pulsewidth remains 100% and Amps fall to zero (about 6 in reality) at full speed.

Your almost described a perpetual motion machine - glad you modified that "falls to zero". Current actually has to fall to approximately the no load current at some speed and then rise again because friction and air drag go up with speed. Having a "static" brain, I can fairly well understand steady-state motor behavior (neither accelerating nor decelerating and at constant load). When one goes from that to a dynamic situation, static thinking and simple algebra no longer suffice, and as I've noted I never wanted to learn how to deal with differential equations.

P.P.S. I have another spare time project for you (or Will or a volunteer). You periodically remove motors from WC service. How about hanging on to a couple of them, attaching them to a dummy load, and drive them from your chair's wheels to have a (uncalibrated) dual dynamometer so you can actually test things under load. If you hooked them to rollers about the diameter of your wheels (so you don't over-spin them) and have a ramp up to the roller, you'd be able to drive the chair up off its wheels at the same time. Like so:

[Bearded_Blunder]

Ok, this has evidently become moot, but it's still driving me crackers, so for sakes of simplification:

The only way we have to estimate back EMF is from the measured current and (known) motor resistance.

Which obviously works, but at any given speed, in a wheelchair where the motor shared same spindle as the wheel, for simplicity, if you disconnect said motor and coast, you can stick a voltmeter across and measure it a motor is a dynamo is a motor... the voltage you measure doing that is your back emf.

You're using PWM to drive this so your input is present during the "on" portion of your duty cycle, and your motor is disconnected "off" the rest of the time.
The motor is doing no such fancy trickery, it's producing a back emf which is plain boring vanilla DC, so that is present the whole time, with the right kit doubtless measurable during the off part of your duty cycle *if* your control module supported doing it.. it'd give you a value directly proportional to speed.

However, it can be done by calculation, and since I'm suffering brain-fart from some unrelated turmiol I cheated by googling instead of dredging up stuff I've had no real involvement in since college circa 30 years ago. Turns out to be a nice explanation of how to do it over at stackexchange, for a PWM driven system, reading the comments there it's most accurate to fair size motors and reasonably high inertal loads, which seems to describe BM's chair.. and I'm not going irredemably crackers after all...

So should it turn out you do need a reasonable estimate of motor speed for your control script logic at any point.. the how to do it is here:
http://electronics.stackexchange.com/qu ... a-dc-motor

And the fact your measured current is max at umpteen speeds is accounted for, you can still get the answer because your input voltage changes according to the PWM duty cycle (only your full 48v if it's 100% 24 @ 50% 12 @ 25%) given what is there that I could never get the formatting right to post/paste here, getting it is now "Just Sums" as my prof used to say.... (after clicking the link for the formulae).

[LROBBINS]

Bearded_Blunder wrote:

It's also a less than ideal parameter to use for motor compensation, because the situations where you really need compensation are the ones where it has tiny/negligable values, you're not going fast enough, generally, when climbing thresholds etc., for it to be significantly > 0

That's just plain not true. A motor running at low speed with NO LOAD indeed draws very little current. A motor running at low speed under high load, when accelerating or if climbing over an obstacle, draws massive amounts of current. Here's a graph of characteristic curves for a fairly typical wheelchair motor:

Ciao, Lenny

[Burgerman]

Lenny, the difference between my chair and a stock mobility chair (or a car) is that its BHP output increases by double (actually 4x) as it goes from 0 to 8mph.

Draw two graphs like above, with same motor that has a 120A stall at 24V, and a 120A current limit. Then do the same with a 48V supply as the only change and you will see my torque, Amps, acc problem rather clearly!

Which is why it feels so damned fast once rolling and why I limit acc which means slow to initially respond..
Simplicated figures here!

Stock mobility chair 24v stalled = 100A approx. at motor and battery at 100% pulse. And that's 2400 watts max. Acceleration can only decrease from here on. This power level now only reduces as speed increases from zero, and amps reduce naturally, An acceleration curve isn't needed. Even if your acc curve STARTS at 100% pulse then acceleration reduces to HALF by 3mph. And stops accelerating at 6mph completely.

My chair stalled = 100A controller maxed. At 24V at the motor 50% pulse. (simple figures). And so 50A at the 48v battery. As speed increases to 8mph, its STILL 100 motor amps because you are increasing pulsewidth further, and now a 100 battery amps. So power level or horsepower if you want, increased to 4800 watts per motor! That's a 100 percent increase.

At 3mph the stock chair has HALF its acceleration.
My chair has the same as when it started. So 100 pecent harder acc.

At 6mph stock chair no longer acc at all.
My chair still accelerating at the same whoosh rate as before.

At 8mph, STILL full stall current if your acceleration setting allows it to climb to 100 percent in this 5 seconds. At this point on, it behaves like a 8mph stock mobility chair and Amps begin to fall with speed. No longer limited by the controller.

My "initial start" delay, comes from the fact that I have 4x the power, and so must limit acceleration rate to a very low level. To simulate a stock chairs natural stall current then reducing amps over speed directly from the start. It means initial forward stick response is slow to happen, and the real power is in the 5 to 8 mph range. Whoosh!
When you double the voltage you actually increase POWER by 4x.

[Bearded_Blunder]

Bearded_Blunder wrote:

It's also a less than ideal parameter to use for motor compensation, because the situations where you really need compensation are the ones where it has tiny/negligable values, you're not going fast enough, generally, when climbing thresholds etc., for it to be significantly > 0

That's just plain not true. A motor running at low speed with NO LOAD indeed draws very little current. A motor running at low speed under high load, when accelerating or if climbing over an obstacle, draws massive amounts of current.

Making current very useful, if you know the speed is low, the back emf however, is the same for the same RPM, what you'd measure if you disconnected the motor in the hypothetical chair I described earlier and stuck a voltmeter across coasting, the difference being under high load you'd stop instead of coasting before you could measure backEMF, however, that stackexchange link shows how to calculate it, & it could be useful still in determining speed is low, accuracy may suffer though (of determining speed) may be useful enough though to tell you "slow/stopped" and I sit corrected re usefulness therof.

[LROBBINS]

NEW SCRIPT with Turn priority and acceleration boost controlled by current.

Here's a script to try derived from the simulation script that generated the last set of curves. Hope I haven't made any stupid copy-and-paste mistakes in this one.

BTW: for those new to Roboteq scripts and this message board. Roboteq scripts have the subscript .mbs (for micro basic script), but they are actually just plain text files. So they can be opened in any text editor you like to use. If you download Roborun+ however (it's free) you can make changes and at least use "build" to check for syntax errors. This bulletin board, however, as many others, does not allow either .txt or .mbs files, so the attached file is renamed .zip - it's not really a zip file, so just change the suffix back to whatever you wish .txt for notepad, .mbs for Roborun+.

Some notes re. this script
there's a new parameter:
PowerAccelLimit = 200 'value of (M1Power+M2Power)/2 where script transitions from boosted to constant acceleration

some parameters are no longer there:
AccelMix and DecelMix: by giving turn priority over speed (only 3 lines of code), we get rid of all the inner-wheel, outer-wheel biasing (many lines of code and processor time).
PowerCurving is no longer needed because current is already "curved"

I've changed some starting user setting from the last ones you posted:
PowerDecel is set equal to PowerAccel because both are now scaled by current. PowerDecel may have to be higher or lower, however. We may also need to add a PowerDecelLimit (like PowerAccelLimit), but I don't think so.

DecelBoost was set back up to 20 because I think the hyper stop should be gone or at least much less.

Fingers crossed in hope that I haven't made some stupid screwup in the logic.

Ciao,
Lenny

[Burgerman]

If things are controlled by current, then testing on blocks may not be possible or may show something completely different to testing by RC or with a fat user on a ramp?

[Burgerman]

Testing on blocks, shows very mild behaviour.
No signs of any accelerations over the (now increased) base settings at all. Like going back several weeks.

On the graphs, no curves, all dead straight lines. and low acc levels for everything.

Turn acc and deceleration measured in seconds... Even with the 100 replaced with 900, then 2000. (TurnAccel = 2000)
Motor acc increased to the old 2000 to get a straight line acceleration.
Back stick braking now set to 50 for correct level.

Code: Select all

M1Accel = 2000
M2Accel = 2000
M1Decel = 1800
M2Decel = 1800

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

'boost of accel/decel proportionate to difference between MotorCommand and MotorPower
PowerAccel = 150

PowerAccelLimit = 200 'value of (M1Power+M2Power/2) goes from boosted to constant acceleration
PowerDecel = 80

'boost of accel/decel proportionate to diffeence between targetTurnRate and currentTurnRate
TurnAccel = 2000
TurnDecel = 2000

' BACK STICK BRAKING
DecelBoost = 50          'percent of added deceleration to use if Throttle crosses 0.
                         'effect of this is proportional to how far past 0 the stick is moved.

[Burgerman]

Turn on spot, and go, may be fixed however! I think. Hard to say with such slow turn acc/dec levels. And no boosted curve any more.

PowerAccelLimit = 200 'value of (M1Power+M2Power)/2 where script transitions from boosted to constant acceleration

I don't see any boosted behaviour. Because its on blocks? This 200 is a speed position? (200 from 1000?) How do I control the amount of boost?

EDIT...
By turning turn acc up to 10 to 20k (silly figures!) I get turn response (turn acc) up to a good level again. Maybe you missed a 10x maths thing somewhere?

And yes turn seems it may be more than fixed!

But now I get a random runaway acceleration every now and again, where the chair goes from a turn to 16mph in under a second. That scares me!

Theres 3 full stick acceleration lines here (and some braking, reverse etc). See how the third one is much steeper. 3x the acceleration level. It sees current, and we have a runaway! Not sure that basing acceleration on motor amps is at all wise.

[LROBBINS]

Maybe you missed a 10x maths thing somewhere?

Could be, but somehow you have to put a load on those motors to see if lack of current because of lack of load is the root cause. Or at least hook on your amp meter and get an idea of current starting out. I considered max current to be 100 Amps (1000 deciAmp units), but the max on blocks could be much much less almost immediately after the motor starts to move even a few degrees. If the max a moment after starting out is just 100 deciAmps we can add a 10X factor for testing on blocks. If it's just a couple amps (as it is with my old Fracmo motors under no load), we could use 50X for testing on blocks. After I look at the algebra, I'll may add an "OnBlocksCurrentAdjustment" user setting.

Does your clamp meter have a peak hold? That might be helpful. The sooner you can let me know how much the max current draw is on blocks, the sooner I can adapt the code.

Ciao,
Lenny

[Burgerman]

I added to the above post.

But not sure I feel safe using current to control acc rates. Its a self feeding thing... It runs away! See graph above. That would spit you out in an instant. So its lack of current. It will make it odd to drive by RC too. Or when coasting and then acc. Its like a light switch! If it did it only at very low speeds, it may be safer and that's the only place its needed.

Getting a meter onto a motor connection means major surgery, seating all removed etc. But if need be I will. But I can tell from previous testing, that actual current can be either very low, or up to 100A depending on acc rates, and if it runs away etc. But only for short periods.

Quick dirty test, got a man with long fingers to pull out a motor wire from under the seat pan far enough to almost get the clamp on properly. It may be a higher reading than this in reality but:
2 mins wiggling the stick (no runaway) and it reads 23A and a bit peak on the motor tested on blocks.

If I use roboteq built in one, and look at the run screen I see massive differences between motors. One peaks at 17 the other 33A. And they are massively different at constant speed too. The clamp says its about the same however. So the roboteq motor current calculation is a joke! That explains why the current sensors work well and the built in one is rubbish... I think it only measures battery current and looks at pulsewidth. But doesn't know which motor is taking the current. Why?

Because at full throttle it says BATTERY amps are 1A and 5A approx. Well that cannot be correct! Its then tries to calculate motor amps from this...

[LROBBINS]

OK, I've seen your added comments and graph. That's BAD. It may be that current on blocks is so low that the measure is very noisy. Then when you boost accels enough to get some movement, that noise makes things go crazy. Unfortunately, the only way I can think of to find out if that's what's happening is to get some load on those motors: on its wheels by RC if you can't apply a load while it's blocked up.

Here's a script with a minor change of adding an OnBlocksCurrentMultiplier = 10 user setting. If we have a noisy measurement problem, this won't help, however.

Tomorrow I'll work on writing an updated version that doesn't use current, but PWM comparisons, exponential curving, and a (M1+M2)/2 value above which the boost disappears. It can be scaled for TurnPot and SpeedPot, but is still going to have an awful problem at small stick movements unless I (later on, not now) think of some clever way to deal with that. Of course we could also try a stronger curving than 5 (i.e. power of 2), such as a power of 3 or more. I'll put in some stronger curving choices in as well. Whatever I do, I'll have to run simulations before sending it to you, so a change of this magnitude will take some time.

The turning part of the code might now work well with just a fixed multiplier rather than a variable boost. Let's try that too. It would get rid of the need to scale for TurnPot and would also work with small stick movements in the turn sense.

I see your point about the higher voltage. If a 100 Amp controller "automatically" gives a decent acceleration response for a 24 V setup, at twice the voltage you are truncating things with even a 150A limit. You'd need a 400A limit to get the same accel behavior at 48V as with 100A at 24.

Ciao,
Lenny

[LROBBINS]

Oops, forgot the attachment.

[Burgerman]

Quite!

>>> get some load on those motors: on its wheels by RC if you can't apply a load while it's blocked up.

I dare not try it. I have to use RC to even get it out of the house. It will end up embedded in a wall. That's a 400 percent acc increase, that comes on like a switch, and this is a 16mph chair! I don't much like runaway things, esp if its heavy, powerful and unstop-able by RC! I have had experiences with drag bike launch systems, rolling road automated throttle control systems etc and it never ends very well!

[Burgerman]

OK x10 one.

Much the same. ONLY forward and reverse seems OK without turn.
Add in to turn as you go from stopped to full speed (say push stick forwards at a few degrees off centre and acc goes really wild. A slight forward/right turn results in 5x greater acceleration. Even more so now.

And wiggling stick around zero point can cause violent acceleration now and again and it doesn't sound very healthy... Big voltages fast. Makes bangs and clunks... Something very odd happening with this current controlled acceleration.

Anything to do with my 10K turn acc required to get sensible turn rates? Because this 10x thing caused those turn acc to speed up considerably. It seems on or off this acc boost.

Added...
Reduced turn acc rate to 1000. And its now slower initially, but then the current boost kicks in as its starting and it does so an instant afterwards. You hear a 2 stage turn to the left/right as it speeds up, and overshoots a fraction. Motor RPM goes too high by 10 percent, then recovers. We are talking about zero turns. I don't like it!

[Bearded_Blunder]

Sorry to keep banging on, I'll shut up about this soon, promise, but I won't sleep till the saying is said.. some ways Asperger's is a curse.

Not real figures but for clarity lets say:
At stall, they take 150A each at 22V which is about right. I have 44V battery. So that's a 50% pulsewidth.

At stall there's no rotation
22/150 = 0.147 Ohms - our motor imp.

At this point battery Amps are half of motor amps.

Except we only care about motor amps for this

Chairs max speed is 16 so that means it will (could) still pull 150A at 100% pulsewidth at 1/2 speed, 8mph, at which point battery Amps = motor amps.

we have 150A * 0.147 = 22.05v effective applied
44 -22.05 = 21.95v (back EMF) @ 8mph

From now on pulsewidth remains 100% and Amps fall to zero (about 6 in reality) at full speed.

we have measured 6A full 44V applied running free
6*0.147 = 0.882v (effective EMF going in seems low, but no load, just spinning wheels on blocks?)
44-0.882= 43.1v backEMF nice n high, consistent with FAST and surprise surprise about double the 8mph figure...

Try plugging in some real numbers, you'll find them consistent with real speed, I wouldn't want to rely on this to detect small changes myself without real world checking, may not be accurate enough to say detect difference between each motor in running speed, but plenty good for break points like 1/4, 1/3, 1/2 speed etc. one action below, other action above, or triggering a row of LEDs for a speedometer...

[LROBBINS]

Bearded Blunder,

That last post is quite clear, but we didn't have any problem anyway with controlling acceleration once the motor's turning. Once rolling, it's quite enough to just set a single, moderate deltaPWM/time (Roboteq's definition of acceleration for brushed motors - we have to live with that, we can write, interpreted, micro basic, scripts, and even add external hardware, such as the motor current sensors or an outside MCU as I have in my CANbus system, but we can't change either the main, closed source, program or the hardware that's inside the controller).

The problem we're trying to solve is getting adequate, strongly boosted, "acceleration" at motor start, without causing "acceleration" to be too high later on. ALL of what we're trying to solve concerns that not-turning to barely-turning situation, not the motor running steady-state situation, but we have to fix that without creating unintended consequences further along.

The solution to the other problem, making sure that turn-in-place stops, or nearly stops, before fore-aft movement begins or ends, has already been found, and in a way that gives steering priority over speed in all circumstances with only 3 lines of code. This problem had already been worked out, in a more complex way, for turns while moving, but turn in place to straight fore-after and the reverse had been left out. Happily, imposing steering priority turns out to be a much simpler solution in all situations.

John,

The attempt to use motor current does not look like it will ever work. At the transition between souped-up turning and fore-aft acceleration we seem to be right on an uncertain edge of deciding which boost to use. The spikes could probably be avoided by the script's insisting that turning is completely stopped before even beginning fore-aft movement, but I don't think that would feel comfortable, which is why there's a few msec overlap. Then, given that motor current is at the controller's limit from start to 8 mph, it's just not a measure that tells us when PWM change/time needs to be reduced. It's just not going to work, so back to using (currentTurnRate-targetTurnRate) and (motor command - motor power) as the measure, and curving the response and/or adding limits at which the boost is forced to end.

You are absolutely right to not want the chair with that script in it to be moving whether you're aboard or not. You need a dual-dynamometer or some other way to load the wheels when it's jacked up. Not just in the current situation, but whenever you want to test something new, hardware or software - no-load behavior and under-load behavior both have to be checked empirically; we've had ample evidence these last few weeks that what seems "logical" or "reasonable" isn't always so.

For testing before even putting the hardware in Rahci's chair I used the crappy Fracmo motors that had been removed from it. One still has a working, but weak, brake that I could use for short times to load one motor. On the other one, the hex hole in the ceramic disc is completely worn out. I think I'm going to try to find a second pair of cheap junk that I can link up axle to axle with the Fracmos so that I can test under load when I get my second HDC2450. Or a pair without gearcase, or with a lower gear ratio, that could be mounted on (reasonably-sized) rollers to make a drive-on load (not really fair to call it a dynamometer as I wouldn't meter anything - just have a variable load I can work against). Per wheel - 4 pillow blocks, 2 shafts/rollers and a motor-to-roller coupler. Doesn't sound too bad, but given my proclivity for cutting wrong even after measuring thrice, it would probably take me near forever, especially with only a (cheap) drill press, bench and angle grinders, and hand tools available.

Be back later.

Ciao,
Lenny

[Burgerman]

The turn acc/dec increase alone fixed one problem
The changes that made the turn stop or almost stop before forward power fixed another.
The curves fixed the final problem, or almost so, provided I can get them to only work up to x mph and then do nothing...

One script where those three things are integrated, and reverse braking was unaffected by it, would be perfect!

[LROBBINS]

Working on it, but after a full day at it I remain convinced that it's going to take me quite a while to get this right.

In today's escapades, I checked curving all the way up to fourth power - in no case does boost go to 0 at a low enough speed. I added a limit value of (M1Power+M2Power)/2 [= speed at steady state if held there] above which boost was zeroe'd out, but even with X^4 there was a pretty big jump at that limit. So I then simply linearly scaled the boost from 100% starting out to 0% at that limit. This works fine during acceleration, and I think I have an idea of how to make it work for small stick movements as well (but not yet coded or tested). However, I haven't yet figured out what to do about deceleration.

When decelerating, we may start from full speed or an intermediate speed. It's easy enough to get a decel boost that's 100% at full speed and disappears at full speed minus a limit, but I haven't figured out how to get an initial boost starting from an intermediate (accelerating or steady) speed. To do that, I will somehow have to keep track of what the last speed was before starting to decelerate, so tomorrow I'll see if I can implement that.

Rest assured that with the new way of establishing turn priority, the extreme back stick deceleration is gone.

A domani (till tomorrow),
Lenny

[Burgerman]

No hurry. Currently drilling holes through everything testing new drill... My screwdriver has one, many coins, and I drilled a hole through a drill bit...

[hank]

GET them alloy discs drilled for new wheels
Cant wait to see them fitted on bm2 .lol

[Burgerman]

That's the plan!

[Bearded_Blunder]

The problem we're trying to solve is getting adequate, strongly boosted, "acceleration" at motor start, without causing "acceleration" to be too high later on. ALL of what we're trying to solve concerns that not-turning to barely-turning situation, not the motor running steady-state situation, but we have to fix that without creating unintended consequences further along.

Hence me suggesting this to tell which state you're dealing with, you've got at any time all the information you need, measured current, pulse width/duty cycle, measured voltage, known motor impedance.. you have here a means to determine whatever you impliment has no consequence in steady state running situations, or accelerating once a set speed has been passed. Pick a low threshold equivalent to creeping round slowly.

I have no clue how your scripting language works having not looked but a simple "If - Then" or "select case" will do it.. If determined backEMF is less than.. work your boosting magic, else hands off and let controller do it's thing, am I missing something? Never heard of any scripting language that couldn't handle IF x THEN y ELSE z

Soon as you're rolling the back EMF rises above threshold, and your boost code gets ignored, can't have unintended consequences, not being acted on, so you can boost in ways that would be completely uncontrollable going faster, won't matter once you're rolling, the boost code cuts out due to back emf from motor turning and "else" is acted on instead.

Ignoring voltage and current sensor failures, which I assume you have arranged to shut the system down in the event of, the only way for this to give you a false low, and attempt boosting when the motor *is* turning, is by the armature going open circuit, and I doubt unwanted boost will do much then.

[LROBBINS]

you've got at any time all the information you need, measured current, pulse width/duty cycle, measured voltage, known motor impedance.

I'm not sure of this, but I think that we're actually missing one piece of information. Right at motor start up we know how much of the current is resistive and can subtract it out to know back EMF. A moment after that, we have a part that is still resistive and a part that is back EMF, and to be able to calculate that I think we'd need to know the voltage drop across the motor (i.e. I think this is what you mean by "measured voltage"). Measuring that would also be needed when climbing an obstacle. The Roboteq doesn't provide motor voltage, so some hardware would have to be added, a couple voltage dividers is the trivial part.

Adding that would be easier on my CANbus system as I already have an Arduino copy in the power distribution module (don't recall whether it still has two analog pins not already in use, but adding another one these days costs nearly nothing) that can send the voltage information to the Roboteq script via CAN.

I'd have to go back to the Roboteq spec sheet to see if there are 2 analog inputs still available there, but I doubt it. So John's setup would involve more new engineering. He'd have to add an MCU with some sort of communications link. I like the robustness of CAN, but RS232 would probably be quite workable for this if leads were kept short. He'd have to program that processor - and he doesn't write code. Then, all of the testing that's already been done in the last year or so would need to be repeated. Right now, we have to find a usable, albeit not perfect, solution using the hardware he already has.

You are quite right, however, that with full information we could reach a truly analytic solution to the problem. For the moment, however, I'm still trying to use another "known" piece of information - we know that we need acceleration boost only in 2 situations - just after starting the motors from 0, and just when beginning to decelerate. We can easily decide if we're in those states by keeping track of what the motors were doing and what they are being commanded to do, the exact amount of boost is by no means critical, and I think (more than a hope at this point) that we can empirically find out how big the boost should be and how long it should last. The user will have to adjust one more parameter - the point at which boost goes to zero - than he/she would have to adjust if the true back EMF were calculated. (The amount of boost would still need a user parameter because it's likely that, just as with using Current*millOhms for motor compensation, using the exact solution could lead to a runaway condition.) Downstream, if we decide that a fully analytic, rather than empirical, solution is needed, the whole CANbus controller package will also be ready, and that would probably be the best way for John to add the needed hardware. Who knows, before then Roboteq might decide to update their brushed-motor controllers so that _Accel is deltaRPM/time instead of deltaPWM/time, essentially doing all the measurement and calculation in the ARM, but I wouldn't hold my breath for that.

Since last night, it seems that I've got things coded properly for dealing with speed; both accelerating and decelerating and for both large and small stick movements. Now working on doing the same for turn. Then comes hours of tedious simulation (but this time, there is no "guessed" current curve involved, so the simulation should be more meaningful) before taking out the simulation code (just some IF (MotorSimulation) triggered subroutine calls and some PRINT lines that were added to see the results without having a controller attached) and sending it to John for testing. Probably another day or two until I can do that.

MicroBasic is not a great language to work with, at least I don't like it compared to C, C++, Pascal, PL1 or even Fortran. But it is workable. There's no switch statement, so you have to string together lots of IF clauses, there's no scope - everything is global, and everything is in one long file that makes editing a PITA etc. And, being interpreted it's slow, something compounded by the fact that the interpreter gets only a "slice" of processor time once every millisecond - the rest of the time the processor is dedicated to doing the actual motor controlling. Luckily, it's a pretty fast 32-bit ARM. The script however does not seem to run any faster, and probably slower, than I can doing far more complex calculations and transmitting CAN frames from an Arduino NANO with it's much slower 8-bit processor; for the script that ARM is really hobbled. BTW, the Roboteq user manual and software (including a C API and examples that can be used in an attached computer, or as models for script writing) are free downloads.

Ciao,
Lenny