PINNED - Roboteq Controller - developing for powerchairs

[Williamclark77]

I haven't had a chance to post, but here is the linear accel pot installed. That's it in front of the round speed pot. All the way back and she's as tame and smooth as a granny scooter. Slide it forward and ZOOOM! Lots of wheelie oomph. The linear pot does slide a bit too easy. I'd like it to have more tension. It hasn't bounced into different positions in my limited testing though.

Man, my joystick housing looks rough in pictures! I have ordered a 3d printer. Hopefully soon I'll have a full blown custom built from scratch one that looks MUCH better.

Crap picture taken in the near dark last night.



Video of some high speed running from last weekend. Those casters take a pounding! You can tell just how much time they spend in the air too.

http://www.willsjunk.com/Other/WillChai ... -MNZFRpG/A

Same day. The video doesn't do justice for just how rough and muddy this area is. This area is under running water much of the year.

http://www.willsjunk.com/Other/WillChai ... -4GzWBRk/A

[Burgerman]

Those vids make any normal mobility chair look stupid.

Although I may suggest you get some spare caster and wheel bearings in stock. Because looking at this they wont be lasting very long!

[Williamclark77]

I bought extras!

It is a shame others confined to chairs don't get to experience this.

After seeing the video showing how hard they get pounded I'm not surprised that the original caster fork roller bearings I used were destroyed in no time! I don't feel any of that in the chair. Nor is there any gearbox whine. The cam is mounted right in line with the right gearbox.

The 3/4" id (can't remember the od - about 2") tapered roller bearings SHOULD last. They're made for a tractor disc (I'm sure many other things, but that's what I bought them for). Two of these in each caster barrel. The wheel bearings are cheapies though. They'll be upgraded whenever I get around to having the caster forks and a few other bits powder coated.

Overkill? Naaaaaw.




I have gotten caster shimmy a few times that was bloody scary on pavement. If I wheelie at 8+ or so mph and they land crooked they don't always smooth back up if I stay on the throttle. They shook me hard enough to make the rear of the chair jump side to side. Scary. Like headshake or tank slap on a motocross bike. Let off just enough to put weight on them and they get back smooth. I need to add a little more preload to the bearings. There's almost none.

I need to update my build thread too.

[Burgerman]

3 things I know of that would stop that caster shake.

1. A set of these http://www.partsbrothersonline.com/inde ... ct_id=2684 and I tried some similar ones 2 years ago on a chair that insisted on shaking. Complete cure. At least on that chair. They put more rubber on the ground and it aids damping. And they ride on soft stuff too.
2. More trail. But then the caster starts hitting stuff...
3. More damping, wave washers, silicone sleeve etc.

Sometime they do it. Other times they don't. Its all a mystery.

[ex-Gooserider]

Just as a thought, I'd be a bit concerned about how well a slide pot will hold up in a pod that may be subject to getting rained on, splashed with mud and so on... The slide pots that I've encountered had relatively little protection over the opening for the slider - and I don't see a really good way to protect that opening.

OTOH, the Bournes rotary pots that I have used to add speed pot functions to my P&G pods are IP rated to IP65 or 66 as I recall, which means that they are proof against pretty much anything short of total submersion.

ex-Gooserider

[LROBBINS]

CRITICAL UPDATE - ERROR IN MOTOR COMPENSATION SUBROUTINE

I finally installed a "quick change" wiring harness on Rachi's chair so that I can attach my CAN+Roboteq system when she's not using it and swap back the Dynamic DX when she is, and I discovered a majorly stupid logic error in the Motor Compensation subroutine that makes compensation almost completely ineffective. The result was exactly what John has experienced: sluggish initial acceleration and then "woosh". (Far less evident on Will's chair with its low-impedance brushless motors.) Fixing this is a mandatory change, but before you make the changes that follow below, set your MotorResistance values to something you are sure is absolutely safe. MotorCompensation is going to work MUCH better after this change, and you definitely don't want a runaway chair.

The problem is in two lines in a section starting about line 349:

Code: Select all

349   IF (abs(oldC1-C1) <= 3) OR (GetTimerState(3) = 0) THEN
350     C1 = oldC1
351   END IF
352   IF (abs(oldC2-C2) <= 3) OR (GetTimerState(3) = 0) THEN
353     C2 = oldC2
354   END IF
355   IF (C1<>0) OR (C2<>0) THEN
356     SetTimerCount(3, BrakeDelay) 'reset timer anytime stick not centered
357     SetTimerState(3, 0) 'start timer
358   END IF

The GetTimerState(3) = 0 in lines 349 and 352 should be GetTimerState(3) = 1! Like this:

Code: Select all

349   IF (abs(oldC1-C1) <= 3) OR (GetTimerState(3) = 1) THEN
350     C1 = oldC1
351   END IF
352   IF (abs(oldC2-C2) <= 3) OR (GetTimerState(3) = 1) THEN
353     C2 = oldC2
354   END IF
355   IF (C1<>0) OR (C2<>0) THEN
356     SetTimerCount(3, BrakeDelay) 'reset timer anytime stick not centered
357     SetTimerState(3, 0) 'start timer
358   END IF

What's going on here?
John had noticed that if a stopped chair was jostled, the motors, acting as generators, produced enough current that MotorCompensation changed C1 and C2 a bit which could cause the brakes to release. I did two things to fix this. The first was just to not apply MotorCompensation (that is, use the oldC values) if the change was <= 3 (out of 1000). This helped, but at least on the bench I could still force a motor hard enough to get the brake to release, so I added something else.

Why is the existing code wrong?
Whenever the stick is out of neutral (line 355), a timer is started, and continuously re-started so it stays running as long as the stick is out of neutral. If the stick is in neutral, the timer starts counting down and if it keeps on counting down for BrakeDelay milliseconds when it finishes and changes state. BUT, GetTimerState is 0 when the timer is RUNNING, not when it is STOPPED! The first time through loop with the stick off center, the timer hasn't yet been started, GetTimerState = 1 and MotorCompensation is applied. Then the timer starts, and the next time through the loop GetTimerState = 0, and C1 and C2 stay at oldC1 and oldC2, with only as much motor compensation as was calculated when the stick just started to move off center not the motor compensation corresponding to where the stick is now. And it will continue using this too-low amount of compensation until the stick again is at neutral for BrakeDelay milliseconds.

How does changing 0 to 1 fix this?
The first time through loop with the stick off center, the timer hasn't yet started, GetTimerState will return 1, and there's no motor compensation (see note below as to why this is a good thing). Then the timer starts, so the next time through the loop a few microseconds later, and every other time through the loop as long as the stick is out of center, a freshly calculated motor compensation gets applied. If the stick is moved, or the load changes (as it will as rpm changes), the new, correct motor compensation is again applied. That's the way things should work!

Yesterday, when I first hooked up the new controller and started testing with the speed pot turned all the way down I couldn't turn in place, and going fore-aft or turning while moving gave the sluggish then zoom response. Scary, even with speed pot at minimum, because I was doing this in our living room - can't be running at any speed with the whole controller rig just sitting on the rear deck of the chair. So I started to increase MotorResistance, and wasn't seeing any great effect even with absurdly high values, and the numbers in Roborun weren't showing any change with supposedly increased compensation either. Could my calculations be off by a factor of 10 or 100? I started to put some print statements in the script to see where things were going awry, and that 0 instead of 1 stuck out like a sore thumb.

Today I fixed that, remembered to turn MotorResistance way back, and I could now turn in place (just barely at pot min - some tuning still needed on that), but the chair was now accelerating correctly out of the gate without the adrenaline effect. Now I started to increase MotorResistance - nothing, nothing, TOO MUCH, and instead of just juddering, it seemed OK moving forward or back, but then just didn't stop - right into runaway. Adrenaline was back, and the first time I wasn't really prepared to pull the emergency stop plug until the chair was jammed in the corner of the living room. Dialed back MotorResistance, and all seems well at 150 milliohms (the Dynamic is set at 120, it starts to judder at 150, so my calculations aren't too far off ). The lack of juddering with resistance set just a bit high may be because throttle/steering changes <= 3 are discarded by the script - they may "count" in the Dynamic. So be extra cautious - the first sign of getting motor resistance too high may be not being able to stop!

So far, with MotorCompensation working as it should, AccelMotorComp and DecelMotorComp seem to have much less effect than they did when motor compensation wasn't correct. They may not be needed or even useful at all. Now that I have my own test bed, especially once I have a way to tie the controller to the chair, I'll be able to find out. You also may want to turn accel and decel down as the chair will get moving better without need for excessive values. Will may also find that the acceleration pot is less needed.

Ciao,
Lenny

NOTE: Why is it a good thing for there to be no motor compensation the first time through the loop after moving the stick out of neutral? When you move the stick out of neutral, the brakes are released, but it takes a finite amount of time for the disk to move. The first time through the loop you could be applying compensation with a locked rotor. Though this will self-correct the next time through the loop, it's probably easier on the motor and controller to have this slight delay (some microseconds, at most 1 msec) before boosting PWM.

[Burgerman]

Thanks. Will make the changes.

I have a slightly odd problem. I have 2 scripts.

And I cannot remember which is loaded... And what the difference was.

Is there any way to read the one loaded in the roboteq? Or at least compare it to the two I have here? (by size maybe?)

Here they are.
Ignore the 3.3 that's for my use.

[LROBBINS]

Is there any way to read the one loaded in the roboteq? Or at least compare it to the two I have here? (by size maybe?)

Not that I know of. When you Build a script it does show total size at the end of the listing, but I have no idea how you'd get that of of the controller itself. Tools from the processor manufacturer probably exist to do that, but I don't think that you'll find them in Roborun. I've taken to putting a Print line at the top of my programs so that I can see what file it is in the Roborun Console tab, but I have to remember to update that line every time I change the script. For the Arduino programs, where until day before yesterday I'd been doing the same thing, I now came across something that makes it easier - there's a macro built-in to the Arduino package that serial prints file name, and last modified date and time:

Code: Select all

Serial.println(__FILE__ " - " __DATE__ " " __TIME__);

Can you find the lines that are different in the two scripts you're looking at? Perhaps I'll be able to compare those with my "base" copy and be able to at least tell you how they might behave differently.

Ciao,
Lenny

[Burgerman]

In the two scripts in the above zip, that I thought were the current ones, that bit of code doesn't appear the same way. At least not identical.

So I cant see how to modify it ... Or at least be sure.

(The only difference between the two is that one has AccelMixMode added?) (3.3beta) And will isn't using this. I don't think I tested it yet either. So 3.2 is the current one we are both using.

WE HAVE:

Code: Select all

MotorCompensation:
'NOTE: extra boost at low speeds only applies to ESTIMATED current; if SENSORS are used
'boost calculation is ignored
   'find motor currents
   IF UseCurrentSensors = TRUE THEN
      IF SuppressPrinting = FALSE THEN
         PRINT ("\n", "READ 10X M1 AND M2 CURRENT SENSOR VALUES \n")
      END IF
     LeftSensorValue = GetValue (_AI, LeftCurrentSensorPin) ' raw (relative) mV
     RightSensorValue = GetValue (_AI, RightCurrentSensorPin)
     LeftSensorDiff = LeftSensorValue-LeftSensorZero '20 mV = 1 Amp
     RightSensorDiff = RightSensorValue-RightSensorZero
'     IF abs(LeftSensorDiff) <= 5 THEN 'ignore currents less than 1/4 Amp
'       LeftSensorDiff = 0
'      END IF
'     IF abs(RightSensorDiff) <= 5 THEN
'       RightSensorDiff = 0
'     END IF
      ILeft = LeftSensorDiff/2 '10X left motor Amps from external 100A sensor
      IRight = RightSensorDiff/2 '10X right motor Amps from external 100A sensor
   ELSE
      IF SuppressPrinting = FALSE THEN
         PRINT ("\n", "READ 10X M1 AND M2 CURRENT ESTIMATES \n")
      END IF
      ILeft = GetValue (_A, 1) 'estimated current in units of 10X Amps for left motor
      IRight = GetValue (_A, 2) 'estimated current in units of 10X Amps for right motor
   ' boost motor compensation at low currents to deal with error in motor current estimation and/or
   ' increased impedance of brushless motors at low output
      IF SuppressPrinting = FALSE THEN
         PRINT ("Estimated current: Left = ", ILeft, "  Right = ", IRight,"\n")
     END IF
     IF A1 > BoostStart AND A1 < BoostEnd THEN
        IF ILeft <= BoostEndCurrent THEN
            BoostFactor = MaxBoostFactor*(100-(100*ILeft)/BoostEndCurrent)
           ILeft = ILeft + (BoostFactor*ILeft)/100
        END IF
      END IF
     IF A2 > BoostStart AND A2 < BoostEnd THEN
           IF IRight <= BoostEndCurrent THEN
            BoostFactor = MaxBoostFactor*(100-(100*IRight)/BoostEndCurrent)
           IRight = IRight + (BoostFactor*IRight)/100
        END IF
      END IF
      IF SuppressPrinting = FALSE THEN
         PRINT ("\n", "Boosted current estimates: Left = ", ILeft, "  Right = ", IRight, "\n")
      END IF
   END IF
   'do mixing to find motor values (DO NOT TRUNCATE - will be un-mixing later)
   M1 = C1 + C2
   M2 = C1 - C2
   IF (NOT(M1 = 0)) AND (ILeft = 0)THEN
'PRINT ("LEFT MOTOR DISCONNECTED \n")
   END IF
   IF (NOT(M2 = 0)) AND (IRight = 0) THEN
'PRINT ("RIGHT MOTOR DISCONNECTED \n")
   END IF
'apply IR compensation; everything converted from volts to 0-1000 joystick units and *100/10 used to reduce
'granularity
   BattVolts = GetValue (_V, 2)
   M1Comp = (10*ILeft*MotorResistance)/BattVolts
   M2Comp = (10*IRight*MotorResistance)/BattVolts
'modify motor command values in accord with motor compensation
   M1 = (10*M1 + M1Comp)/10
   M2 = (10*M2 + M2Comp)/10
'modify acceleration and deceleration rates in accord with motor compensation
   BaseM1Accel = M1Accel + AccelMotorComp*abs(M1Comp)/10
   BaseM2Accel = M2Accel + AccelMotorComp*abs(M2Comp)/10
   BaseM1Decel = M1Decel + DecelMotorComp*abs(M1Comp)/10
   BaseM2Decel = M2Decel + DecelMotorComp*abs(M2Comp)/10
'undo mixing to get back new THROTTLE and STEER values
   oldC1 = C1
   oldC2 = C2
   C1 = ((10*M1 + 10*M2)/2)/10
   C2 = ((10*M1 - 10*M2)/2)/10
'ignore small changes to avoid brake clicking and motor judder if motor milliohms set high
'and make sure physically jostling the chair with stick centered can't release the brakes
   IF ((abs(oldC1-C1) <= 3) OR (oldC1=0)) THEN
     C1 = oldC1
   END IF
   IF ((abs(oldC2-C2) <= 3) OR (oldC2=0)) THEN
     C2 = oldC2
   END IF
'truncate in case compensation pushed THROTTLE and/or STEER over limits
   IF (C1 > 1000) THEN
      C1 = 1000
   END IF
   IF (C1 < -1000) THEN
      C1 = -1000
   END IF
   IF (C2 > 1000) THEN
      C2 = 1000
   END IF
   IF (C2 < -1000) THEN
      C2 = -1000
   END IF
   IF SuppressPrinting = FALSE THEN
      PRINT ("compensated THROTTLE = " , C1 , "    compensated STEER = " , C2, "\n")
   END IF
RETURN 'End of "MotorCompensation:"


So a little different. Will it still work if I change the two 0 to 1?

[LROBBINS]

John, I just looked at 3.3 beta and compared it withe the one I've been maintaining to use with analog connections on my HDC2450. If what you have in your controller is 3.3 beta - do not use it. It does have the corrected MixAccel calculations, but does not have later corrections to how current sensor data are used, nor the AccelComp and DecelComp coding etc.

I am attaching the file that I've been using with analog joystick. The user settings and pin connections WILL NOT BE CORRECT for your controller, but the code is current, and includes today's correction. Do you have a program that can compare text files and list differences (I use document compare in WordPerfect for that)? If you do, you can compare this file to any you have in your hard disk - if you find one that matches this except for user and pin values, the introductory comments at the top, and today's changes, that's probably the last one you'd been using. In any case, your best bet is probably to start with the file attached here (not really a zip) and just change the pin and user settings to yours.

Ciao,
Lenny

[Burgerman]

Great. Will get to it!

I can go through manually.

Theres no pin/settings in the code? Just in the user settings correct?

[Williamclark77]

Just as a thought, I'd be a bit concerned about how well a slide pot will hold up in a pod that may be subject to getting rained on, splashed with mud and so on... The slide pots that I've encountered had relatively little protection over the opening for the slider - and I don't see a really good way to protect that opening.

OTOH, the Bournes rotary pots that I have used to add speed pot functions to my P&G pods are IP rated to IP65 or 66 as I recall, which means that they are proof against pretty much anything short of total submersion.

ex-Gooserider

These look to be pretty susceptible to moisture getting in. How much affect that will have I don't know. My chair is out in the nasty a lot. I don't really have a way to seal it up easily. We shall see!

Lenny, I'm excited to try this update out. I SHOULD have time to tonight when I get home from work. I'll report back as soon as I do.

[Burgerman]

Took 5 mins. Now need a strong man to get chair on blocks to try it...

May get another Roboteq to fit the chair 2 that I am rebuilding... I set Compensation down from 100 to 35 to test.

It was doing something, just not quite correctly. 45V disguises the compensation issues.

[Williamclark77]

Took me a few minutes because, apparently, I was using an older script. I had to add the code I did for myself in different places. Mine was definitely different

Short test. I'm in the chair now. It's safe. Been rolling around the house for a bit. I will need to lower my accel rate. It's a bit jumpy until I decrease the rpm/s rate and a few other tweaks (can't reach the Roboteq to plug it in while in it and Sommer is busy), but does feel like it requires less stick input to get the same result and needs tamer settings.

I'll test it much more thoroughly when it quits raining and I can go outside in it. It was 81 degrees F here today. Supposed to drop below freezing tomorrow. I'll get back in it and try when I get home tomorrow evening.

[Burgerman]

(can't reach the Roboteq to plug it in while in it and Sommer is busy),

I have a 600mm extension USB plugged in and cable tied just under the seat frame so to get easy access.

Did you lower the CALC figure for compensation?

It's a bit jumpy until I decrease the rpm/s rate

Which means its working.

[hank]

John the tyres you listed above the kenda smooth 9x3.50-4 would they work ok on just tarmac work.As they look a better quality structure.Obviously with a inner tube
or better sticking with the 3.00-4 rounder profile as std.

[Burgerman]

If they fit inside your forks. They grip tarmac and concrete better. But they may hinder turning etc - all depends on your programming, and on your weight bias.

Try a set and see.

[hank]

Only consern is overall dia smaller. so would have to lower back to get caster pot on frame vertical again for front forks.
But could get round that. Suck it and see then.Thankyou.

[Burgerman]

Its 12 to 15 mm smaller. (Only bottom half counts here!) so isn't that critical. The only worry is that some are wider and some are not... Nominal sizes mean its guesswork. I have some that go in the stock fork, and some that don't.

[Irving]

Do you have a program that can compare text files and list differences

http://winmerge.org/ is a good tool...

or use Notepad++ (my go to editor for most files) and use the 'Plugin->Compare->Compare' feature...

Both allow moving stuff from file to file...

[Burgerman]

I have things like that. But if its just a bunch of user settings it takes just 5 mins and I get to see and remember what it all does and what I set up.

My edited file (but with slow accelerations) is here:
http://www.wheelchairdriver.com/BM3-con ... Script.txt

I am calling this V4.0 for my own purposes and is the latest.

[Burgerman]

OK. QUICK TEST.

Motor compensation finally is predictable and gives much better control at very small stick movements as it should. This has taken away my "delay" as far as I can tell. Testing via RC only so far with my carer as ballast. (sorry Jenny!) Now I need to figure out what to set it to. 45mOhm at the moment.

On blocks:
Setting compensation up to 350 which is way too high, (using sensors) and the wheels slowly rotate forwards very slowly and slightly jerkily, at zero stick. And if you put your hand on either one it speeds up! That is sort of what you would expect setting motor compensation too high would do. If it was on the ground it would definitely run away. It wasn't doing this before.

Setting compensation to a lower level of 250 and using calculated current (set sensors to FALSE), gives asymmetrical results on each wheel, and does some odd un-predicable things. Like snatches a wheel suddenly (always same one) if you steer in reverse and then cuts all power... I don't recommend using this. Will you are going to need your current sensors hooking up.

I think the Roboteq only measures battery amps (total) and tries to guess which motor is pulling what Amps. It doesn't work. Free running it "sees" one motor pulling 15A and the other 8A where my clamp meter sees them identical. So that will not work correctly. It adds more compensation than needed to one wheel, and non to the other...

[LROBBINS]

John,

Your result with estimated current and way high motor resistance setting is not unexpected, and may not be a problem either. The Roboteq does measure battery current for each half of the motor board, but the measure is very grainy - my recollection is that the manual speaks of 1/2 amp steps on the larger controllers. So, just from noise one side may say 1/2 amp battery current at say 1% PWM, and estimate 50 motor amps (0.5/0.01), when the other one says 0 battery amps and 0 motor amps. Motor compensation for the "high" motor will be M1Comp = (10*ILeft*MotorResistance)/BattVolts. With estimated 50 Amp motor current, and 250 mohms resistance that is = (10*500*250)/420 = 2976 and compensated M1 = (10*M1 + M1Comp)/10 = (10*0.01 + 2976)/10, but 10*0.01 is zero in integer arithmetic, so this becomes compensated M1 = 297 = over 1/4 stick equivalent. That motor's going to really take off, while the other does nothing. Later on, both might be at 0 amps, and both motors stop.

Whether things will still be too twitchy at low stick with estimated current and more reasonable motor resistance, I don't really know, but I'm sure Will will soon be telling us what happens.

Ciao,
Lenny

[Burgerman]

It works exactly as it should with the sensors. But that wont help will I think. Because those sensors must be seeing some AC waveform??? And so averaging current to zero? Buggered if I know to be honest! Wonder what Roboteq say about current sensors on brushless? May be worth will asking them.

[LROBBINS]

If those sensors can't be used as is with brushless, there may be several ways to deal with it:

(1) Use unidirectional sensors, but these may not be available pre-mounted on those handy boards.

(2) Use the bidirectional sensors, but set the analog range in Roborun from center point to one end only with all values from center point to other end just ignored. Assuming that the AC motor current is near symmetrical, the swing in one direction should work whether going forwards or backwards.

(3) Use estimated current, but have the script ignore it if abs(Throttle)+abs(Steering) < 50 [or whatever number is needed to avoid compensating when stick is very close to center]

Ciao,
Lenny

[LROBBINS]

Time to give you the results of some testing - delayed because I first had to find and fix something that was crashing Rachi's voice computer - it was a failed, 27 year-old, 55watt 24V to 12V DC-DC converter that was shorting intermittently and driving the switch interface crazy until it blew its fuse. Cure was to take it out of the circuit, install the switch interface I made for the new system that operates on 5V from either USB (which is all I'm using for now) or (automatically by diode logic) from any of the CAN nodes. Left me without 12V for the audio amplifier, which sounds awful at 5V, so it's running on a 9V battery until I get a little 500 mA 12V DC-DC converter just for it. (I was using that old converter, which had actually powered Rachi's first couple computers, just cause I had it - I have no need for a 55 watt converter. Cost a pretty penny way back when.)

So, this afternoon was my first chance for a serious go at getting user settings right. First off, the corrected motor compensation, as John has already reported, works the way it should. Nevertheless, there was still too much hesitation doing turn-in-place at very low rates. The casters are hard to turn because they are (1) low pressure slicks, (2) carry ca. 30% of chair weight on a FWD, and (3) the stems are inclined top forward because I hadn't properly accounted for "squish" of the drive tires, and then when I had to change to the Kendas ended up with smaller-still drive tires. So starting a turn means not only friction but actually lifting the rear as the casters turn. (I have to do some cutting and welding to fix the geometry, but can't seem to get around to it.)

So I tried out AccelComp, that boosts the acceleration rate when current is high. Had to go to a pretty high value - at least 100 - but that got rid of the stickiness of the heavily loaded, hard to turn casters. Ended up settling on AccelComp and DecelComp both at 200, and dropping MotorResistance from 150 to 110 (exactly the same as was set on the Dynamic DX). Note that AccelComp should have very little effect on runaway tendency - it doesn't change the command value as motor compensation does, just the speed with which one gets to that value. It might do so secondarily because accelerating harder, even to very slow motor speeds, will probably increase current flow and increase compensation, hence my caution on the MotorResistance value.

Now, there's no problem starting very slow turns except on carpet where there's still some hesitation, so I may be turning the MotorResistance up some more, but I want to wait until I've gotten it outside on uneven terrain and at various speeds to make sure I can't get into a runaway inducing situation.

I did add another "safety" to my MotorCompensation routine - if the joystick is centered (i.e. abs(Throttle)+abs(Steering) <= 2, just barely outside deadband), current is not measured but set to 0. In other words, if the stick is centered, motor compensation is turned off. Thus, I should be able to get out of a runaway just by letting go of the stick. This is not yet in the analog version of the script, just the CAN version.

I am going to change some of the user settings. We have speed pot min and max (for throttle) but then reverse speed, forward steering and reverse steering as percentages of throttle, and reverse throttle, forward and reverse steering weighting of the speed pot. As I was fiddling with adjusting turn settings, I found myself using pencil and paper to calculate what the minimum and maximum turn rates are at pot min and pot max. Well, if the minses and maxes are what makes human "sense", that's what the user setting parameters should be and I should let the computer do the calculations. So, I'll be changing to Throttle Forward min and max, Throttle Reverse min and max, Steering Forward min and max, and Steering Reverse min as max as the user settings (I think that the number of parameters remains the same, but that it will be easier to think about it in these terms while adjusting things. Each parameter affects just one thing, rather than more than one as weighting percents do.) Don't worry, I'll get this worked out in the CAN system before I make changes to your script. Actually a bit harder to code for the Arduinos than for the Roboteq - C gives a lot of flexibility, but I have to keep straight my byte, int, longint, usigned int and unsigned long int variables and make sure I don't truncate things by doing something like multiplying two bytes and trying to fit the result in a byte, when it actually is much larger. The Roboteq wastes RAM by allowing only 32-bit signed integers, but that much about MicroBasic does make a programmer's job easier. Once I have the new arithmetic worked out for my Master node, translating it to MicroBasic just means simplifying it.

So, aside from the tedium of changing parameters over and over to get things a bit tuned, I'm a pretty happy camper tonight.

Ciao,
Lenny

P.S. Depending on how fast the analog-to-digital converter and script are in the Roboteq, Will may be able to use the bidirectional current sensors just using abs(I) and then the sign of the motor commands to know whether it needs to be added or subtracted. If the ADC and script aren't fast enough, however, it will just average the positive and negative values rather than converting the negatives to positive with the abs function.

[Burgerman]

So...

Should I also start with AccelComp and DecelComp both at 200 too? Considering 45V and so on?

Although it seems pretty good set to zero.

[LROBBINS]

No. Start with it at 0 and get everything else set as best you can without adding AccelComp and DecelComp.

Then, with speed pot set at minimum, see how it does doing turn in place. With your lightly-loaded casters it might not need any at all, and if it needs some, it will probably be much less than what I've set. I'd probably go in increments of 10 up to 50, then, if 50 is not enough, try 100, 150 etc., but you'll probably stop well short of there.

I'm really dealing with an awful geometry and loading; you are not. Just make sure your MotorResistance is set well under the skittish point.

Ciao,
Lenny

[Burgerman]

Then, with speed pot set at minimum, see how it does doing turn in place.

At least as good as any mobility controller. And my turn rate is pretty low at min pot. It is 70% of the 18% of full speed. So about 12% of total at full stick set to low speed.

That's about 4% of 45V at a third of a stick. And that easily turns it on heavy carpet or grass. About 1.8V average without compensation...

That 4 percent makes it less precise or more "lumpy" at really small stick movements. A result of same impedance and double the volts. Less resolution at slow speeds. But barely detectable. That said it easily crawls at just a few mm per second.

[Williamclark77]

Whether things will still be too twitchy at low stick with estimated current and more reasonable motor resistance, I don't really know, but I'm sure Will will soon be telling us what happens.

Ciao,
Lenny

Whether things will still be too twitchy at low stick with estimated current and more reasonable motor resistance, I don't really know, but I'm sure Will will soon be telling us what happens.

Ciao,
Lenny

I was in the chair all day yesterday. Indoors and out with plenty of tedious driving along with 1/4 mile high speed runs mixed with rough steep muddy hills. I had to edit the parameters a bit tamer to remove the jumpiness at low throttle. It felt fantastic. It's better. I still get a bit of issue zero turning in grass or mud, but as Lenny has with his test chair, I have a good bit of bind in my casters due to not much offset. It does have a bit of the "lumpy" feel as BM says, but with the combination of my motors being brushless along with 46.5v in operation, that's to be expected.

I can feel the issue Roboteq has with high amps and very low input pwm. Mainly on the side of a steep hill at very low speeds as one wheel goes over a hump or rut - think driving horizontally along a steep hill at VERY slow speeds, maybe 1/3 of a walking pace. It feels like it may add input to the wrong wheel at times - I believe I can anyway. Encounter an obstacle to one wheel and it tries to SLIGHTLY turn vs holding straight. I did not really notice it until reading BM's post. With that said, between my suspension flexing and tire sidewall giving it is hard to tell which is causing or giving the affect. It could be the wrong motor being applied heavier or simply the suspension/tires flexing as it encounters an obstacle. Either way, it is not a real issue and better than before. Nothing enough to make me want to hook the sensors back up. PITA and I pirated the wiring from one for my accel pot (which is still needed/wanted by me, but not nearly as much).

I'll play with the AccelComp when I get a chance again. It may not be until the weekend. It's starting to rain again now and supposed to all week.