PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

Yes fair enough I never thought of that... I can see that, so why no PC (or Android) / USB capability so that we can see all that stuff? It would be really useful. And there must be many more powerchairs than roboteqs out in the world. So economies of scale etc. After all the Roboteq stuff/software is FOC.

[Burgerman]

1st column ...second down ..Command Priorities

Options are...

Serial, Pulse, Analog. And this is the default as written.

And correct for most users. So in my case the analog joystick works unless theres a radio controlled pulse. At which point it takes over. If you connect to a PC then this takes over (serial). Unless you tick the box to stop it.

It is correct, and no way to change script priority?

[woodygb]

The script has an order it checks for pulse first ...it does this continiously ...if it misses finding a pulse then it searches for one of the options.

[Burgerman]

Well the roboteq is doing the same thing every 1000ms or whatever I tell it. So what will happen?

[LROBBINS]

John,

If you want to force the script to ONLY read pulse input, modify the script as follows:

in MainLoop, find the line that reads:

GoSub FindMode

and put a single quote at the beginning. It now is just a comment and the FindMode subroutine will not be called.

Immediately after that commented-out line, add a line that says:

vMode = 1

This will force the mode to always be pulse.

The vMode = 1 could actually be put above MainLoop, and that would be more efficient as there really is no need to set it every 20 msec. I suggest putting it with the commented out line as a reminder of what you've done. One assignment of a variable takes so little time that it won't actually slow down the computer by a noticeable amount - less than 5 seconds per day of continuous use if it is an 8 MHz microcomputer in the controller and the MicroBasic compiler isn't particularly badly done.

Ciao,
Lenny

[Burgerman]

Will try that, but with which script. I lost track!

Trial script 3?

[LROBBINS]

Yes, trial script 3.

[Burgerman]

Will test this afternoon.

[Burgerman]

DIM bPactive AS Boolean
DIM bSactive AS Boolean
DIM bAactive AS Boolean

vForwardScaling = 90
vReverseScaling = 60
vTurnScalingFwd = 60
vTurnScalingRev = 25
vMotorResistance = 100

MainLoop:
PRINT ("\n","START OF MAIN LOOP \n")
'GoSub FindMode
vMode = 1 'ADDED TO ALWAYS SEE PULSE INPUT BURGERMAN


GoSub SetCommands

'use following three lines if _CIx are M1 and M2 values
' GoSub ScaleSpeedM1M2
' GoSub ScaleTurnM1M2
' GoSub MotorCompensationM1M2

' use following three lines if _CIx are THROTTLE and STEER values
GoSub ScaleSpeedThrStr
GoSub ScaleTurnThrStr
GoSub MotorCompensationThrStr

GoSub SetMotors
Wait (20)
GoTo MainLoop

FindMode:
vP1 = getvalue(_CIP,1)
vP2 = getvalue (_CIP,2)
vS1 = getvalue(_CIS,1)
vS2 = getvalue(_CIS,2)
vA1 = getvalue(_CIA,1)
vA2 = getvalue (_CIA,2)
bPactive = TOBOOL (abs(vP1)+abs(vP2) > 0)
bSactive = TOBOOL (abs(vS1)+abs(vS2) > 0)
bAactive = TOBOOL (abs(vA1)+abs(vA2) > 0)
IF bPactive THEN
vMode = 1
ELSEIF bSactive THEN
vMode = 2
ELSEIF bAactive THEN
vMode = 3
ELSE
vMode = 0
END IF
PRINT ("\n","Mode = ", vMode, "\n \n")
RETURN

SetCommands:
IF vMode = 1 THEN
vC1 = vP1
vC2 = vP2
ELSEIF vMode = 2 THEN
vC1 = vS1
vC2 = vS2
ELSEIF vMode = 3 THEN
vC1 = vA1
vC2 = vA2
ELSE
vC1 = 0
vC2 = 0
END IF
RETURN

ScaleSpeedM1M2:
vSpeed = ((vC1 + vC2)*10)/20 'vC1 = left motor, vC2 = right motor
IF (vSpeed < 0) THEN
vC1 = (vC1*vReverseScaling)/100
vC2 = (vC2*vReverseScaling)/100
ELSE
vC1 = (vC1*vForwardScaling)/100
vC2 = (vC2*vForwardScaling)/100
END IF
PRINT ("\n" , "M1 scaled speed = " , vC1 , " M2 scaled speed = " , vC2, "\n \n")
RETURN

ScaleSpeedThrStr:
vSpeed = vC1 'vC1=THROTTLE
IF (vSpeed < 0) THEN
vScaledSpeed = (vSpeed*vReverseScaling)/100
ELSE
vScaledSpeed = (vSpeed*vForwardScaling)/100
END IF
'set THROTTLE to new speed
vC1= vScaledSpeed
PRINT ("\n" , "THROTTLE/STEER scaled speed = " , vC1 , "\n \n")
RETURN

ScaleTurnM1M2:
vSpeed = ((vC1 + vC2)*10)/20 'vC1 = left motor, vC2 = right motor
'unmix motor settings to find turn value that will be scaled
vTurn = vC1-vC2
IF (vSpeed < 0) THEN
vScaledTurn = (vTurn*vTurnScalingRev)/100
ELSE
vScaledTurn = (vTurn*vTurnScalingFwd)/100
END IF
'apply half of change to each wheel in opposite senses
vChangeTurn = vTurn - vScaledTurn
vC1 = vC1 - vChangeTurn/2 'subtracted
vC2 = vC2 + vChangeTurn/2 'added
PRINT ("M1 scaled turn = " , vC1 , " M2 scaled turn = " , vC2, "\n \n")
RETURN

ScaleTurnThrStr:
vSpeed = vC1 'vC1 = THROTTLE
vTurn = vC2 'vC2 = STEER
IF (vSpeed < 0) THEN
vC2 = (vTurn*vTurnScalingRev)/100
ELSE
vC2 = (vTurn*vTurnScalingFwd)/100
END IF
PRINT ("THROTTLE/STEER scaled turn = " , vC2 , "\n \n")
RETURN

MotorCompensationM1M2:
vILeft = GetValue (_AIC, 3)
vIRight = GetValue (_AIC, 4)
'apply compensation to each motor
vC1 = vC1 + (vILeft*vMotorResistance)/1000
vC2 = vC2 + (vIRight*vMotorResistance)/1000
PRINT ("\n" , "vC1 compensated = " , vC1 , " vC2 compensated = " , vC2, "\n \n")
RETURN

MotorCompensationThrStr:
'find motor currents
vILeft = GetValue (_AIC, 3)
vIRight = GetValue (_AIC, 4)
'do mixing to find motor values (DO NOT TRUNCATE - we will be reversing this below)
vM1 = vC1 + vC2
vM2 = vC1 - vC2
'apply IR compensation
vM1 = vM1 + (vILeft*vMotorResistance)/1000
vM2 = vM2 + (vIRight*vMotorResistance)/1000
'undo mixing to get back new THROTTLE and STEER values
vC1 = (vM1 + vM2)/2
vC2 = (vM1 - vM2)/2
'truncate in case compensation pushed THROTTLE and/or STEER over limits
IF (vC1 > 1000) THEN
vC1 = 1000
END IF
IF (vC1 < -1000) THEN
vC1 = -1000
END IF
IF (vC2 > 1000) THEN
vC2 = 1000
END IF
IF (vC2 < -1000) THEN
vC2 = -1000
END IF
PRINT ("\n" , "compensated THROTTLE = " , vC1 , " compensated STEER = " , vC2, "\n \n")
RETURN

SetMotors:
SetCommand (_G, 1, vC1)
SetCommand (_G, 2, vC2)
PRINT ("\n" , "motor commands set \n \n")
RETURN

__________________________________________________________

Tested, including the modification. As soon as I choose to run the script it leaves "pulse" and goes to serial. At which point there is no control. Everything stays at zero output/input no matter what. Stop the script, and all works fine in pulse.

[Burgerman]

Added. Also slows down and makes graph update erratically, and even if command priority changed to not include serial, it changes to serial anyway...


Simulate gives this.


START OF MAIN LOOP

THROTTLE/STEER scaled speed = 0

THROTTLE/STEER scaled turn = 0

Calling: GetValue(_AIC, 3)...returned 0.
Calling: GetValue(_AIC, 4)...returned 0.

compensated THROTTLE = 0 compensated STEER = 0

Calling: SetCommand(_G, 1, 0)
Calling: SetCommand(_G, 2, 0)

motor commands set


START OF MAIN LOOP

THROTTLE/STEER scaled speed = 0

THROTTLE/STEER scaled turn = 0

Calling: GetValue(_AIC, 3)...returned 0.
Calling: GetValue(_AIC, 4)...returned 0.

compensated THROTTLE = 0 compensated STEER = 0

Calling: SetCommand(_G, 1, 0)
Calling: SetCommand(_G, 2, 0)

motor commands set


START OF MAIN LOOP

THROTTLE/STEER scaled speed = 0

THROTTLE/STEER scaled turn = 0

Calling: GetValue(_AIC, 3)...returned 0.
Calling: GetValue(_AIC, 4)...returned 0.

compensated THROTTLE = 0 compensated STEER = 0

Calling: SetCommand(_G, 1, 0)
Calling: SetCommand(_G, 2, 0)

motor commands set


START OF MAIN LOOP

THROTTLE/STEER scaled speed = 0

THROTTLE/STEER scaled turn = 0

Calling: GetValue(_AIC, 3)...returned 0.
Calling: GetValue(_AIC, 4)...Program aborted by user.

[woodygb]

I'm baffled ..try commenting out the compensation.

' use following three lines if _CIx are THROTTLE and STEER values
GoSub ScaleSpeedThrStr
GoSub ScaleTurnThrStr
' GoSub MotorCompensationThrStr

Doubt it will help but eliminates one variable.

[Burgerman]

Did a screen vid... !r starts the script.

Now, no motors connected. But RC connected and on, and used in pulse mode. (when I cick mute) Graph is smooth (not in the vid!)

Once script started its, slow graph updates, spasmodic, no control, and it stays in serial input... With or without tick! Some spasmodic serial only control.

Watch carefully.

http://www.wheelchairdriver.com/gopro/1.avi Still uploading

[Burgerman]

' use following three lines if _CIx are THROTTLE and STEER values
GoSub ScaleSpeedThrStr
GoSub ScaleTurnThrStr
' GoSub MotorCompensationThrStr

Doubt it will help but eliminates one variable.

It will add many more since I will get that wrong! Not sure how.

[LROBBINS]

John,

I'm baffled too. (In the following, though it looks weird, I've put every question I have for you in bold and on a separate line so that they can stand out.)

Thanks for posting the output of the simulator.

Was that with the controller connected? My guess is yes as that's the only hardware that can read the pulse input, but please confirm.

Everything zero is what you should get if the joystick is centered, or if there's no pulse input at all (Roboteq assigns zero values for pulse input if there is no device). In other words, it's acting as though the pulse input device is turned off. Which would make some sense if serial is getting in from somewhere and taking over input priority.

Was this simulator result with mute checked?

Does one have to do something special in Roborun to enable the pulse joystick and tell the controller which pulse interpretation to use (I gather that there's more than one)?

To trouble shoot further, I suggest that you run the script as a "pure" simulation, no controller and no joystick, getting input just from the keyboard. Put in say 300 and 300 when it asks for CIP,1 and CIP,2 (the little fill in window will have the long-form names), and 0 and 0 when it asks for AIC (the analog inputs for compensation).

What numbers to you get for scaled speed and scaled turn?

You should get:
THROTTLE/STEER scaled speed = 270
THROTTLE/STEER scaled turn = 180
compensated THROTTLE = 270 compensated STEER = 180

If you don't get this even with no controller and no joystick connected, in "pure" simulation, there's something wrong with your MicroBasic compiler (that would also explain why it once said that some short-forum Roboteq variable wasn't recognized although you haven't seemed to have any further problem with that.) If so, you might want to try a fresh download and fresh install of the Roborun software.

I don't think that Woody's suggestion to turn off Motor Compensation can make any difference. Compensating 0, with 0 amps, just gives no change. There's only one subroutine that actually reads the inputs - that's SetCommands (not a good name, probably should be something like SetScriptJoysticVariables) which reads _CIx, 1 and _CIx, 2 into script variables that will then get "messaged" by the other subroutines. (CIx is always CIP because you've forced vMode=1.) Those values are eventually sent to the motors. There is NO part of the script that sends anything to ANY inputs.

You can see the CIP,1 and CIP,2 values before any algebra's been done if you add the following just below the GoSub SetCommands line:

PRINT ("Channel 1 input = " , vC1 , " Channel 2 input = " , vC2 , "\n")

These values should be 300 and 300 in pure simulation with keyboard input. If they are 300, 300 without the controller, BUT you get 0 and 0 when the controller is connected, the controller is NOT seeing the pulse source.

If you get the above values with pure simulation and input values of 300 and 300, then the script is running correctly and something about your setup is keeping the Roboteq from seeing the pulse input when the script is running. My suspicion, once again, is that the PC script engine (not the particular script) is trading information with the controller via serial and that it is this that is interfering, but I suppose there could be some "typo" in your configuration that makes pulse not get to the Roboteq even when there's a signal.

Another trouble shooting thing you could try is to just connect a pair of pots (or an analog joystick) as analog joystick input and force vMode to 3. If it responds OK to this, it would confirm that there is interference with the Pulse input. The script does not send anything at all to the pulse input, or any other input for that matter, so the problem's not in the script per se, but in some kind of interference with pulse input when the script is running.

When you tested the earlier (not mine) script that you were working on and got it to work, was that with pulse or analog input?

Lastly, another troubleshooting idea to track down the source of serial interference, but you have to connect something to the motor outputs. Either motors, or a couple volt meters. Get everything communicating with pulse input without the script; the motor outputs should track your pulse input. Run the script. All goes to pot and the outputs just stay at 0. UNPLUG THE USB LEAD.

Do the outputs start tracking the pulse input?

If they do, the interference is coming from the PC. If they still don't track, the interference is within the controller and coming from the script. If the former, I guess you'll have to contact Roboteq to ask if there's any way to keep the PC connected while running a script that reads Pulse input. If the latter, I'd do a fresh install of Roborun, re-Build the script and download the rebuilt one to the controller and try again. If still no joy, I would ask Roboteq to try the script --- is it a bug in the script, a bug in the Roboteq or a bug in Roborun?

Ciao,
Lenny

P.S. All Woody wanted you to do was add the one single quote mark in front of the GoSub MotorCompensationThrStr line.

P.P.S. In your VID was it still muted when you ran the script?

[woodygb]

I've hacked /cut about Lenny's script,

Try this...PULSE ONLY ... motor comp is commented out ..remove it if it runs ok.


vForwardScaling = 90
vReverseScaling = 60
vTurnScalingFwd = 60
vTurnScalingRev = 25
vMotorResistance = 100

MainLoop:
PRINT ("\n","START OF MAIN LOOP \n")
'GoSub FindMode
vMode = 1 'ADDED TO ALWAYS SEE PULSE INPUT BURGERMAN


GoSub SetCommands

'use following three lines if _CIx are M1 and M2 values
' GoSub ScaleSpeedM1M2
' GoSub ScaleTurnM1M2
' GoSub MotorCompensationM1M2

' use following three lines if _CIx are THROTTLE and STEER values
GoSub ScaleSpeedThrStr
GoSub ScaleTurnThrStr
' GoSub MotorCompensationThrStr

GoSub SetMotors
Wait (20)
GoTo MainLoop

SetCommands:
IF vMode = 1 THEN
vC1 = getvalue(_CIP,1)
vC2 = getvalue(_CIP,2)
END IF
RETURN

ScaleSpeedM1M2:
vSpeed = ((vC1 + vC2)*10)/20 'vC1 = left motor, vC2 = right motor
IF (vSpeed < 0) THEN
vC1 = (vC1*vReverseScaling)/100
vC2 = (vC2*vReverseScaling)/100
ELSE
vC1 = (vC1*vForwardScaling)/100
vC2 = (vC2*vForwardScaling)/100
END IF
PRINT ("\n" , "M1 scaled speed = " , vC1 , " M2 scaled speed = " , vC2, "\n \n")
RETURN

ScaleSpeedThrStr:
vSpeed = vC1 'vC1=THROTTLE
IF (vSpeed < 0) THEN
vScaledSpeed = (vSpeed*vReverseScaling)/100
ELSE
vScaledSpeed = (vSpeed*vForwardScaling)/100
END IF
'set THROTTLE to new speed
vC1= vScaledSpeed
PRINT ("\n" , "THROTTLE/STEER scaled speed = " , vC1 , "\n \n")
RETURN

ScaleTurnM1M2:
vSpeed = ((vC1 + vC2)*10)/20 'vC1 = left motor, vC2 = right motor
'unmix motor settings to find turn value that will be scaled
vTurn = vC1-vC2
IF (vSpeed < 0) THEN
vScaledTurn = (vTurn*vTurnScalingRev)/100
ELSE
vScaledTurn = (vTurn*vTurnScalingFwd)/100
END IF
'apply half of change to each wheel in opposite senses
vChangeTurn = vTurn - vScaledTurn
vC1 = vC1 - vChangeTurn/2 'subtracted
vC2 = vC2 + vChangeTurn/2 'added
PRINT ("M1 scaled turn = " , vC1 , " M2 scaled turn = " , vC2, "\n \n")
RETURN

ScaleTurnThrStr:
vSpeed = vC1 'vC1 = THROTTLE
vTurn = vC2 'vC2 = STEER
IF (vSpeed < 0) THEN
vC2 = (vTurn*vTurnScalingRev)/100
ELSE
vC2 = (vTurn*vTurnScalingFwd)/100
END IF
PRINT ("THROTTLE/STEER scaled turn = " , vC2 , "\n \n")
RETURN

MotorCompensationM1M2:
vILeft = GetValue (_AIC, 3)
vIRight = GetValue (_AIC, 4)
'apply compensation to each motor
vC1 = vC1 + (vILeft*vMotorResistance)/1000
vC2 = vC2 + (vIRight*vMotorResistance)/1000
PRINT ("\n" , "vC1 compensated = " , vC1 , " vC2 compensated = " , vC2, "\n \n")
RETURN

MotorCompensationThrStr:
'find motor currents
vILeft = GetValue (_AIC, 3)
vIRight = GetValue (_AIC, 4)
'do mixing to find motor values (DO NOT TRUNCATE - we will be reversing this below)
vM1 = vC1 + vC2
vM2 = vC1 - vC2
'apply IR compensation
vM1 = vM1 + (vILeft*vMotorResistance)/1000
vM2 = vM2 + (vIRight*vMotorResistance)/1000
'undo mixing to get back new THROTTLE and STEER values
vC1 = (vM1 + vM2)/2
vC2 = (vM1 - vM2)/2
'truncate in case compensation pushed THROTTLE and/or STEER over limits
IF (vC1 > 1000) THEN
vC1 = 1000
END IF
IF (vC1 < -1000) THEN
vC1 = -1000
END IF
IF (vC2 > 1000) THEN
vC2 = 1000
END IF
IF (vC2 < -1000) THEN
vC2 = -1000
END IF
PRINT ("\n" , "compensated THROTTLE = " , vC1 , " compensated STEER = " , vC2, "\n \n")
RETURN

SetMotors:
SetCommand (_G, 1, vC1)
SetCommand (_G, 2, vC2)
PRINT ("\n" , "motor commands set \n \n")
RETURN

[LROBBINS]

Ooops, I wanted to edit my last post a bit, but ran out of time. So, here it is again with a few changes added.

John,

I'm baffled too. (In the following, though it looks weird, I've put every question I have for you in bold and on a separate line so that they can stand out.)

Thanks for posting the output of the simulator.

Was that with the controller connected? My guess is yes as that's the only hardware that can read the pulse input, but please confirm.

Everything zero is what you should get if the joystick is centered, or if there's no pulse input at all (Roboteq assigns zero values for pulse input if there is no device). In other words, it's acting as though the pulse input device is turned off. Which would make some sense if serial is getting in from somewhere and taking over input priority.

Was this simulator result with mute checked?

Does one have to do something special in Roborun to enable the pulse joystick and tell the controller which pulse interpretation to use (I gather that there's more than one)?

To trouble shoot further, I suggest that you run the script as a "pure" simulation, no controller and no joystick, getting input just from the keyboard to see if the script itself generates correct values. Put in say 300 and 300 when it asks for CIP,1 and CIP,2 (the little fill in window will have the long-form names), and 0 and 0 when it asks for AIC (the analog inputs for compensation).

What numbers to you get for scaled speed and scaled turn?

You should get:
THROTTLE/STEER scaled speed = 270
THROTTLE/STEER scaled turn = 180
compensated THROTTLE = 270 compensated STEER = 180

If you don't get this even with no controller and no joystick connected, in "pure" simulation, there's something wrong with your MicroBasic compiler (that would also explain why it once said that some short-forum Roboteq variable wasn't recognized although you haven't seemed to have any further problem with that.) If so, you might want to try a fresh download and fresh install of the Roborun software.

I don't think that Woody's suggestion to turn off Motor Compensation can make any difference. Compensating 0, with 0 amps, just gives no change. There's only one subroutine that actually reads the inputs - that's SetCommands (not a good name, probably should be something like SetScriptJoysticVariables) which reads _CIx, 1 and _CIx, 2 into script variables that will then get "massaged" by the other subroutines. (CIx is always CIP because you've forced vMode=1.) Those "massaged" values are eventually sent to the motors. There is NO part of the script that sends anything to ANY inputs.

You can see the CIP,1 and CIP,2 values before any algebra's been done if you add the following just below the GoSub SetCommands line:

PRINT ("Channel 1 input = " , vC1 , " Channel 2 input = " , vC2 , "\n")

These values should be 300 and 300 in pure simulation with keyboard input. If they are 300, 300 without the controller, BUT you get 0 and 0 when the controller is connected, the controller is NOT seeing the pulse source.

If you get the above values with pure simulation and input values of 300 and 300, then the script is running correctly and something about your setup is keeping the Roboteq from seeing the pulse input when the script is running. My suspicion, once again, is that the PC script engine (not the particular script) is trading information with the controller via serial and that it is this that is interfering, but I suppose there could be some "typo" in your configuration that makes pulse not get to the Roboteq even when there's a signal.

Another trouble shooting thing you could try is to just connect a pair of pots (or an analog joystick) as analog joystick input and force vMode = 3. If it responds OK to this, it would confirm that there is interference with the Pulse input. The script does not send anything at all to the pulse input, or any other input for that matter, so the problem's not in the script per se, but in some kind of interference with pulse input when the script is running.

When you tested the earlier (not mine) script that you were working on and got it to work, was that with pulse or analog input?

Lastly, another troubleshooting idea to track down the source of serial interference, but for this you'll have to connect something to the motor outputs. Either motors, or a couple volt meters. Get everything communicating with pulse input without the script; the motor outputs should track your pulse input. Run the script. I expect that all goes to pot at this point and that the outputs just stay at 0 because 0 speed + 0 steer means 0 output to both motors. NOW UNPLUG THE USB LEAD.

Do the outputs start tracking the pulse input?

If they do, the interference is coming from the PC. If they still don't track, the interference is within the controller and coming from the script. If the former, I guess you'll have to contact Roboteq to ask if there's any way to keep the PC connected while running a script that reads Pulse input. If the latter, I'd do a fresh install of Roborun, re-Build the script and download the rebuilt one to the controller and try again. If still no joy, I would ask Roboteq to try the script --- is it a bug in the script, a bug in the Roboteq or a bug in Roborun? If the script works with an analog joystick (and vMode=3), but not with a pulse joystick (and vMode=1), the problem's NOT the script, but somewhere in Roboteq (software, firmware or hardware).

Ciao,
Lenny

P.S. All Woody wanted you to do was add the one single quote mark in front of the GoSub MotorCompensationThrStr line.

P.P.S. In your VID was it still muted when you ran the script?

[Burgerman]

Ooops, I wanted to edit my last post a bit, but ran out of time. So, here it is again with a few changes added.

John,

I'm baffled too. (In the following, though it looks weird, I've put every question I have for you in bold and on a separate line so that they can stand out.)

Thanks for posting the output of the simulator.

Was that with the controller connected? My guess is yes as that's the only hardware that can read the pulse input, but please confirm.

YES

Everything zero is what you should get if the joystick is centered, or if there's no pulse input at all (Roboteq assigns zero values for pulse input if there is no device). In other words, it's acting as though the pulse input device is turned off. Which would make some sense if serial is getting in from somewhere and taking over input priority.

Was this simulator result with mute checked?

WHEN SCRIPT RUNS, MUTE DOESENT MAKE MUCH DIFFERENCE. TRIED IT BOTH WAYS. SEE THE VIDEO.

Does one have to do something special in Roborun to enable the pulse joystick and tell the controller which pulse interpretation to use (I gather that there's more than one)?

NO. IT ASIGNS A PRIORITY, IN ANY ORDER YOU CHOOSE. IF I ONLY ENABLE PULSE, DISABLE ALL THE REST, IT STILL GOES TO SERIAL WHEN I RUN THE SCRIPT ON THE CONTROLLER...

To trouble shoot further, I suggest that you run the script as a "pure" simulation, no controller and no joystick, getting input just from the keyboard to see if the script itself generates correct values. Put in say 300 and 300 when it asks for CIP,1 and CIP,2 (the little fill in window will have the long-form names), and 0 and 0 when it asks for AIC (the analog inputs for compensation).

DONT UNDERSTAND THIS. BUT WITH NO CONTROLLER YOU CANT REALLY RUN THE SCRIPT. IT ONLY RUNS ON THE CONTROLLER. IF YOU CHOOSE SIMULATE, INSTEAD, YOU GET A SCREEN OF STUFF I DO NOT UNDERSTAND. BUT THAT WILL WORK FOR YOU AS WELL?

What numbers to you get for scaled speed and scaled turn?

You should get:
THROTTLE/STEER scaled speed = 270
THROTTLE/STEER scaled turn = 180
compensated THROTTLE = 270 compensated STEER = 180

DID YOU WATCH THE SCREEN CAPTURE MOVIE?

If you don't get this even with no controller and no joystick connected, in "pure" simulation, there's something wrong with your MicroBasic compiler (that would also explain why it once said that some short-forum Roboteq variable wasn't recognized although you haven't seemed to have any further problem with that.) If so, you might want to try a fresh download and fresh install of the Roborun software.

DID THAT. AND ALSO AN UPDATED VERSION THAT GOES WITH THE UPDATED FIRMWARE.

I don't think that Woody's suggestion to turn off Motor Compensation can make any difference. Compensating 0, with 0 amps, just gives no change. There's only one subroutine that actually reads the inputs - that's SetCommands (not a good name, probably should be something like SetScriptJoysticVariables) which reads _CIx, 1 and _CIx, 2 into script variables that will then get "massaged" by the other subroutines. (CIx is always CIP because you've forced vMode=1.) Those "massaged" values are eventually sent to the motors. There is NO part of the script that sends anything to ANY inputs.

You can see the CIP,1 and CIP,2 values before any algebra's been done if you add the following just below the GoSub SetCommands line:

PRINT ("Channel 1 input = " , vC1 , " Channel 2 input = " , vC2 , "\n")

These values should be 300 and 300 in pure simulation with keyboard input. If they are 300, 300 without the controller, BUT you get 0 and 0 when the controller is connected, the controller is NOT seeing the pulse source.

If you get the above values with pure simulation and input values of 300 and 300, then the script is running correctly and something about your setup is keeping the Roboteq from seeing the pulse input when the script is running. My suspicion, once again, is that the PC script engine (not the particular script) is trading information with the controller via serial and that it is this that is interfering, but I suppose there could be some "typo" in your configuration that makes pulse not get to the Roboteq even when there's a signal.

I DIDNT UNDERSTAND ANY OF THAT!

Another trouble shooting thing you could try is to just connect a pair of pots (or an analog joystick) as analog joystick input and force vMode = 3. If it responds OK to this, it would confirm that there is interference with the Pulse input. The script does not send anything at all to the pulse input, or any other input for that matter, so the problem's not in the script per se, but in some kind of interference with pulse input when the script is running.

Tested Analog input on, and pulse off, still goes to serial when script is run.

When you tested the earlier (not mine) script that you were working on and got it to work, was that with pulse or analog input?

PULSE. I DO NOT HAVE ANYTHING CONNECTED VIA ANALOG. THAT WAS THE ROBOTEQ GUY COSMAS SCRIPT. IT WORKED FINE, AND SWITCHED TO PULSE INPUT SMOOTHLY WHEN THE MUTE WAS TICKED AS IT SHOULD. And it still does, I tried it.

Lastly, another troubleshooting idea to track down the source of serial interference, but for this you'll have to connect something to the motor outputs. Either motors, or a couple volt meters. Get everything communicating with pulse input without the script; the motor outputs should track your pulse input. Run the script. I expect that all goes to pot at this point and that the outputs just stay at 0 because 0 speed + 0 steer means 0 output to both motors. NOW UNPLUG THE USB LEAD.

Do the outputs start tracking the pulse input?

If they do, the interference is coming from the PC. If they still don't track, the interference is within the controller and coming from the script. If the former, I guess you'll have to contact Roboteq to ask if there's any way to keep the PC connected while running a script that reads Pulse input. If the latter, I'd do a fresh install of Roborun, re-Build the script and download the rebuilt one to the controller and try again. If still no joy, I would ask Roboteq to try the script --- is it a bug in the script, a bug in the Roboteq or a bug in Roborun? If the script works with an analog joystick (and vMode=3), but not with a pulse joystick (and vMode=1), the problem's NOT the script, but somewhere in Roboteq (software, firmware or hardware).

Ciao,
Lenny

P.S. All Woody wanted you to do was add the one single quote mark in front of the GoSub MotorCompensationThrStr line.

P.P.S. In your VID was it still muted when you ran the script?

BOTH, I MUTED AND UNMUTED WHILE SCRIPT WAS RUNNING. IN BOTH CASES IT STAYED ON SERIAL, AND THE TRANSMITTER WAS IGNORED, AND THE SERIAL CONTROL DATA WAS INTERMITTENT AND THE GRAPH WAS SLOW AND JERKY. SOMETHING IN THE SCRIPT MAKES IT STAY ON SERIAL, WILL NOT ALLOW IT TO SWITCH TO PULSE, AND SLOWS DOWN THE GRAPHING MARKEDLY.

[woodygb]

SIMULATE ...&..INPUT NUMBERS.

BM PIC.jpg (42.33 KiB) Viewed 16125 times

[Burgerman]

Yes, it does that!

Now, am I testing with the controller? or without? and does it make a difference? Dont know what I am doing... Its like greek. Does it help?

[woodygb]

It would appear to confirm that the Roborun software is running correctly..

The 300 is the equivalent of a pulse value ...entered manually ..that SHOULD BE being read from one axis of your joystick... when running the script in the controller...but isn't

[Burgerman]

Now it wont build...

[Burgerman]

Is there another name for _AIC?

[woodygb]

_AIC = _ANAINC

Replace with longer version ..shouldn't need to but some part of the software is misbehaving.

[Burgerman]

No _ but that works.

Gives:

Program started.

START OF MAIN LOOP

THROTTLE/STEER scaled speed = 0

THROTTLE/STEER scaled turn = 0

Calling: GetValue(_MOTAMPS, 3)...returned 0.
Calling: GetValue(_MOTAMPS, 4)...returned 0.

compensated THROTTLE = 0 compensated STEER = 0

Calling: SetCommand(_GO, 1, 0)
Calling: SetCommand(_GO, 2, 0)

motor commands set

____________________________________________________________

But laid on bed, need to test roboteq asap... Will report back.

[Burgerman]

I get this in simulation...

6 boxes, put in 300 every time, and see result:


START OF MAIN LOOP
Calling: GetValue(_CMDPLS, 1)...returned 300.
Calling: GetValue(_CMDPLS, 2)...returned 300.
Calling: GetValue(_CMDSER, 1)...returned 300.
Calling: GetValue(_CMDSER, 2)...returned 300.
Calling: GetValue(_CMDANA, 1)...returned 300.
Calling: GetValue(_CMDANA, 2)...returned 300.

Mode = 1


THROTTLE/STEER scaled speed = -3

THROTTLE/STEER scaled turn = 75

Calling: GetValue(_MOTAMPS, 3)...returned 0.
Calling: GetValue(_MOTAMPS, 4)...returned 0.

compensated THROTTLE = -3 compensated STEER = 75

Calling: SetCommand(_GO, 1, -3)
Calling: SetCommand(_GO, 2, 75)

motor commands set


START OF MAIN LOOP

[LROBBINS]

John,

From your screenshot showing that _AIC was not recognized, it's clear that something is very wrong with the MicroBasic compiler in your computer. You've got to get that fixed before you'll be able to tell anything else.

The image that Woody showed of a simulation, without the controller, is what I'd asked you to do. He input 300 and 300 as Pulse inputs from the keyboard, and the script properly retrieved them and properly scaled forward speed and forward turn and since _AIC values (amps) were entered as 0, motor compensation did nothing.

Even if you don't understand the lines in green in the simulator output that say what step the computer has just done, the PRINT statements in black are coming from the script and you obviously do understand them.

IF YOU SUCCEED in a make of the script and simulate without the controller, do you get the same result as Woody got?

I really think that this test is irrelevant at this point if you can't make the script.

Hmmm, another possibility. Did you cut and paste text from a posting to create the script that wouldn't compile? It's conceivable pasted data from a browser contains some hidden characters or other garbage that are confusing the compiler. In a few minutes I will upload a fresh copy of the script with the forced use of Mode 1 and that extra print line to show in plain text what Pulse joystick values the script has before doing any of the scaling/compensation. Just change its name from xxxx.zip to xxxx.mbs and open that in the script editor. Does this copy compile?

BTW, I did look at the VID, but it was a struggle; partly because I don't know what I should be seeing, and partly because on my computer it showed upside down and mirror imaged. Even turning the computer around so it was right side up didn't make it readable.

Ciao,
Lenny

[woodygb]

This is what I get from testscript3 under simulation.

300 for all except _AIC which I gave a zero.

scriptsim.jpg

[LROBBINS]

Lenny has egg on his face. I just did what I had told you to do earlier --- commented out FindMode and added the vMode=1 line, and simulated. That made throttle and steer always equal 0 because the commands to actual read the joystick are in FindMode. So your earlier simulation result of 0 , 0 now makes perfect sense.

In the file I'm sending you, FIndMode is NOTE commented out, but the vMode=1 line is added. The FindMode subroutine will take in the joystick data, but it's vMode result won't matter because whatever it is it will be immediately set to 1. I should have first tested my suggestion before posting it. Sorry.


On second though, I'll send you a three scripts. The first one will do everything, except that mode will always be pulse. In the second, all of the calculation routines are commented out, but it will still send values to the motors (that is to the _G,1 and _G,1 named variables). The last one will do all the calculations, but won't send anything to the motors. If all of these compile (make), try each one in simulation and look at the black lines in the simulator output. Then try them with the controller and see if any of them work without causing it input to go haywire.

Ciao,
Lenny

[woodygb]

Deleted ... that pic wasn't script3..this is.

scriptsim3.jpg (87.35 KiB) Viewed 15979 times

[Burgerman]

I am confused.

Re installed brand new roboteq software, nothing changed.
Tried Laptop, same thing.

And 3 scripts? Email?