PINNED - Roboteq Controller - developing for powerchairs

[LROBBINS]

Perfect, not the chair's behavior but the video. Between that and your statement

Roboteq acc set to 800 - all. It has no affect. Whatever its set to.

I think I know what's happening.

In the setup part of the script, near the beginning, I read the profile acceleration and deceleration settings:

Code: Select all

BaseM1Accel = GetConfig (_MAC, 1)
BaseM1Decel = GetConfig (_MDEC, 1)
BaseM2Accel = GetConfig (_MAC, 2)
BaseM2Decel = GetConfig (_MDEC, 2)


and then in MixAccel I add and subtract (M1 and M2)*SteerMixWeight to and from these. BUT, those profile accel/decel settings aren't being read, the base values are being filled with 0 (instead of whatever you set in the profile) so the script ends up just sending the steering bias rather than sum of profile setting +/- steering bias. The profile settings have no effect because the script thinks they're always 0, and SteerMixWeight has to be turned way, way up. If the profile value should be 300 and the bias is 3 (with SteerMixWeight = 100), we should send 303, but we're sending just 3. Raise SteerMixWeight to 10000 and we send 300, pretty close to what is really needed. To top that off, when the bias is negative, it will send a negative value of deceleration to the Roboteq, but that's meaningless and the Roboteq will say it's 0. This will severely mess things up when we're not decelerating from a steady turn, but doing other things.

I don't know why the Roboteq isn't sending those _MAC and _MDEC values to the script, but I do have a quick way to find out whether this is really the problem. The attached script doesn't attempt to read the profile settings, but just sets all the Base values to 300. It still won't respond to your profile settings, but at least it won't think the Roboteq is set for 0 acceleration and deceleration. Try it starting with a SteerMixWeight of 100 though!

Ciao,
Lenny

P.S. What version of the firmware do you have in your unit? Even if its the latest, you might try re-loading it just in case the reason these Roboteq commands aren't working is because the firmware has been corrupted. BUT DO THAT AFTER TRYING OUT THIS LATEST SCRIPT AND TELLING ME WHAT HAPPENS.

[Burgerman]

Acceleration is now really realy slow, deceleration too.

Still no steer on acc. Steer works as before on deceleration, once turned up to 1000 so I can actually see it. But it takes about 1 minute to get to 15mph and back to zero!

[Burgerman]

Latest firmware. Reloaded last night.

[LROBBINS]

John,

Remember how the profile file has 20000 when Roborun shows 2000.0? I don't understand this, but maybe it has something to do with 300 in the script giving very slow response. Look in that last script for the lines:

Code: Select all

BaseM1Accel = 300
BaseM1Decel = 300
BaseM2Accel = 300
BaseM2Decel = 300


change them to 3000 and give it another try. Start once again with a low value of SteerMixWeight.

I wish it were possible to run the motors and see PRINT results as well. Then we could see what values Roboteq returns for BaseM1Accel = GetConfig (_MAC, 1) etc.

Ciao,
Lenny

[Burgerman]

It is.

The last script screwed up the Roboteq. I reloaded the good work script, and the slow and weird behaviour remained.

So I turned off, and back on again, and then it worked normally again. ?

Right will try that.

[LROBBINS]

I don't understand.

It is.

To see PRINT results while running? I'd thought that every time we did that there were problems. Or was it only problems with the graphing?

For the rest, all I can say is HUH?
Ciao,
Lenny

[Burgerman]

Heres a log.

45 DEGREE STICK, And an extra zero added to all 4. Now accelerates fast again.

Acceleration no steering, deceleration at 100 steermix is just visible.

Heres a text log.

Change to .txt

[Burgerman]

No its easy to click record, but I didn't know you wanted that!

[LROBBINS]

That log file is useful. It confirms two things: the biasing of the motors during deceleration is working, and Roboteq's acceleration alone does the same thing while accelerating as it does while decelerating. Without a script, when decelerating both motors slowed down at the same rate until the inside one reached 0, then the outside one kept descending and the chair finally came out of the turn. With this script, which has NO effect on acceleration, both go up at the same rate until the left motor reaches 500, no turning yet, but the right motor keeps accelerating finally putting the chair into its left turn (assuming M1 is left and M2 is right - I could have that turned backwards in my head).

I am assuming that this is with the latest script with base acceleration/deceleration set at 3000. Tomorrow afternoon (Rachi has a dentist appointment in the morning) I will ask Roboteq what the accel/decel numbers in Roborun and the profile file mean, and what numbers GetConfig (_MDEC) retrieves and how the Roboteq interprets numbers sent with SetConfig (_MDEC) but not written to the EEPROM configuration.

Next, I will add biasing of acceleration to the script to see if we can get it turning while accelerating. That may have to be done very differently from during deceleration. That too is for tomorrow, at this hour my brain is turning to mush.

Ciao,
Lenny

[Burgerman]

The firmware I reloaded was not the newest. Its a couple of months old. I cannot load newest one that I downloaded a few mins ago, because my laptop and my PC say "DFU loader had a problem and needs to close. That worked 30 hours ago!

And

The latest few scripts are doing something odd. They require the Roboteq to be shut down before a new script can be loaded and work. No idea why.

[LROBBINS]

The need to turn the Roboteq off to load a new script may be because you have it set to autostart the script - though why it should be different with this script than older ones I have no idea.

I'm attaching a freshly (earlier today) downloaded copy of the firmware for you to try loading.

I noticed in the log file that the faster wheel only got to 800, rather than 1000. Did you have the speed pot turned down? Does it go up to 1000 if you go straight ahead max? If the answers are: No, the speed pot was at 100, and Yes, it does go to 1000 going straight forward, then the MixB algorithm isn't doing quite what you think it is - it's not (just) double slowing the inside wheel, but slowing both motors - it's like having a round restrictor plate that keeps you from getting full Throttle pot output when its pushed to the side as well.

Tomorrow,
Lenny

[Burgerman]

But theres a little program that loads it onto the Roboteq. Called DFU Loader. And it will not run on either of my PCs at the moment. I have had that before and I cannot remember what I did to fix it.

[Burgerman]

I noticed in the log file that the faster wheel only got to 800, rather than 1000. Did you have the speed pot turned down? Does it go up to 1000 if you go straight ahead max? If the answers are: No, the speed pot was at 100, and Yes, it does go to 1000 going straight forward, then the MixB algorithm isn't doing quite what you think it is - it's not (just) double slowing the inside wheel, but slowing both motors - it's like having a round restrictor plate that keeps you from getting full Throttle pot output when its pushed to the side as well.

If I hold the stick in the correct position it reaches 1000. And to 100 and right at the top of the screen. You can see it slow the inside wheel only. By RC (square stick) when you turn at full speed.

[LROBBINS]

Hi John,

Back from the dentist visit. Given that this involved about 2 hours each way to get there, and some waiting as well, I had lots of time to think about what's going on (or not going on) and to look at some of the Roboteq files and documentation.

I think that before we go any further, you have to make sure that the Roboteq software in your Roboteq and your PCs is working properly. There have just been too many, and increasingly troublesome, glitches.

First, we discovered that SetCommand (_ACCEL) and SetCommand (_DECEL) weren't doing anything, and the confused and partial messages on the Roboteq forum suggest that it's not just "broken" in your software (more about this below).

So, we substitute these with the nearly equivalent SetConfig (_MAC) and SetConfig (_MDEC) and find that these DO send acceleration and deceleration values to the controller, but then we find that the converse commands GetConfig(_MAC) and GetConfig(_MDEC) aren't reading acceleration and deceleration values from the controller (or are reading values that are far, far too low).

So I fixed the base acceleration and deceleration values at 300 instead of reading them from the controller, and we discover that when we sent them back to the controller with SetConfig (_MAC) and SetConfig (_MDEC) it acts as though they are 3 instead of 300.

Now, you can no longer download a new script without turning off the controller, and you can't upload a fresh copy of the firmware. (BTW, the USB upload firmware program DfuLoader.exe is part of the Roborun+ software, so the fact that your computer can't access it may suggest that the Roborun+ software has been corrupted - though it mystifies me that this happened on two computers (unless both were bollixed by a Windows update or a virus). Another possibility is that the controller's EEPROM has been corrupted - you might be able to clean that up by using the Reset Defaults button in the Roborun Configuration tab and then re-entering your configuration information - probably best to do that by hand rather than by loading a profile from disc.)

In any case, I think we need to know that the controller and Roboteq software are working at 100% before trying to fix what ails the script. If you can freshly install Roborun+ and freshly download the controller firmware, and find that the controller works properly without any script, I can then create some very simple scripts just to test _ACCEL, _MAC and so on and find out what values they are sending and receiving from the controller.

I have also decided to not write something to the Roboteq forum at this point, because thinking about the threads on this already there, I realized that there were either no answers or wrong answers coming from Griffin Baker (the Roboteq person who seems to handle forum queries). In particular, his advice to use SetConfig (_ACCEL) instead of SetCommand (_ACCEL) is just plain wrong, yet when the OP questioned this he didn't get any response. I know that it is wrong because I checked the Constants.h file in the Roboteq software where these things are defined. _ACCEL and _DECEL are defined (in the SetCommand section of the file) as:

Code: Select all

#define _ACCEL 7
#define _DECEL 8


What this means is that every time the compiler sees the word "_ACCEL" in a script, it just puts in the number 7. So the "real", but not-human-readable, function call is SetCommand (7). Now if your script has:

Code: Select all

SetConfig (_ACCEL)

this will be replaced with SetConfig (7,), but SetConfig (7) and SetConfig (8) already have meanings defined in constants.h and they have nothing to do with acceleration and deceleration:

Code: Select all

(in the Get/SetConfig section of Constants.h)
#define _CPRI 7 = the command priorities setting
#define _RWD 8 = the serial watchdog setting


I think that we are going to have to figure out what's not working and then talk with Cosma Pabouctsidis, but before we can do that we need to know that your copies of their software, in the controller and in the PC, are OK.

Ciao,
Lenny

BTW: I realized that we can actually use PRINT lines where the script does GetConfig(_MAC) and GetConfig(_MDEC) -- that's just in initial setup, before the loop, so there's no sending of serial while the motors are running. We will be able to add a few lines there to see what we get from the controller with these and what arrives in the controller after we do SetConfig(_MAC) and SetConfig(_MDEC).

[Burgerman]

Now, you can no longer download a new script without turning off the controller, and you can't upload a fresh copy of the firmware. (BTW, the USB upload firmware program DfuLoader.exe is part of the Roborun+ software, so the fact that your computer can't access it may suggest that the Roborun+ software has been corrupted - though it mystifies me that this happened on two computers (unless both were bollixed by a Windows update or a virus).

I suspect a windows update or some software not compatible on both my machines. Actually three machines when you consider the desktop is dual boot to my backup version... Something not compatible.

Another possibility is that the controller's EEPROM has been corrupted - you might be able to clean that up by using the Reset Defaults button in the Roborun Configuration tab and then re-entering your configuration information - probably best to do that by hand rather than by loading a profile from disc.)

Except the controller doesn't need to be plugged in or turned on. The firmware transfer DFU program should run fine and just not see a controller. But it fails on start up.

And the Roboteq only seems to have issues with the latest script. All the previous ones can be overwritten and all changes work fine.

I don't think there's anything wrong with the Roboteq firmware. Other than I wanted to put the very latest one on. I though 10/10/13 was the newest till I downloaded a fresh one yesterday.

I t may be one of the multitude of serial port/USB devices I use!

[Burgerman]

http://www.roboteq.com/index.php/forum/ ... ed-working

DFU issue obviously nothing new...

And it doesn't crash. Lets hope it updates firmware to the latest version later!

There's hardly any changes, but programmers all say that! While they fix things and create more bugs. They have done 2 things new. Neither of which are related.

[LROBBINS]

STMicroelectronics is the manufacturer of the MCU used in the Roboteq, so you should be safe using their DFU loader if it works.
Lenny

[LROBBINS]

Something is clearly wrong somewhere if such basic commands as GetConfig(_MAC) aren't working, but I have no way of knowing from what's happened whether it's the firmware or the MicroBasic compiler (part of Roborun). Here's something that may give you a clue.

With no script running, you can send commands directly from Roborun via serial (with MUTE unchecked). This does not use the MicroBasic compiler/interpreter, but the Roboteq API (written in C and already compiled). If these work properly via serial, the problem's NOT in the firmware, but in the MicroBasic compiler. If these also don't work via serial, you still won't know for sure: corruption of Roborun (which would also explain why their dfu won't work) or a firmware fault, or even, (spaghetti monster forbid) an MCU failure could all cause the controller to not respond to both script and serial commands.

What I'd do is this:
Set all Roboteq acceleration and deceleration parameters to 300 and make sure there's no script running. With sliders (MUTE unchecked) or your joystick check that both motors take about 3.3 seconds to go from 0 to 100% with full forward stick.

Double check that MUTE is unchecked and go to the Console tab.

in an Out data box, type ~MAC and send that
The In data pane should show 300:300 - the acceleration settings for motor1 and motor2
If it does, _MAC is working when sent by serial even though it's not working in the script.

in the next Out data box, type ^MAC 1 1000 and send that. This should change motor 1 acceleration to 1000. Some sort of confirmation of this may print in the In Data box as it will show all serial exchanges between the PC and controller.

Repeat:
in an Out data box, type ~MAC and send that.
The In data pane should now show 1000:300 because acceleration for motor1 has been changed to 1000

Now go to the Run tab and move the sliders up - motor 1 should accelerate 3.3 times faster than motor2.
Now check the MUTE box and work the throttle from your joystick - should get the same result, 3.3 times faster acceleration for motor1

Whether you do these tests first or not, I think that t'wer it me I'd uninstall and re-install the Roborun+ software (latest version).

Ciao,
Lenny

[Burgerman]

I have downloaded and reinstalled Roborun about 5 times on both computers. No change. All works perfectly except the tiny DFU program. However the manufacturers one allowed me to update and verify the latest firmware.

I then re ran yesterdays tests, nothing changed.

Will now do the thing in the last post.

[Burgerman]

in an Out data box, type ~MAC and send that
The In data pane should show 300:300 - the acceleration settings for motor1 and motor2
If it does, _MAC is working when sent by serial even though it's not working in the script.

Nope, 3000.

in the next Out data box, type ^MAC 1 1000 and send that. This should change motor 1 acceleration to 1000. Some sort of confirmation of this may print in the In Data box as it will show all serial exchanges between the PC and controller.

Showed just a: +

And one motor takes about a week to accelerate.

[LROBBINS]

One comment, one question and one further suggestion.

(1)

I then re ran yesterdays tests, nothing changed.

With that last script, nothing can change - the base acceleration and deceleration values are set in the script and not read from the controller.

(2)

I have downloaded and reinstalled Roborun about 5 times on both computers.

Just out of curiosity, are both of these Win7-x64?

(3) Now the suggestion. There's something very simple that you can do that might tell me whether there's a problem in your copy of the MicroBasic compiler, and you just need a PC, don't even need to have to connect to the controller.

Open Roborun, in the scripting tab check "Work Offline" and tell it that it's an HDC2450. Now open the "Accel_Mix_2014_06_23 _baseaccdec300" script file and look for the lines:

Code: Select all

'BaseM1Accel = GetConfig (_MAC, 1)
'BaseM1Decel = GetConfig (_MDEC, 1)
'BaseM2Accel = GetConfig (_MAC, 2)
'BaseM2Decel = GetConfig (_MDEC, 2)


(should be around line 82)

Delete the ' comment markers, and click the Build button. Wait a bit and there'll be a long listing of the compiled program. Copy about the first ten screens of that, paste it into any text editor and post it or send it to me. I'll compare it to what I get here (which seems to compile those commands correctly) to see if there's anything obviously strange going on. Go down to the very end of that build output and make a note of the "Total program length" and tell me that number. That too should match what I get on my computer.

Ciao,
Lenny

[Burgerman]

Just out of curiosity, are both of these Win7-x64?

Yes.

[Burgerman]

@ Total Program Length is 3562 byte(s).

I have vers 1.2 and 1.3. Defaults to 1.3.

[LROBBINS]

Thanks John. Our two compiled files are identical (as far as we both copied and pasted them) and the total bytes are the same. There is no obvious craziness in either MicroBasic compiler.

Now, let's see if we can figure out what's not working with these Roboteq acceleration commands. There are several possibilities that I can think of: (1) they are simply broken, (2) they work but the values returned are much smaller than the values that actually have to be set (that weirdness of 2000.0 in Roborun and 20000 in the profile xml), (3) they work, but can not be changed, or the change takes affect with a delay, while motors are running - if that's the case, we definitely have to go back to the "sending Throttle in little bits over an extended time" approach unless we can convince Roboteq to apply their mix algorithm do acccel/decel.

So, here's a test script to try. THIS IS NOT A SCRIPT FOR ACTUALLY CONTROLLING A CHAIR - do not even bother to touch the joystick. Just a script to exercise the _MAC get and set commands and see what happens.

Definitely turn off Autorun.

Make sure all the accel/decel config settings are at 300.

Load this into your controller with the chair on blocks and run it while making a video of the graphs. Save the log files as well.

There is no loop in this program. It will run just once, take about 1 min 20 seconds to run, and then exits. Both motors will accelerate and decelerate repeatedly: motor 2 will always do so at the 300 "motor units" per second set in your configuration, and motor 1 at various rates (there are comment lines in the script that describe this). Send me the results and I'll see what I can figure out by comparing motor 1 vs. motor 2 and the different cycles of motor 1.

Ciao,
Lenny

[LROBBINS]

Did it again. Posted the message without the attachment.

[Burgerman]

That's what I was waiting for!

[Burgerman]

http://www.wheelchairdriver.com/a.zip

Real zip...

EDIT... My PC shutdown while uploading... So it will not work. I think.

[LROBBINS]

My PC shutdown while uploading... So it will not work. I think.

Yep, can't open it.

[woodygb]

Try this.

http://www.diskinternals.com/zip-repair

It worked for me and recovered the video file.

[Burgerman]

Its on my other PC and I will re upload as soon as I can get up...