PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

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.

Will have a read. Thing is, without motors connected will the compensation throw a wobbly? Because it got very warm last night over a 10 min period. Normally not an issue running not connected to test things.

Maybe set comp to zero?

[LROBBINS]

John,

Yes, serial communications conflicts when running a program from the PC (as opposed to after it's been downloaded into the controller) is a serious issue, and serial can interfere with pulse!

I don't have a Roboteq, and any attempt I might make to say how it's hardware will react is just speculation.

All that the compensation routine does is slightly boost the duty cycles on the two motors as amps increase. You don't have any current sensors on input, and if you're trying to really read analog 3 and analog 4 (as opposed to putting in numbers from the keyboard during simulation) with nothing connected there I have no idea what values the Roboteq will see. Are they pulled down, pulled up, or floating when nothing's connected? What would happen if the Roboteq thinks that analog 3 is 16000 instead of being in the -100 to 100 range for 100 Amp sensor? So, if when you run the program with the controller attached, you have to force those inputs to behave like -100 to 100 inputs in one way or another. If you have no way to get them to behave like analog inputs, I'd suggest you put a single quote in front of the GoSub MotorCompensation line. That turns it into a comment and it will then never be called and the controller won't be looking for nonexistent current sensor. After you get it working that way, you might see whether the configuration application can fake having something connected there (with signals in the -100 to +100 range with the controller configured to scale that to a -1000 to 1000 range). After you've got the sensors faked, then I'd take out the commenting quote and change vMotorResistance from 100 milliohms to 0. Now you'll read the sensors, but not do any compensating. Then add some resistance to see what the compensation does.

I'd really suggest that you try playing with it first with under simulation before connecting the controller so you can see how it should behave. I have no idea how you've configured all the inputs and outputs, and if there's a problem with the controller connected, you may have to go through those with a fine tooth comb. Is your pulse joystick (or emulator) connected to the default Robotek joystick pins? Is your configuration reading whatever pins it's connected to as the standard motor control inputs? etc.

In other words, one step at a time, especially when your hooking something, even a virtual something, to some fairly expensive hardware.

Ciao,
Lenny

[LROBBINS]

YIPPEE! YIPPEE! YIPPEE!

After making many mistakes exercising my rusty algebra and in transferring that to a spreadsheet (it's oh so easy to point to the wrong cell), I finally was able to unmix the mixing done by Woody's algorithm, and yes 10% MotorCompensation done on Throttle/Steer is EXACTLY the same as 10% MotorCompensation done on LeftMotor/RightMotor. Whatever _CIx is won't matter - the compensation algorithm will work fine.

The scaling routines would still be different depending on whether _CIx is pre or post mixing, but you already have one for pre and I did one for post, so we just have to eventually decide which to use.

Ciao,
Lenny

[Burgerman]

Yes, serial communications conflicts when running a program from the PC (as opposed to after it's been downloaded into the controller) is a serious issue, and serial can interfere with pulse!

I am running it on the controller. But starting it from the PC by typing !r and clicking go!

[Burgerman]

>>>but you already have one for pre and I did one for post, so we just have to eventually decide which to use.


We do?

OK what EXACTLY do I test!

Will do it in the next hour.

[LROBBINS]

I am running it on the controller. But starting it from the PC by typing !r and clicking go!

If you have not downloaded it into the memory of the controller itself, you are actually running it in the PC and just sending instructions via USB to the controller. According to Roboteq there's a mute function somewhere in the application to prevent this "crosstalk".

>>>but you already have one for pre and I did one for post, so we just have to eventually decide which to use.
We do?
OK what EXACTLY do I test!

The version of my script that you have assumes that _CIx1 and _CIx2 are M1(left motor) and M2(right motor) values. The script (from someone at Roboteq) you'd been working on with Woody assumes that _CIx1 and _CIx2 are THROTTLE and STEER. If the one from me makes the chair turn when you go straight back, IT'S WRONG and _CIx1 and _CIx2 are reallyTHROTTLE and STEER.

The next one I send will have two sets of scaling and compensation subroutines: one based on _CIx1 and _CIx2 being M1 and M2, the other based on _CIx1 and _CIx2 being THROTTLE and STEER. At that point you could try both of them, by commenting out one or the other group of three GoSub lines. One will make the chair behave correctly, the other will make it into a drunken sailor. I suspect that the M1/M2 assumption is wrong and that this (which is what's in the last script from me) will be the drunken sailor.

I have the new one ready, but want to simulate test it with lots of different values of M1 and M2 (for one set of subroutines) and THROTTLE and STEER (for the other) to make sure it didn't mistakenly change some + into a - or vice versa.

Ciao,
Lenny

[LROBBINS]

Just a brief note (something actually brief from Lenny?) to clarify what I meant in my previous enthusiastic post about compensation using Woody's algorithm.

For compensation, it doesn't matter which algorithm is used to calculate the compensation - if you use the same algorithm to mix and to un-mix the compensation will work.

Compensation has do be done for each motor based on its current draw so we do need to have M1 and M2 values. The Roboteq may give us these, but, more likely, we have to calculate them THROTTLE/STEER. Thus, we do need different compensation routines depending on whether the input measure are M1/M2 (no mixing/unmixing needed) or THROTTLE/STEER (a mix - compensate -unmix sequence needed), but in the script we can use any mixing algorithm; it doesn't matter which algo the chair is actually using. The mixing algorithm in the script has no effect on the mixing algorithm in the chair and vice verse.

So I'm just using the simplest possible mixer, equivalent to Roboteq Mixing Mode 1, without any truncation, to do (THROTTLE/STEER to M1/M2) -- COMPENSATE -- (M1/M2 back to THROTTLE/STEER). After all that's done, truncation is needed before sending the final values to _G1 and _G2 in case the compensation pushes a value out of bounds.

After I've gotten some sleep (I hope) and done some more testing, I'll upload a new file.

Ciao,
Lenny

[Burgerman]

Great I wait in anticipation.

>>> If you have not downloaded it into the memory of the controller itself, you are actually running it in the PC and just sending instructions via USB to the controller. According to Roboteq there's a mute function somewhere in the application to prevent this "crosstalk".

I have downloaded it. And instead of running it on auto so it starts on boot up, I just type the !r command and click send.

It is running on the roboteq?

[LROBBINS]

OK, but DON'T DON'T USE AUTORUN UNTIL YOU'RE SURE OF EVERYTHING. Also, I just checked the manual and see that even then you have to "mute".

Important Warning
When running a script that sends motor command, make sure you click “Mute” in
the PC utility. Otherwise, the PC will be sending motor commands continuously and
these will interfere with the script commands.

I suspect that this is why you were getting weird behavior, along, possibly with the absence of analog signals at analog inputs 3 & 4. Perhaps you should use a couple pots connected as voltage dividers and configured to have a -1000 to 1000 range so that there are real inputs there. Otherwise, comment out the GoSub calls to motor compensation.

I also don't know if the Roboteq has problems if motor commands are actually sent (as the script will) when no motors are connected. Do you have a pair of any old 24V motors (even tiny ones) that you could have connected while testing? Otherwise, you could comment out GoSub SetMotors to avoid actually sending motor commands.

If you comment out both GoSub MotorCompensation and GoSub SetMotors, you will still be testing the joystick response. If you have pots at the analog inputs, you can mimic compensation by twisting them.

I'd still rather you tried out the script in the simulator first, without the controller connected. If there are bugs, it would be better to find them in a virtual world than in the real one. The simulator is an analog of your cardboard battery box.

Ciao,
Lenny

[Burgerman]

No. I know about the mute. Its set up so that it takes motor commands in this order. ANALOG, RC, SERIAL. The mute button lets it do its RC when theres a valid signal, otherwise it forces serial data only. So thats not it. In order to test it I have to untick the mute.

I'd still rather you tried out the script in the simulator first, without the controller connected. If there are bugs, it would be better to find them in a virtual world than in the real one. The simulator is an analog of your cardboard battery box.

Try it your end.

Simulator just brings up a box of code/numbers... No graphs or anything I can undertsnd. Downloading to the device, running/starting manually is what roboteq recommend. That way I can see the graphical results of control inputs and changes. Even autorun isnt a disaster as its still just a case of reloading firmware.

[woodygb]

It's all a little unclear concerning the mute button ... but my thought is that you'd start the script running ..type !r ..then hit mute.

[woodygb]

The “Mute” checkbox can be selected to stop all commands from being sent to the controller.
When this is done, only parameter reads are performed. When commands are
muted and if the watchdog timer is enabled, the controller will detect a loss of commands
arriving from the serial port and depending on the priorities it will switch back to the RC or
Analog mode.

Note that disabling the watchdog will cause the serial mode to be always
active after the first command is received, and the controller will never switch to a lower
priority mode.

Your joystick is connected to the Roboteq?

[LROBBINS]

I tried looking for a mute button and couldn't find it, but there is a WorkOffline check box. Of course I don't have a controller, but if that box is unchecked, the Roboteq software takes up near 100% of both cores cycles, I presume it's trying to send serial information to a non-existent COM port. It sure makes the computer sluggish. If I check the Work Offline box, Roboteq takes perhaps 4% of processor cycles. So, IF the Roboteq software is open on the PC, it is continuously sending serial data even if you have no serial input device connected and this probably will conflict with the script even if the script has been downloaded to the controller.

Thus, if you want to connect the controller (and have faked or connected some analog source to analog input pins 3 & 4, and perhaps connected motors to the outputs), once you have downloaded the script you MUST click Work Offline before running it. I think that this is why Roboteq puts that warning I quoted in bold.

I have now tested version 3 of the script in the simulator to try to spot errors - indeed, there were errors. There were places where I had a + instead of a -, or a + instead of a *, and some inconsistent variable names because of typos or cut-and-paste that should have been slightly changed in the copy. I think I've got it working right now, so in the next message I'll describe the testing and upload the file.
Ciao,
Lenny

[woodygb]

Lenny ..from looking at the picture in the Roboteq user pdf that shows the mute button page 234...and then looking at the RUN screen in Roborun's program... I'd suggest that a Mute button and all the sliders etc ...will appear IF a joystick is present.

[LROBBINS]

In order to test script 3, I fed the simulator values corresponding to half joystick throw at various points around a circle and recorded the output values with or without speed scaling, turn scaling and motor compensation. I did this with the 3 GoSubs that assume that the _CIx values read by the program are M1 and M2 (post mixing), and then I did it all again with the other GoSubs that assume that the inputs are THROTTLE and STEER (pre mixing) active.

In the first case (M2/M2) all scaling should affect both motors: speed scaling in the same sense for both, turn scaling in opposite directions for the two motors. Compensation gets independently applied to each motor.

If the inputs are THROTTLE and STEER, speed scaling only affects THROTTLE and turn scaling only affects STEER. To do compensation, the THROTTLE and STEER values are mixed to get M1 and M2 values, compensation is done on those, and then they are un-mixed to get back to the compensated THROTTLE and STEER.

Here's a table of the results. The input values are the cartesion coordinates of the joystick positions. I've hidden the columns that do the trigonometry for this, but if people want the actual spreadsheet I can provide that; both as the original QuattroPro and as an Excel export. I am more a numbers than visual type, but maybe Woody will come up with a way to graph these for those who think visually.

script 3 testing.jpg (153.76 KiB) Viewed 21972 times

I think that all of these numbers make sense, but would certainly welcome other checking them too.

I'll now upload the script file. As before, it says "zip". After downloading, change that suffix to "mbs" and you will be able to open it in the Roboteq software. I've changed some variable names: for example what was vLeft is now vC1 because "command 1" can be either "left motor" or "throttle" depending on which interpretation of _CIx,1 is chosen. I've added separate forward and reverse turn scaling factors, and tried to make some things a bit more mnemonic so it's easier to read. Happy testing.

[LROBBINS]

Woody, if there is a mute button that appears only when a joystick is connected, it should definitely be pressed while the script is running in the controller. Pulse and Serial information are not completely hardware independent in the Roboteq and there will be conflicts. Maybe, unlike Work Offline, mute lets you still receive serial (so that you can monitor what's going on) and just blocks sending. Ciao, Lenny

[woodygb]

Throw me the spreadsheet please Lenny.

[LROBBINS]

John,
I just looked at the RUN tab and noticed that by default AIN3 and AIN4 (and all the other AIN) are set to 9999. That would be read as 1000 Amps of motor compensation and might explain your controller getting warm even with no motors attached. Even a high resistance leakage path with that much amperage will generate heat (even if it's actually truncated in firmware to max peak amps). Perhaps you don't actually have to connect pots, but you do have to set those pins to reasonable values.
Ciao,
Lenny

[Burgerman]

>>> Woody, if there is a mute button that appears only when a joystick is connected, it should definitely be pressed while the script is running in the controller. Pulse and Serial information are not completely hardware independent in the Roboteq and there will be conflicts. Maybe, unlike Work Offline, mute lets you still receive serial (so that you can monitor what's going on) and just blocks sending. Ciao, Lenny

The mute button is a tick box on the run screen. Its always present. If the tick is removed the box, ONLY serial data control is available. If it is ticked, it runs according to priority. So changes to pulse.

Analog input levels are zero as this is set to "no action" rather than a motor. The RC pulse input works great. And very accurate consistent and precise, as soot as you tick "mute"... And trust me, I am running this script on the roboteq after downloading to device. By manually starting the script, then ticking the mute box.

Only inputs enabled are pulse and serial.

ADDED. Mute button always exists if you have selected a controller. EG work offline, choose hdc2450

[LROBBINS]

John,

With no joystick connected, I do not have a mute box on the run screen.

What you say about the mute function does not match with that warning note in the Roboteq manual. Actually, I find the manual pretty confusing, but it seems to me that mute does a lot more than just lock youstick priority. If you repeatedly search "mute" in the manual you will find several paragraphs saying different things about what it does.

My run tab, not having changed anything at all after installing the software, and not having a controller attached, shows the AnalogInputs tick box checked, and values of 9999 for all of them. I don't know if the absence of that tick means "use the values in the boxes rather than read what's connected to the pins" or if it means that you can't read any analog inputs at all. If you can't read analog inputs, the script may have a problem because it definitely tries to read the Roboteq variables for analog pins 3 and 4 in order to do motor compensation. Do you have any idea what values of are assigned to _AIC, 3 and _AIC, 4 if the analog input box is unticked? I don't. I have no idea what the controller will put in these Roboteq variables if there's no analog device connected and the tick box is unchecked. If I untick that box, the value boxes become blank instead of 9999, but the simulator gets numbers for _AIC, 3 and _AIC, 4 from the keyboard so I can't tell what either a 9999 or a blank will do. In most programming languages that I know, if you don't assign a value to a variable it has no value, but is "unnasigned" and that causes a run-time error. For variables that create in a MicroBasic basic script, 0 is automatically assigned unless you put in something different, but that doesn't necessarily mean that Roboteq followed the same rule in writing the controller firmware. Again, if you have a controller connected and intend to use the motor compensation subroutine, I think that you have to make sure that there is some value (real or software assigned) at those ports. Otherwise, comment out both GoSub MotorCompensationyyyy lines so that these analog ports are never read.

Same thing for motors. The script is going to send its results to _G and I don't know what the controller does if told to send a 100% duty cycle PWM to a motor that's not there. If you comment out the GoSub SetMotors line, the script will do all of its calculations, but won't send the results on to the motors. Maybe do this at first.

Ah yes, you're right, I can select a controller model even with none connected and working off line. Then the mute button does appear. It surely doesn't do anything if there's no one to talk to.

Ciao,
Lenny

[Burgerman]

On the screen below, tick off line box. Choose HDC2450. Now on all my PCs, inc the laptop, I see the same thing as below. Roboteq, and any joystick, definitely not connected!

Note tick box marked mute? And all analog, pulse inputs say 99999 unless the ticks are removed and then put back. Then empty. As shown. But they dont have any affect anyway. At least when DISABLED (no action) in roboteq software. When RC RX connected it reads 1500 (centred) give or take 1 either way.

[Burgerman]

When the program os opened and connected, the mute makes it behave normally. Otherwise the software takes over command via serial. Can be via those sliders, a windows PC joystick, etc.

Mute normally prevents the serial command data being "in charge" and the roboteq then uses the order you choose to decide which input to use. Poled every 1 second. In my case RC gets priority, since I can then switch on and drive my chair about and the analog joystick gets ignored. Switch off and the analog joystick takes over.

[Burgerman]

And I have carefully gone through every option disabling every input and all safety checking, guardbands, and so on, from end to end on the hundreds of options. So that a floating input, digital or analog, cant do anything. And same with motor section on the other side, every possibble thing set to "simple" so it will just work in easy to understand fashion!

[Burgerman]

Its datalogging, and real time graphs of control stick positions, and motor amps, output power, battery volts and loads more is really neat. Why cant powerchair controllers do all this stuff? They already have a big colour screen, with nothing useful on it! This softare runs fine on a small netbook, so you can watch all these graphs and log all the data as you drive. It absolutely helps in situations where the chair is stalled, to see if the battery voltage has collapsed, or the controller is "out of amps" etc. It would let you see how much that hill or grass was taking out of your chair too. Very educational for most users I would have thought. Even better for those that understand this stuff. This is FREE with the roboteq, as is the programming software.

And its now pretty safe. If we can just figure out this bit of code then compensation, and turn rates will also be sorted without using any electronics.

See graphing options (real time and storable) here (for those that dont have the software but may be interested...

[woodygb]

Your suggesting that the intermitent serial glitch is somewhere in the code / script?

[Burgerman]

Dunno. But it seems so. if I dont start the script, then as soon as I tick the mute (so serial control is supposed to be off, and it shows exactly this) then pulse RC input works flawlessly. And shows as pulse control, and all the curves, input and output do exactly as expected.

As soon as I run the script, (by starting it up on the controller itself, by sending !r and choosing "send"), the pulse input stops working normally, and it goes to serial input and no control. Everything at 100 percent forwards, and the pulse input on throttle has no affect. And the serial input light stays on, until I add some steering, then it goes to pulse (rather than serial) but still doesent actually work... Very odd behaviour.

[woodygb]

What exactly is connected to the Roboteq inputs ... A digital joystick and the Radio control? ...

The question seems to be is the script causing the Roboteq to revert to serial ..or is it an errant signal from somewhere..

If you attached 2 motors then you could perhaps disconnect the puter and see if everything settled down.

[Burgerman]

It wont. The problem isnt the PC, because the MUTE stops it sending commands.

What is connected? Just RC Receiver, and its working great. I drove the chair about with me in it via RC about 7 months back. Every other input is deactivated. No analog joystick.

Read the bit about script priority and serial stuff here. This is what I am doing. http://www.roboteq.com/how-to/microbasic-overview

Script Command Priorities - Quoted from link.

When sending a Motor or Digital Output command from the script, it will be interpreted by the controller the same way as a serial command (RS232 or USB). This means that the RS232 watchdog timer will trigger in if no commands are sent from the script within the watchdog timeout. If a serial command is received from the serial/USB port at the same time a command is sent from the script, both will be accepted and this can cause conflicts if they are both relating to the same channel. Care must be taken to keep to avoid, for example, cases where the script commands one motor to go to a set level while a serial command is received to set the motor to a different level. To avoid this problem when using the Roborun PC utility, click on the mute button to stop commands sending from the PC.

I do this! I have to anyway or it will never read the RC signal input

Script commands also share the same priority level as Serial commands. Use the Command Priority Setting to set the priority of commands issued from the script vs commands received from the Pulse Inputs or Analog Inputs.

This bit I dont get...

[woodygb]

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

[LROBBINS]

The Roboteq software can display all that information because it is running on a PC. An on-chair controller has a "computer" about like the one inside the Roboteq controller; a micro-computer. It can display some stuff on a screen (e.g. fault messages on Rachi's are not flash codes, but cryptically spelled out on her screen) and keep an internal log of information that you can read with the programming software on a PC. Can the Roboteq itself, without a PC attached, display any information at all? Can it display, log and upload logged fault codes? P&G, Dynamic etc. are actually getting quite a bit out of a microcomputer with limited bit depth, limited memory, and a clock running at a few MHz rather than GHz. Ciao, Lenny