PINNED - Roboteq Controller - developing for powerchairs

[woodygb]

The "fast" post was a coincidence ..I'd been browsing for something else and seen the sensors ..thought.... Ah! ..they maybe of use and actually posted without seeing your prior question.

Lenny seems to prefer the seperate sensor option .. but has indicated that it is possible to rewrite the script.. to querry the Roboteqs internal motor current estimates.

Over to Lenny.

[JoeC]

I confess that I haven't read this whole thread yet, but I'll chime in and say that my understanding of the Roboteq manual is still that for low PWM values the current estimate will become increasingly inaccurate. You could try it without sensors, but I have a strong suspicion that it won't 'feel right' without the current sensor.

I've been getting a few things sorted out before I could do this, but I think I'm about ready to get started on a chair with the brushless roboteq. I have a dead Quickie P222 that I've verified isn't designated for any other use, so now I just need to steel my nerves to spend $625 on a non-essential sporting item that is essentially just for my own education. Should be fun!

[LROBBINS]

Patience, I will have a new version of the script posted soon - I want to make it so the various options (PRINT or no-PRINT, channel signals THROTTLE and STEER or M1 and M2, use internal current estimates or external sensors, allow pulse input or not) can all be selected right at the top so you won't have to fiddle with anything inside MainLoop or the subroutines.

The sensor Woody found looks interesting because it just fits around the wire, but it has a 1/4" opening that you might have trouble passing connectors through. It does still need small wires for power and output. It has various components on a small board, and you can (and may have to) adjust opamp gain etc. to calibrate it.

Roboteq recommends the Allegro ACS756 series of sensors (now replaced by the ACS758 series). Here's a link to the -100/100 Amp version (which I would use rather than the -150/150 Amp, but one could use that too). With the -100/100 Amp, compensation will roll off over 100 Amps, where it's not needed as much, and I think that this will allow a higher milliohm setting before the chair gets jumpy.
http://it.rs-online.com/web/p/sensori-effetto-hall/6807557/?searchTerm=ACS758LCB-100B-PFF-T&relevancy-data=636F3D3126696E3D4931384E4272616E644D504E266C753D6974266D6D3D6D61746368616C6C26706D3D5E285C772B5B2D5C2E5C732F5D292B285C772B293F2426706F3D3526736E3D592673743D4B4559574F52445F4D554C54495F414C5048415F4E554D45524943267573743D4143533735384C43422D313030422D5046462D542677633D4E4F4E4526

The Allegro sensors are monolithic with no adjustments, but they do have to be soldered into a motor wire. I would mount them right next to the Roboteq.

The internal motor current estimates get inaccurate at low duty factor, and the steps may be a bit large. I'd try them anyway and see whether they work well enough for motor compensation.

Later today I should have the updated script ready.

Ciao,
Lenny

[Burgerman]

No hurry. Still putting chair together.

[LROBBINS]

Here's the latest version of the script.

FIRST, delete any copies you have of "development 2012_09_12.mbs". Everything that was in there is in the new one, and that one had an error in the AmpHr calculating subroutine.

SECOND, after you download today's "development 2012_09_19.zip" and change it to *.mbs, take a look at the lines at the beginning of the script. There are now a series of options, some numeric, some TRUE or FALSE, that should let you easily change how it behaves without commenting out lines and so on. There is also more, and more descriptive, PRINT output when simulating so that you can know what inputs you're being asked for etc. You may want to change vCyclesPerSpeedPotRead and vCyclesPerAmpHrCalc to much smaller numbers, such as 20 and 100/vMainLoopWaitTime respectively if simulating. Dividing by vMainLoopWaitTime adjusts cycles automatically for changes of Wait time. DO REMEMBER to increase these numbers again if actually running the controller or it may be rather sluggish.

The Speed Pot value is now used for forward speed scaling, and all of the other scaling values are percentages of this. So if vSpeedPot = 90 and vForwardTurnScaling = 80, maximum turn rate when going forward will be 0.9 X 0.8 = 62%, and with vReverseScaling = 60 and vReverseTurnScaling = 40, max speed going backwards will be 0.9 X 0.6 = 54% and max turn going backwards will be 0.9 X 0.6 X 0.4 = 22% (maybe 21% because integer arithmetic truncates rather than rounds).

I couldn't be sure, reading the Roboteq manual, how the motor current estimates are calculated. However, because they say that the precision gets less as maximum amps goes up, I suspect that 0 to maximum amps is scaled to 0 to 1000. So, if max amps is set at 1500 (=150Amps), an estimate of motor current of 1000 corresponds to 1500 = 150 Amps. Because motor compensation should use actual current, not an arbitrarily scaled number, and work the same way even if you change the MaxAmps using Roborun, I have calculated back to actual 10X Amps. If max amps is set at 750 (=75 Amps), then a motor current estimate of 1000 is taken as 75 Amps (750 DeciAmps), and 500 would be 37.5 Amps (375 DeciAmps). The way to find out whether I got this right is to compare what the Roborun software reports as motor current, and what the script PRINTs as motor current after scaling - IF you can figure out how to see the PRINT results while actually running the controller with motors.

This program is getting complex enough that I think you should be bench testing this with a couple motors (of any sort) hooked to the controller, perhaps loaded with a friction roller of some sort so that you can see that things behave the way you are interpreting the graphs. Better than flipping a chair (without you in it as I assume you will be testing by RF at first)!

Ciao,
Lenny

Let me know how the testing goes.

[Burgerman]

OK. This will not be this week. And testing will be in the chair...

Cant see an easy way to connect anything any other way, lots of wires, brakes, inverters, RC connections, etc etc...

I will save the post too. So I can understand whats happening. Will the Ah bit cause any problems? Can I turn it off some how?

Thanks!

[LROBBINS]

No, it just gathers information and does a PRINT. If you suppress printing, it won't even do that. At least if I haven't made any bloopers. Ciao, Lenny

[Burgerman]

We will soon find out.

[LROBBINS]

In my last posting with the uploaded script, I mentioned that I had guessed about how the time (clock) function in the Roboteq works. I have since found the information hidden somewhere in the manual, and my guess was quite wrong. The clock is in seconds, not milliseconds, so I will have to revise the AmpHr monitor to use a count-down, millisecond, timer instead. I did also find where the information about the countdown timers is hidden in the manual, so it won't be difficult. I may also have found a way to interrogate what mode is being used (without polling all 3 input types), but I'm not sure yet. Lastly, when running a script, serial input is pretty useless, so I think you should leave the "bAllowSerialInput = FALSE" line as is and not try to use serial control inputs as your joystick. The Roboteq isn't really set up to use serial joysticks anyway; serial commands are intended for stuff coming from the PC (e.g. from Roborun, or another program on the PC).

Lastly, and this is very good news, I'm now pretty sure that it's possible store a modest number of user variables in the Roboteq's flash memory. That means that we can continue to accumulate AmpHrs even if the controller has been turned off and then back on, and at least some logging information. So, aside from putting that stuff in the script, we will just need a way to display it. I couldn't find it in the manual, but it may be that the basic error and status flag information is already in flash, and can be read out with Roborun even if the controller has been turned off and back on. However, I'd like the log information to also have a time stamp, and I'd like to be able to see some fault and status information on the chair without connecting a PC. I'm also thinking that it might be possible to automatically zero AmpHrsUsed after a re-charge by saying "IF battery voltage exceeds tot, this means that the chair has been recently recharged and we now have full, or near full, AmpHr capacity".

I've been reading some Arduino stuff, and it looks like it won't be too hard to use one with a little TFT-LCD screen to do that. Adafruit, for example, has a 1.8" diagonal color screen that uses only 4 Arduino pins and they already have a graphics library for it, and parsing stuff sent by Roboteq PRINT statements should also be straightforward, although somewhat cumbersome to program. The Arduino also has enough flash to store information if there's not enough room in the Roboteq itself. I wouldn't want an Arduino to be actively involved in controlling a chair, but have no problems thinking about using one for displaying information or even for ancillary functions. I'm not going to start working on that now, just wanted to get an idea of how easy or hard it will be to do. I have also been thinking about how to integrated both a joystick as an attendant control and Rachi's switch array, have some ideas, but am a long way from implementing anything for that.

The bottom line is that I will be sending along another updated script when I get the AmpHr routine re-written, but you can continue using the last one. You just needn't bother trying to test whether the AmpHr meter works - it doesn't.

Ciao,
Lenny

[Burgerman]

OK.

>>> I'm also thinking that it might be possible to automatically zero AmpHrsUsed after a re-charge by saying "IF battery voltage exceeds tot, this means that the chair has been recently recharged and we now have full, or near full, AmpHr capacity".

That will work great with lithiums. As they jump from 3.3v to 3.6 per cell on charge suddenly right at the end. And within a few meters in use they drop to 3.35v as you drive away. And stay there all day long.

[Burgerman]

Just measured a Pilot Plus joystick, it has a 1.5v (1.46v measured) total voltage swing.

So I wont use that. I could, but resolution will be lower. And stray voltages injected via external electrics (noise) will have a greater effect.

Roboteq works with up to 5v swing. And can use any.

[Burgerman]

I heres a pilot plus dismantled. Theres not much to see. You could use the case, and joystick module only, throw away the rest of the internals, with a simple on off switch if you wanted. The 5v for joystick comes from the roboteq. Thats the black neg - and red + wires. That leaves three others. The yellow and blue ones give voltage swings for left/right & forwards/reverse against the negative. Neutral is half way between the 5v input and the negative. So 2.5v.

The green one thats left is just a fixed reference voltage at 2.500 volts. And can be used or ignored. Roboteq allows absolute or compared to reference volts, you can choose. I wont use it other than as a comparison to detect errors. But I will actually use my APEM 4.5V swing joystick instead of this one for greater resolution since the roboteq input allows 0 to 5v. Either will work fine. May even use the pilot plus casing since it is easy to mount.

The charge port connector will be removed if I do. And replaced with a big red stop button! And the top plate will be replaced with a plastic or carbon sheet epoxied on to replace the "sticker/buttons" with three or 4 latching illuminated switches for reduced speed, on/off, lights, RC on, etc. And some LEDs for roboteq status, Overheat, lights, battery level, etc. And a USB port to connect laptop for monitoring, graphing battery, controller and motor parameters and programming easily. Or for connecting a small devive to read Ah used from battery pack (copyright Lenny!)

[ex-Gooserider]

Another option for a controller pod might be to do something on a 3-D printer... We have several at the Asylum, and they can do some quite impressive stuff.

ex-Gooserider

[Burgerman]

Well it might. But I have this, and my original small metal box. So either of those will work. But the whole chair/lithium 45v thing and roboteq/joystick and 15mph is all a bit of a prototype... But thats why its fun.

[LROBBINS]

Or for connecting a small devive to read Ah used from battery pack (copyright Lenny!)

John,
Don't jump the gun on this. I can (I think) script accumulating AH, but there's still the problem of being able to see the result. I assume you don't want to be driving with a PC in front of your face. If the only output function is a battery meter, you might be able to get away with an Arduino nano (connected by USB cable to Roboteq), 6 LEDs and 6 resistors right inside your joystick box, but that's still another little hardware and software project. The software could be done (awkwardly) long distance, but the hardware and testing would fall to your capable, but very busy, hands. Ciao, Lenny

[Burgerman]

To be honest, now we have the control throw thing working, with no serial in/out data being needed, all I really need for the moment is the internal motor compensation to work.

By lightly changing this:

I added a mountain of stuff so I know what I am doing...

________________________________

'Start here, include this line!
'Last updated on: 13th September 2012.
'In this version SERIAL input is ignored and has been 'commented out, and turn and speed scaling applies to pulse and analog only
'Print has been commented out too for speed and graph is smoother.
'ONLY change USER SETTINGS below, with care! Start manually, and iff no problems set to start script automatically.


'Declare Boolean and start:
DIM bPactive AS Boolean 'pulse
DIM bSactive AS Boolean 'serial
DIM bAactive AS Boolean 'analog


'_________USER SETTINGS__________

vForwardScaling = 90 'FORWARD MAX SPEED (ALLOW SOME HEADROOM FOR STEER/MIXING)
vReverseScaling = 30 'REVERSE MAX SPEED
vTurnScalingFwd = 30 'FORW TURN RATE
vTurnScalingRev = 30 'REVERSING TURN RATE
vMotorResistance = 100 'MOTOR COMPENSATION. (SETTING THIS TOO HIGH IS DANGEROUS)

'_______END USER SETTINGS________


MainLoop: 'Begin!
'PRINT ("\n","START OF MAIN LOOP \n")
GoSub FindMode 'looks to see which input used
GoSub SetCommands
'PRINT ("\n" , "Joystick THROTTLE = ", vC1, " Joystick STEER = ", vC2, "\n")

'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 (3) 'speed of re-run script
GoTo MainLoop


FindMode:
vP1 = getvalue(_CIP,1) 'PULSE INPUT MODE
vP2 = getvalue (_CIP,2) 'PULSE INPUT MODE
' vS1 = getvalue(_CIS,1) 'SERIAL INPUT MODE
' vS2 = getvalue(_CIS,2) 'SERIAL INPUT MODE
vA1 = getvalue(_CIA,1) 'ANALOG INPUT MODE
vA2 = getvalue (_CIA,2) 'ANALOG INPUT MODE
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

_______________________________________

The newer one you sent baffles me... So was hoping to start with this as I know what most of it is doing!

Is it easy to change this one so internal compensation works? After I get it all up and running, will then test the new script you did. And look at Ah reading etc.

[LROBBINS]

I'd rather not add the internal current estimation to that script. I am working on another update to use the count-down timers, and once I've sent that to you, I'll walk you through it if need be. Basically, it will be set up so that you can just make changes in the USER SETTINGS section to allow or suppress printing, use or not use a speed pot, use internal or external current sensing, change the loop Wait and so on without ever having to fiddle with anything within the subroutines. That way, if there are problems it will be much easier for me to trouble shoot than if I have to look line-by-line through a modified script to find what's been changed or where a bug of my doing lies. I'll probably have the new one ready today. If not, expect it tomorrow. I'll try to pick good names for things in the USER SETTINGS section, or add lots of comments. (I'll also try to remember to set the defaults at the values you have in your message here.)

Ciao,
Lenny

[LROBBINS]

John,

I just did a typical Lenny. I previewed the last message and then went to work on the script without ever actually posting it. So this one, with a new version of the script, will arrive at almost the same time.

Download this and take a look at the top USER SETTINGS part. I don't think that you will have to delve into any of the innards to make this work for testing. If something in USER SETTINGS doesn't make sense, just ask. I've tried to make it match your preferences, but certainly could have missed something.

There are comments about the changes I've made at the very end, but I'll summarize here:

(1) It now finds out which mode is active by using the Roboteq's StatusFlags variable - gets rid of a lot of calculation.
(2) it only reads command values for the mode actually in use
(3) the timing of summing the current used is now done with a Roboteq count-down timer (set at 1000 msec), and another timer, set at 10000msec=10sec, is used for sending this to a display device; I don't think that a display update needs to be any faster than this so why load down the Roboteq or external micro processors?
(4) all user settings have been moved to the top of the file; there should be no need to make changes within MainLoop or any of the subroutines to set it up for your tastes

Because the simulator does not simulate any of what the Roboteq stores in flash memory, I can only test the logic of the program. I can not actually test whether the motors will actually behave the way I'd want them to, or that a speed pot would work right, or that the amp hours are correctly summed. (I've posted about this at the Roboteq forum - if they'd simulate the flash in a bit of PC RAM, one could do much more complete testing before risking the hardware. No response yet.)

Let me know if you run into any problems with this and I'll try to get on it as quickly as possible so as to not delay you.

Ciao,
Lenny

[Burgerman]

Dont worry you wont delay me. Been over a year messing about with other things! Usually build new chairs in a week!

Thanks for all your work.

I will study and test and see how it works later today, this evening.

The roboteq only switches to different input modes (serial, analog, pulse, digital etc) after polling every 1 second. (you choose 1000ms). So how can it have a digital or analog input working simultaniously like switches or encoders etc? Gives me a headache!

[LROBBINS]

Reading the digital and analog input/output pins is independent of mode, the pulse/serial/analog mode setting only applies to how that information gets handled when a particular input is configured for motor control. I do think that I'd want a closer than 1 sec polling of what controller is in use though. (There is some safety in the fact that an absent pulse signal sets both control channels to 0, or an out of range analog signal can trigger a fault state, so at worst, you'll lose motor power for a second if your active controller changes from pulse to analog or vice versa.)

The bigger source of confusion for me is that there are fewer pins than possible uses for them, so one has to be very careful to avoid using the same pin for more than one thing, or has to figure out how to avoid conflicts between the different uses. This is not at all uncommon in micro-processors, but is a headache to keep straight (at least for me). The Arduino, just to take an example I have worked with, also multi-functions its pins: digital pins can be just 1 or 0, or, for some of them, PWM or tx/rx, digital pins can be both input and output (just as on the Roboteq) etc. With the Arduino, if you run out of pins, you can add some external chips to multiplex multiple multiple signals on one pin and the programming language is flexible enough to separate the multiplexed inputs or outputs. Of course, the more you play such games, the slower it will run. I don't think that the Roboteq MicroBasic is up to that in any case.

Ciao,
Lenny

[Burgerman]

Heres how easy it is to convert an old empty pilot plus joystick pod, to use as a simple home setup joystick. (electronics, joystick, all connectors removed)

It will use my APEM 4.5 volt swing cheap hall effect joystick. It fits easily.
It will use 6 illuminated ebay switches. Dim when off, bright when depressed.
As shown.

There will be a 1mm real carbon fibre plate fitted to the top where the stiker/buttons from PG drives was removed. So it will look pretty.

1 button for:
POWER On/Off,
Speed - Slow 4MPH/Fast 15MPH, fixed resistor. Pots are too slow and more than I need.
lights ON/OFF,
Radio Control mode On/Off,
2 spare - may not be fitted, or fitted and initially unused unless I see a need. Maybe a superbright light or 12v inverter for USB power etc switching.

[Burgerman]

OK tested new script. Loaded it to controller, and then typed !r

That normally runs script. This time it says "controller lost" and then "controller found", "read configuration yes/no"...

So no work... Dunno why. It says "read motor amps" (which is zero) then fails.

[LROBBINS]

I have absolutely no idea what that is about. I'll take a look at the script tomorrow PM and see if I can figure out some things that might help diagnose it, but it actually doesn't sound like the problem's there. Is your USB connection "wobbly". Ciao, Lenny

[Burgerman]

Not physically or electrically as far as I know.

[LROBBINS]

(1) As much as I've been musing about what might have cause complete failure, I haven't any real idea. One possibility is that I might have forgotten to set bSuppressPrinting = TRUE and that the many print lines going out over the serial port have caused a conflict. So, I guess the first thing to check is that this line does not say FALSE, change it if it does, and re-try. bSuppressPrinting = TRUE will eliminate all but one print action, and that one is called only once every 10 seconds to update the (as yet nonexistent) AmpHr display.

(2) That it says

"controller lost" and then "controller found", "read configuration yes/no"...

really does suggest a serial connection failure or conflict rather than a script error. I'd suggest, FIRST don't touch your physical setup or Roborun settings, but open the older script that was working, download it to the controller, and try that. If it too fails, the problem is not in the script but in your physical or Roborun setup. If, instead, it works, I'd reload the new script, BUILD it to see that the file hasn't been corrupted, download and try it again. Let me know the results of (1) and (2) and we'll go from there.

(3)

"read motor amps" (which is zero) then fails.

Motor amps are read in the new motor compensation sub-routine: this is the Roboteq variable for its estimate of motor current. That message's wording is not in the script, so it was a message from Roboteq about what it was doing. The two lines in the script that read motor amps are

Code: Select all

vILeft = GetValue (_A, 1) 'estimated current for motor1, max amps setting = 1000
vIRight = GetValue (_A, 2) 'estimated current for motor2, max amps setting = 1000


but these are just built-in Roboteq calls. This looks a bit like when the compiler couldn't recognize some Roboteq short names which I think you had tracked down to something like having two different compilers installed and using the wrong one. Has that happened again?

Do check these things out and let me know the results. If they don't give us a good clue as to what happened, I will try to send you some short scripts, or modified scripts, to try to systematically track it down.

Ciao,
Lenny

[Burgerman]

Old script moved to controller. Works fine as before.

New script re installed, compiles or builds, fine too. And simulates fine.

But will not run. Just disconnects and then says found new controller, load settings/data? Then behaves as if no script. Restarting script causes repeat of this.

Will check "false" setting later on too.

[woodygb]

iT IS SET TO FALSE..

' MISCELLANEOUS
bSuppressPrinting = FALSE 'Set to TRUE to suppress printing to speed and smooth controller/PC interaction;
'PRINT of current used will not be suppressed, but is sent only once every vTimeBetweenAmpHrOutputs msec
bAllowSerialInput = FALSE 'Set to TRUE if using serial joystick or emulation
bUseCurrentSensors = FALSE 'Set to TRUE if using external current sensors on analog inputs 3 & 4
'Set to FALSE to use Roboteq's internal motor current estimates
vFullRechargeVoltage = 449 'ten times battery voltage; 44.9V = 3.45V/cell - voltage present only immediately after
'recharging used to reset AmpHrs used measurement to 0

[Burgerman]

So should try true?

Later when dog walked!

[woodygb]

I believe so ..yes

[LROBBINS]

So, the problem is with the script.

Yes, do try it with bSuppressPrinting = TRUE. Better yet, I'll attach a fresh file with it set to TRUE just in case the last download was somehow corrupted. Once you download the new one to your PC, I'd suggest manually doing a BUILD before downloading to the controller. My memory says that Roborun automatically builds at every transfer to the controller, but manually doing a build will make sure that you have code that has been compiled on your computer not on mine. (If MicroBasic or Roboren were themselves written in a NET-based language (e.g. C.NET, C# etc), the NET version present during the compile could be critical.)

Setting bSuppressPrinting = TRUE will get rid of almost all of the serial traffic in case that has been causing a conflict. All those print statements are fine in the simulator, and they might even be OK with a long WAIT, but with only Wait (3) plus a Roboteq-added transmission delay after every 32 print characters, things could get less nice - depending on how Roboteq programmed that serial delay, it might never be able to get back to running the script. Script execution suspends when the controller is doing its thing, and with all those waits also suspending things, it might not even re-start, or it might overstay the 1000 msec watchdog that deactivates serial if there's no signal for a second. Easier to find out by testing than to somehow figure out what Roboteq really means in their manual descriptions.

The other thing to check is that MUTE box - it should be checked when not running the simulator as the PC is sending stuff to the controller at the same time as the script is sending stuff to the controller and Roboteq has no adjudication system for this. Again, let me know what happens.

Here's a new copy. The only change is that it has bSuppressPrinting = TRUE. Ciao, Lenny