PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

When I add all, and choose build, I get 2 ERRORS

_AIC IS NOT A VALID NAMED CONSTANT.
_AIC IS NOT A VALID NAMED CONSTANT.

Line 79 and 80
column 20 and 21

Doesent like
vILeft = GetValue (_AIC, 3)
vIRight = GetValue (_AIC, 4)

If we can (you can!) get this to work we have a good more powerful replacement for the damned mobility controllers with all their cost/innaccessible programmers etc.

[woodygb]

_

ANAINC or _AIC InputNbr Read Analog Inputs Converted

AIC - Analog Input after Conversion

So it exists ...you could try the longer version ANAINC instead or indeed AIC

[Burgerman]

Got it to download, and renamed txt. Copied the text and same error? It worked on yours woody?

Why not here?

[Burgerman]

That did it.

Full name works, _aic not!

[woodygb]

Give it a whirl...run those motors!

[woodygb]

I think that it reads summat like this...

vForwardScaling = 90
vReverseScaling = 70
vTurnScaling = 35
vMotorResistance = 100
The above are user parameters.

MainLoop:
GoSub FindMode
GoSub ScaleSpeed
GoSub ScaleTurn
GoSub MotorCompensation
GoSub SetMotors
Wait (20)
GoTo MainLoop

This says runs thru the 5 parts of the program in order .. GoSub = Jump to this part ..

GoTo Mainloop... directs it back to the beginning to do it all again.

Findmode does exactly that ...it decides what input mode is active Pulse Serial or Analog

Scalespeed retrieves the Pulse Serial or Analog values based on the active input mode from Findmode.
AND applies a percentage reduction that is specified at the very beginning of the script.

Scaleturn
applies a percentage reduction that is specified at the very beginning of the script


MotorCompensation

Applies a formula based on readings from the motor resistance ... and if needed modifies them.

Setmotors

Takes the modified values and applies them to the motors.

[Burgerman]

Right...

When I run the script, it jumps from pulse input to serial, and everything on the graph goes to the top. And the graph slows down and gets jumpy. No amopunt of stick waggling helps it.

So something is wrong. But what. And it will not return to normal without restarting the program/roboteq...

But no errors as such, and the various numbers update fast on the script screen where I type !rt to run the script. The " = 128" at the end of the line seems very popular!


There are NO MOTORS connected. They are on the chair, in bits... Roboteq starts to get warm after half hour. Is it OK to run it without the motors connected do you think? And will it screw up your comp formula?

[woodygb]

The comp formula will be fine ..it might not/will not show correctly but it shouldn't effect the result ...
or will it ...
Hmmmm ...No motors attached ...it might read zero resistance ..and the formula wouldn't like that!

Got a pair of any old motors?

[woodygb]

To temp get rid of the errant serial signal ..fnose where that's creeping in from!

You could replace ..

vPleft = getvalue(_CIP,1)
vPright = getvalue (_CIP,2)
vSleft = getvalue(_CIS,1)
vSright = getvalue(_CIS,2)
vAleft = getvalue(_CIA,1)
vAright = getvalue (_CIA,2)

WITH

vPleft = getvalue(_CIP,1)
vPright = getvalue (_CIP,2)
vSleft = getvalue(_CIP,1)
vSright = getvalue(_CIP,2)
vAleft = getvalue(_CIP,1)
vAright = getvalue (_CIP,2)

So it's only ..or should only be ... using the CIP Pulse input.

If it's still finding swapping over after that script mod..then I'm at a loss...

[Burgerman]

No motors that I can get at, all bolted to chairs.

Right. Will have to have a think, and try that change.

[LROBBINS]

When you download that faked zip file, don't try to unzip it. You don't even need to copy and paste. Just change the extension from zip to mbs and open it with the Roboteq software. Ciao, Lenny

[woodygb]

doh!....AND REPLACE ..just in case... as it's late and I can't be assed to check properly!!

Or wait till morning........or till Lenny posts a solution

ScaleSpeed:
IF vMode = 1 THEN
vLeft = GetValue(_CIP,1)
vRight = GetValue(_CIP,2)
ELSEIF vMode = 2 THEN
vLeft = GetValue (_CIS,1)
vRight = GetValue (_CIS,2)
ELSEIF vMode = 3 THEN
vLeft = GetValue (_CIA,1)
vRight = GetValue (_CIA,2)
ELSE

WITH

ScaleSpeed:
IF vMode = 1 THEN
vLeft = GetValue(_CIP,1)
vRight = GetValue(_CIP,2)
ELSEIF vMode = 2 THEN
vLeft = GetValue (_CIP,1)
vRight = GetValue (_CIP,2)
ELSEIF vMode = 3 THEN
vLeft = GetValue (_CIP,1)
vRight = GetValue (_CIP,2)
ELSE

[LROBBINS]

Burgerman,

Try running it in simulation without the Roboteq controller connected. If it doesn't work then, there's something wrong with your copy of the script - try a mbs renamed version of the zip. If it does work without the controller, then my code is AFU with respect to your configuration. For example, do you have analog sources connected to analog inputs 3 and 4 (the one the code is using to read amps), and have you configured them to scale -1000 to 1000?

I have no idea why it would be hopping from one input mode to another. Or maybe I do. You have your PC connected to the Roboteq and I bet you didn't click "mute" before running the script. That's going to send lots of serial stuff to and from the PC that could be causing a conflict. or just fooling the Roboteq into thinking that it has a serial input device connected. Search for "mute" in the Roboteq manual to see what I'm talking about.

I think a better way to remove the mode checking, and forcing the use of Pulse for troubleshooting would be to comment out the line:

GoSub FindMode

in MainLoop: and add a line right below there that says

vMode = 1

If it now works, the problem is in the FindMode subroutine (or just because you didn't mute the PC serial connection). If it still doesn't work, the problem is in how vMode is being used in the ScaleSpeed subroutine. Making this kind of troubleshooting easier is a good reason for doing modular, structured programming.

Hmm - thinking about that organization now, the first bit of ScaleSpeed should be in a separate subroutine, say named SetModeSpecificCIx. MainLoop would then call GoSub SetModeSpecificCIx before calling ScaleSpeed. Then, if we later decided we wanted to do just ScaleTurn and not ScaleSpeed (now that speed scaling can be set with the configuration GUI), we'd still be reading the correct mode. If I did this, both scaling routines would still work properly even if the order of the ScaleSpeed and ScaleTurn calls in the script got reversed. Tomorrow I'll make this little change and upload a fresh copy.

I'm working on figuring out the three Roboteq mixing modes. I have figured out how to mimic MixingMode 1 and MixingMode 2, but haven't yet figured out how they get MixingMode 3. Once I have that figured out, I'll do some more code writing so that the calculations can be done with Throttle and Turn input data for whichever mixing mode one selects. I didn't see any command for finding out what MixingMode has been set in the configuration, so it will be important to either always specify the same mixing mode in both the script and configuration, or have the script override the configuration setting. It should be easy to automate that as there is a command for setting mixing mode from a script. This may take some time!

Ciao,
Lenny

[woodygb]

Lenny ...Do you mean the base formula for the mixing?

[LROBBINS]

Woody,

I guess that's what I mean.

For MixingMode 1 it's just M1=Throttle+Turn (truncated at 1000), M2=Throttle-Turn (also truncated at 1000)

For MixingMode 2 it's M1=Throttle+Turn, M2=Throttle-Turn, then if any value exceeds 1000, the excess is subtracted from both M1 and M2

For MixingMode 3 it's ????????????????????????

Ciao,
Lenny

Everyone,

Here's a new version of the test script with getting the mode-specific CIx in a separate sub-routine. While I was doing this I discovered that there were errors in it - vSleft had become just Sleft in calculating bSactive and 2 other similar typos. Such mis-typed variables will always be 0, so the logic was indeed screwed up. When simulating, this just made Serial always off, so that tells me that Burgerman's problem with serial input was probably stuff coming from the PC because of lack of "mute".

Remember, to use this file, just change the zip in its name to mbs and load it into the Roboteq application.

[woodygb]

As a starter try ....

2*JOYY-SQRT(JOYX^2+JOYY^2)
SQRT(JOYX^2+JOYY^2)

or a variation of the above

notation is JOYstick Y axis JOYstick X axis .... they're copied from an Excel spreadsheet I did ...it fills in the "circle" nicely without dead corners.

[LROBBINS]

I'll try that, but how does one approximate a square root function with integer arithmetic (in a MicroBasic that doesn't have SQRT)? Ciao, Lenny

[LROBBINS]

Woody,

As written, SQRT(a^2 + b^2), can only taken on positive values, but a motor has to be able to go backwards. Something's wrong here.

Ciao,
Lenny

[Burgerman]

Got it, will test asap this afternoon.

[woodygb]

I'll try that, but how does one approximate a square root function with integer arithmetic (in a MicroBasic that doesn't have SQRT)? Ciao, Lenny

GOOD point .... Sometimes I know too much and not enough.

The formula was ripped from the Excel sheet very late ..I'm fairly sure ... thinking about it now ...that it goes negative in 2 quadrants.

MORE Coffee ...sort the wife ...etc and I'll look.

[LROBBINS]

Woody (and anyone else who's interested),

GOOD NEWS. First, don't worry about figuring out what Roboteq MixerMode 3 does. It turns out that it doesn't matter at all. The reason is that a 10% motor compensation change on LeftMotor and RightMotor is ALSO a 10% change on Throttle and Turn, and I'm pretty sure that this is true however mixing is calculated.

Actually, I've only shown this for all LINEAR transformations between Throttle/Turn and M1/M2, but suspect that it's true for non-linear transformations as well. Even if it's not, however, whatever error is made by assuming this will affect only the amount of motor compensation, and that's only a small part of total compensated M1 and M2 Moreover, IR compensation is just an approximate correction for load in any case. So, the compensation calculation can be applied to CIx,1 and CIx,2 whether they are pre-mixing or post-mixing. THEY'RE EITHER EXACTLY THE SAME, OR IF THEY'RE A BIT DIFFERENT IT JUST DOESN'T MATTER.

So, I'll go back to my script and put in two alternative SpeedScale and TurnScale routines; one each to use if CIx,1 and CIx,2 are pre-mix and the other to use if they are post-mix. We'll just have to decide which ones to (permanently) comment out once we're sure about whether these values are pre or post.

While I'm at it, I'll put in two alternative MotorCompensation subroutines, one for external current sensors the other using the internal motor current estimates. Just comment out one or the other to try either way of doing it.

Expect another script file in a bit.

CIao,
Lenny

[woodygb]

!!!! ..Don't you sleep Leeny?

[LROBBINS]

Not as much as I would like. Rachele has been in bad shape for months (extreme dystonia caused - we think - by a baclofen catheter leak compounded by a badly herniated cervical disc. Cath was replaced two weeks ago, Disc will be removed next week.). So I'm often up for her, and my colitis (or IBS if you prefer to use "modern" names) isn't letting me sleep much either.

I've been trying to keep sane during these extremely trying times by keeping myself active with this chair stuff (whether mechanical or computer).

Ciao,
Lenny

[woodygb]

I know you said not to bother ..but it was nearly done.
BLUE is a R.H. motor .... RED a L.H. motor
A solid block indicates that the 1000 limit has been reached.
There is an additional change in sign for the reverse ...thus minus minus = plus

I've no doubt that you could find a better way of doing it.

lenny.gif (255.89 KiB) Viewed 23066 times

[LROBBINS]

Thanks, I'll see whether this matches Roboteq's MixingMode 3 and also use it to test whether applying compensation pre and post mixing is still equivalent with this non-linear algorithm. Ciao, Lenny

P.S. I'll send you a PM with my e-mail address. If your willing, I'd like you to send me the spreadsheet itself and then I won't have to do a lot of typing.

[woodygb]

Fine by me Lenny.

[LROBBINS]

Hi Woody,

I think I've got it now. Not only is there a sign change in different quadrants, but assignment of the y^2+/- (x^2+y^2)^0.5 and +/- (x^2+y^2)^0.5 formulas to the two motors flips in different quadrants.

Ciao, Lenny

[woodygb]

Lenny,

I'm having to revisit my thinking from many months ago ... it might even be a year plus ...when I first made the spreadsheet ...

Yes there is a flip shift in formula depending on the quadrant or according to the + - value of the signal .

I think there is one cell ...somewhere ..that may have an IF then do formula in it that covers the various scenario's ...

The spreadsheet is really unfinished as I'd reached a point that satisfied my curiosity... and no one at that time had a use for it.

Cheers Woody

[Burgerman]

Mix one gives best speed but reduces turn rate by 50 percent if at full forward speed.
Mix two gives full turn speed at full forward by reducing the slow motor further. I think.
Mix 3 baffled me...

Should I test the newest one or do we know its wrong???

[LROBBINS]

John,

You can, if you wish, test the script - the mode detect is fixed. What is probably still wrong is that is assumes that the CIx values are post-mixing and they are probably actually pre-mixing. Have you checked out "mute" in the Roboteq manual? Reading pulse while a script in the PC is sending its stuff via serial causes big problems, so you do have to see what Roboteq says to do.

As far as the table of the mixing modes. Mode 1 is indeed the classic that chops speed in full turn. Mode 2 fixes this some, but there is one row in the Roboteq table that seems to have a typo. Mode 3, as shown in the table, it turns out doesn't make any sense to me either and I think it is full of typos (especially of sign). I just realized this as I was comparing it to what Woody sent me. For example, take a look at the last row for Mode 3. Full forward and full left turn, but both motors are full forward - that's just plain WRONG. I think that the table wasn't proof read!

Before I touch the script I want to do some more with Woody's mixer algorithm to see if motor compensation can be done equally with pre and post-mixing data with a non-linear mixer. I was working on solving his equations backwards (to go back from mixed LeftMotor/RightMotor to un-mixed Throttle/Steer, but got interrupted by the arrival of some guests after I'd solved the equations for just one quadrant. I'll get back to it in a bit.

Ciao,
Lenny