PINNED - Roboteq Controller - developing for powerchairs

Power wheelchair board for REAL info!

POWERCHAIR MENU! www.wheelchairdriver.com/powerchair-stuff.htm

Re: Some thinking and questions about Roboteq

Postby Burgerman » 10 Oct 2017, 23:04

Did you do this? Did you do this before increasing LowIboost? Please go back to that post of mine, follow the order of things there, and tell me what you get at each step.


I did. Lowboost did as I said. 10 ok. 20 was no way to turn super slow. 1mm of stick made it turn at slightly too fast rate. Setting highher made it worse.

Setting CompTurnBoost to 150 (half of motor compens.) made it turn too sharply on a tiny bit of stick...

Setting to 50, made it more controllable. But neither fixed the dragging wheels.

Changing the two lines had no real affect. On anything. As far as I can tell.

The graph screen on roborun isnt usable with the print on, as it updates evey few seconds...
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 10 Oct 2017, 23:08

Set ComptTurnBoost back to ZERO and turn LowIBo0st up 1 unit at a time. Don't touch CompTurnBoost again until basic motor compensation is working right - if we ever do get it working right.

If you can't use the Console log when the bot is on its wheels, how can you use the Run tab graph anyway. If you want to somehow watch the graph, and aren't using the print lines for anything, comment them out. The Roboteq MCU has only a 32 character print buffer and things really can hang up if that's exceeded. We can reduce the interference with graphing by printing shorter lines less often, but that also reduces the time resolution of what we can see in the console. If you do come up with a way of logging what's in the console, I'll re-do the printing so that short lines are sent in different loop cycles (at 100 cycle intervals rather than 10).
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby shirley_hkg » 11 Oct 2017, 02:45

Will's BLDC motor chairs don't seem to have such complex program . .

Is it easier to work with BLDC ?
:clap :dance :fencing :worship :argument
shirley_hkg
 
Posts: 3918
Joined: 31 Dec 2010, 13:42

Re: Some thinking and questions about Roboteq

Postby shirley_hkg » 11 Oct 2017, 02:51

Emoji are COOL ! :dirtbike :bounce :bravo givebeer goodpost
shirley_hkg
 
Posts: 3918
Joined: 31 Dec 2010, 13:42

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 11 Oct 2017, 06:34

There's no problem with sensorless compensation once battery current rises to a usable value (and, compensation is weak if motor power is at or above 200 for the Roboteq's firmware). Will does not get good compensation at low speed, and has the cogging problem on top of that, but his motors are low impedance so current rises quickly. The 200 limit can be pushed lower, that works, but the mobot motors are high impedance so current is very low at the start and with a high power to weight ratio the mobot doesn't get to a usable current till motor power is about 100. We're trying to get it to work between 0 and 100, but this is proving a tough nut to crack.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby shirley_hkg » 11 Oct 2017, 08:43

goodpost
shirley_hkg
 
Posts: 3918
Joined: 31 Dec 2010, 13:42

Re: Some thinking and questions about Roboteq

Postby Burgerman » 11 Oct 2017, 13:33

Shirley is really into these little emojes! :dance
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 11 Oct 2017, 14:15

I'd like us to back up some in hopes of figuring out what to do about that zone of "missing data" before the Roboteq sees the battery current. Hence, I'm posting yet another version of the script and will try to outline a test and tuning sequence that will give me more information to go on.

The script has no changes in the MotorCompensation calculations. What it does have is a (1) different PRINT arrangement that should make it possible to use the Run tab graphs and will make the Console listing more compact should you figure out a way to save the log during testing, and (2) a couple different starting values in user settings.

I have not changed accel/decel nor motor resistance settings, but have set CompTurnBoost = 0 and LowIBoost = 0. For now leave these alone! This eliminates turn-in-place (and low speed) boost and leaves out the attempt to guess at motor current when battery current = 0. What it does leave in place are basic motor compensation and the extension of calculating MotorCurrent = BatteryCurrent/PWM down from PWM = 200 to PWM = 40. Here's what I'd like you to do:

(1) Adjust MotorResistance until you get good, but stable, compensation FOR THROTTLE >= 200. This should keep you in the range where the Roboteq is showing some battery current and it is using the firmware estimate of motor current. You've been doing this for years, so no need to say more about this step.

(2) Check out behavior at lower Throttle values, but only for values that give readable battery current = at least a solid 0.1 Amps, not "flickering" between 0 and 1.

(3) Now start to add some LowIBoost, but go very slowly and cautiously with this. It's like adjusting motor resistance, but the numbers will be small, so each little change is actually a big percentage change. The aim of this is to get usable compensation at lower Throttle settings (with Steering = 0), or at least I hope you can. If this doesn't work, we'll have to stop here and think of some other way to do things. Perhaps going back to using current sensors, but thinking of a way to prevent runaway if there's a sensor failure (I finally do have some ideas for making it safe-fail).

(3) If all's gone well to this point, check out turning behavior. Is it too wild? In that case, we'll have to make the script reduce the effect of LowIBoost when turning. Is it too sluggish (particularly at low speeds)? In that case, start adding, cautiously, CompTurnBoost to see if it improves matters.

Get me as much hard data as you can, graphs and if possible console logs, as well as your verbal observations. I am, however, a numbers guy and I can do more if I have hard data.
Attachments
analog 2017_10_11.mbs.zip
(35.96 KiB) Downloaded 353 times
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 11 Oct 2017, 14:54

Will try to do that. Getting numbers is hard. And figuring out what they are from or what I was doing at the time harder still.

I have questions.

As the script is now, and if motor compensation is set correctly at 200, we will have a gap at any low current / small stick movements etc from stationary.

Adding low boost seems to do the wrong thing. In that it adds arbitrary boost to fill in that gap. But it isnt load sensitive. So I dont see how thats ever going to work. The amount of low boost added before the roboteq reads anything, may need to be a lot, or even negative if turning on a slope for eg. So adding anything unmeasured here is wrong. Am I correct in that this is what is happening?
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 11 Oct 2017, 16:27

Your reasoning is partly correct and partly not.

As the script is now, and if motor compensation is set correctly at 200, we will have a gap at any low current / small stick movements etc from stationary.
Not quite. We will have a gap when BatteryCurrent = 0. PWM 200 is a good bit higher than the point at which battery current registers and I chose that for basic MotorResistance tuning to be sure that it's never in that 0 battery current condition. On your mobot, on its wheels, you start to read BattI = 0.1A at about PWM = 100 when not turning, but it will be at lower PWM when turning because scrubbing load increases current. On Rachi's chair, the lower impedance motors give BatteryCurrent of 0.5 A at PWM = ca. 50 (when not turning), but the chair is barely moving at PWM = 50. Battery current is measurable when barely above PWM = 0 if starting a turn in place (horrid casters and CG). So on your chair there is indeed a gap to be filled; up to PWM = ca. 100 going straight. If you put some weight on the mobot, such as the mower assembly, I'd expect the gap to be smaller. On Rachi's there's a tiny gap going straight and essentially none for t-i-p. It's because that gap is big on the mobot that this attempt to avoid sensors may end up having been a wild goose chase.

Adding low boost seems to do the wrong thing. In that it adds arbitrary boost to fill in that gap. But it isnt load sensitive.
Yes and no. It is not sensitive to variation of external mechanical load, but it is sensitive to intrinsic motor load. The logic was this. For an ideal mobot motor and constant external load, battery current will go from 0 A at PWM = 0 to 0.1A at PWM = 100. Motor current is undefined at PWM=0 (0 divided by 0 = ?) , but after that it will be constant. I've called that constant LowIBoost. That's for an ideal motor and is conservative for a real motor - there will be too little compensation at low PWM. That linear assumption could be modified if necessary, to match the power curve of the real motor, but it will still never be responsive to external physical load below battery current = 0.1 A. If physical load is added, such as carrying more weight, turning, climbing over an obstacle, or going up-slope the transition to battery current = 0.1A will come earlier, and then compensation does become physical load sensitive earlier as well, but there will still be some gap. On Rachi's chair the gap is so small that the value of LowIBoost turns out to be almost irrelevant over a very wide range of numbers.

The amount of low boost added before the roboteq reads anything, may need to be a lot, or even negative if turning on a slope for eg.
Quite correct. Within the 0 battery-current gap there will be no physical load compensation. This is less of a problem on the positive-load side as the zero current gap gets smaller as load increases, but the gap still extends to PWM = 40 or so for the mobot with the motor stalled. It will, however, absolutely give a speed-up when loads go negative. Again, the existence of this gap may make sensorless-operation unworkable for the mobot, but it does work on Rachi's chair and it should work on the BM3 (lower impedance so higher current at low PWM) and even better on Will's chair (yet lower impedance - so much lower with brushless that you need controller-limited current at very low PWM; it will trigger stall detection if it's made too sensitive - the same phenomenon that made the Invacare Explorer unworkable for you).

There was a similar "going negative" problem with CompTurnBoost for turn-in-place on Rachi's chair - after the caster has swiveled, load drops and there was a feeling of overshoot of turn rate. But at turn start it's outside the 0 current gap on her chair so I was able to detect this as a drop in battery current and simply bypass CompTurnBoost as soon as the the turn has gotten underway. So there's very strong boost to swivel those treadlesss, square, overloaded casters, but no overshoot afterwards. Again, however, this depends on having measurable battery current at least when starting the turn, so it's not applicable to negative loads within the 0 current gap. The same kind of bypass logic could, however, be easily added to remove LowIBoost if a negative load makes battery current go from 0.1 A to 0. That is, don't do LowIBoost if the last reading of battery current was > 0. Or perhaps better yet, bypass LowIBoost if any of the previous n battery current readings was > 0 - that would get rid of any sudden swerve or speedup while slowing down or when coming down off an obstacle. But I won't code that for now. I don't want to add any more complexity until I see how things are behaving when the current design is tuned the way I advised. I may decide to invest my mental energy in figuring out how to make current sensor failure safe instead.

To summarize, sensorless control may not be usable with lightly-loaded, high impedance motors, but only systematic testing is going to let us really know that.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Vitolds » 14 Oct 2017, 13:19

LROBBINS wrote:I wonder whether plugging a USB-WiFi dongle into the Roboteq would allow you to use Roborun remotely.

can be used CAN + arduino + nRF24l01
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 14 Oct 2017, 14:25

Yes, that would work, but might have to use two of these rather than one on the Roboteq then to WiFi router. I don't have enough pins leftover on the Arduino in my PowerDistribution module so would have to add another Arduino + probably a 5V to 3.3V supply.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 14 Oct 2017, 15:09

Will finally get chance to do this hopefully after 8pm. Off bed again then.

I'd like us to back up some in hopes of figuring out what to do about that zone of "missing data" before the Roboteq sees the battery current. Hence, I'm posting yet another version of the script and will try to outline a test and tuning sequence that will give me more information to go on.

The script has no changes in the MotorCompensation calculations. What it does have is a (1) different PRINT arrangement that should make it possible to use the Run tab graphs and will make the Console listing more compact should you figure out a way to save the log during testing, and (2) a couple different starting values in user settings.

I have not changed accel/decel nor motor resistance settings, but have set CompTurnBoost = 0 and LowIBoost = 0. For now leave these alone! This eliminates turn-in-place (and low speed) boost and leaves out the attempt to guess at motor current when battery current = 0. What it does leave in place are basic motor compensation and the extension of calculating MotorCurrent = BatteryCurrent/PWM down from PWM = 200 to PWM = 40. Here's what I'd like you to do:

(1) Adjust MotorResistance until you get good, but stable, compensation FOR THROTTLE >= 200. This should keep you in the range where the Roboteq is showing some battery current and it is using the firmware estimate of motor current. You've been doing this for years, so no need to say more about this step.

(2) Check out behavior at lower Throttle values, but only for values that give readable battery current = at least a solid 0.1 Amps, not "flickering" between 0 and 1.

(3) Now start to add some LowIBoost, but go very slowly and cautiously with this. It's like adjusting motor resistance, but the numbers will be small, so each little change is actually a big percentage change. The aim of this is to get usable compensation at lower Throttle settings (with Steering = 0), or at least I hope you can. If this doesn't work, we'll have to stop here and think of some other way to do things. Perhaps going back to using current sensors, but thinking of a way to prevent runaway if there's a sensor failure (I finally do have some ideas for making it safe-fail).

(3) If all's gone well to this point, check out turning behavior. Is it too wild? In that case, we'll have to make the script reduce the effect of LowIBoost when turning. Is it too sluggish (particularly at low speeds)? In that case, start adding, cautiously, CompTurnBoost to see if it improves matters.

Get me as much hard data as you can, graphs and if possible console logs, as well as your verbal observations. I am, however, a numbers guy and I can do more if I have hard data.
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby Vitolds » 14 Oct 2017, 15:10

I did :
Roboteq + arduino + nRF24l01 = Slave
joystick + arduino + nRF24l01 + Oled = Master
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: Some thinking and questions about Roboteq

Postby Burgerman » 14 Oct 2017, 15:16

(3) Now start to add some LowIBoost, but go very slowly and cautiously with this. It's like adjusting motor resistance, but the numbers will be small, so each little change is actually a big percentage change. The aim of this is to get usable compensation at lower Throttle settings (with Steering = 0), or at least I hope you can


Will this be added compensation, as in load sensitive? Or added boost regardless?
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 14 Oct 2017, 16:09

This is the only boost when battery current reads 0. It is sensitive to the intrinsic voltage vs. current of the motor, but not to external loading. On the mowbot this condition lasts to a higher PWM (ca. 100) than on Rachi's chair (ca. 50), and the mobot is also moving at a decent clip at that point, while the chair is barely crawling. Hence, it may be unsatisfactory for the mobot, but that's what I want to find out. If it is unsatisfactory, sensors will have to be used as far as I can tell, but I will probably send you one more script to try before deciding.

In case sensors are an absolute necessity, I've started rethinking whether current sensors can be made safe-fail. I thought not, but now realize that I can do it. During startup, motor power is 0 so current should be 0 - anything more than that means that the sensor is out of whack (or say more than 0.2% of full scale Amps to avoid false errors and 0-point drift). If it's not OK at startup, I can tell the main loop to not do any motor compensation - it will be (badly) drivable, but good enough to get home and also obvious. Of course, in the CAN system I'd also have it send a CurrentSensorFail message to Display.

Once in the loop, I can test two situations: when Throttle=Steering=0 or when commanding movement. When Throttle=Steering=0, current will either be 0 if the chair has already come to a stop, or falling over time if it's slowing to a stop. Anything else is a sensor fault. When commanding a move, I can back-calculate SensorBatteryCurrent= MotorCurrent*PWM and compare that with measured battery current. A difference between the two that is more than the BatteryCurrent step size signals a fault. I can check both of these, but now instead of killing motor compensation I would switch for that cycle (and subsequent cycles if the fault persists) to using estimated motor current. With that, driving is decent, even for the mobot, but then at the next startup we'll get the more obvious no-compensation behavior.

I've made a CANbus version script of this and tested it, though because I don't any longer have current sensors in the PowerDistribution module I could only test it by using the end-of range value of the non-existent sensor or putting in 0 values to bypass the startup check, or to bypass both the startup and not-moving checks, leaving only the while move-commanded check. Seems to work OK. If it turns out sensors are needed, I will install a pair on my test setup so that I can properly test it to make sure that real faults are reliably detected, and false faults are rare or non-existent.

I eagerly await your test results. I'm going to be tied up with other things this evening and all day tomorrow, however, so probably won't get to look at them till Monday.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 15 Oct 2017, 16:35

Set speed to 206 by RC trims.
Compaesation set to 300 )as with sensors) gives very little compensation, power increases to around 300 if I grab wheels.
Compensation increased to 450 seems about right. Maybe a freaction low.

Then holding wheels on right channel only sees power rise from 200 to 490.
And 150 to goes to 419 (I then noticed that the OPPOSITE chanel. when free running ALSO increases to 170, thats weird).
And 130 goes to (307 no increase on opposite channel which is correct)
And 100 goes to 100...

Test 117= gives 277 stalled
test 106= 106 no change.
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby Burgerman » 15 Oct 2017, 16:41

Lowboost.

Wheels off gound, set to to fixed 100 input via TX trim..

Adding lowboost does nothing at first as you increase it. At around 15 it helps VERY slightly with a tiny bit of compensation. But raises the 100 speed to 145. At lowboost 20 it increases input 100, up to continuous 170. Still shows no sign of usable compensation. So effectively makes it worse. It doesent fill in the missing compensation, it just adds input power as soon as you touch the stick. Or it removes the 0 to 100 completely. You start at 100 or so. This isnt going to work.
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 16 Oct 2017, 19:01

This isnt going to work.
I think you're right, so I'll be mounting sensors on my test setup again to thoroughly test my scheme for reacting to sensor failure.

On Rachi's chair LowIBoost just serves to boost starting current to get the motors moving (starting current is nominally 85 A and no-load is only 3.5), but it's hardly moving at all when battery current becomes readable at Power = 40 or so. On the mobot, starting current is much lower and with the higher impedance battery current isn't readable until power = 100. By 100, however, it's already moving at a good clip. I suspect that it will be OK on the BM3 or Will's chair (where current sensors aren't possible anyway) because both have lower impedance motors and more weight/hp than the mobot, but only time and testing will tell and by then the choice of using or not using sensors will be back.

I also agree with:
And 150 to goes to 419 (I then noticed that the OPPOSITE chanel. when free running ALSO increases to 170, thats weird).
For me too this is totally weird. The two channels are completely separate in the script and as far as I know completely separate in the Roboteq firmware and hardware. Can I assume that you repeated this observation more than once so it wasn't a fluke?

Even though I think you're right that sensors will be needed, I'd like you to try yet another script while I'm working on the safe-fail idea. It has only a minor change in MotorCompensation: that I don't expect to achieve much, and it has a fix for a mistake in the damping routine - you may have noticed that the damping parameter didn't do anything at all! Won't at all affect anything when you're sending a fixed value by RC, but a little damping might be comfortable even for you when using a joystick. In any case, I want to be sure that I didn't screw anything else up when I made these changes, and damping was already correctly coded in the CANbus Master's program, so I need you to test this for crazy mistakes. Do the testing the same way as for the last one. Start with LowIBoost = 0, TurnCompBoost = 0 and Throttle = 200 to adjust motor resistance. Then see what happens when you add a small amount of LowIBoost.

Have you looked at the logic of how I intend to detect sensor failures and what I intend to have the chair do if failure is detected at startup vs. what I intend to have it do if the failure happens after already in the main loop? I want the failure to be obvious, especially at startup, but want it to still be drivable - don't want you to be stuck unable to get back from the pub.

You may wonder why I think that even on the mobot safe-fail is needed, after all your bod isn't going to be thrown about if it runs away. But once you have that mower blade spinning, a runaway might cause a lot of damage. (I notice that you don't have an interrupter on it, or at least there's nothing in the profile to say that the built-in Mosfet failure detection triggers a stop. Are you sure you want to have it running about like that? On the BM3, do you have a digout triggering the relay-open coil if there's a Mosfet failure?)
Attachments
analog 2017_10_11a.mbs.zip
(37.08 KiB) Downloaded 350 times
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 16 Oct 2017, 19:44

I also agree with:

And 150 to goes to 419 (I then noticed that the OPPOSITE chanel. when free running ALSO increases to 170, thats weird).

For me too this is totally weird. The two channels are completely separate in the script and as far as I know completely separate in the Roboteq firmware and hardware. Can I assume that you repeated this observation more than once so it wasn't a fluke?


Yes wasnt a fluke.
I also noticed that on the BM3 that when useing the roboteq current sensors (with wheels locked up solid so they cant turn) that it reads 3x to 4x higher current on one motor than the other. Consistently. But its not real.

And as you say, an input/output of 100 on the bot is 10% speed. Or .6mph. Before it gets any compensation. So faster than I drive it on the bed unless I have to add a bunch of power manually to get it to turn in place...

Not worried about the bot running away...
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 16 Oct 2017, 20:02

100 on Rachi's chair is probably also close to 10% of 5.5 mph, but 50 is very slow. Min pot full stick is only 270 and is a slow walking pace for indoors. If I were sitting in the chair, I'd have full stick a fair bit higher than that.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 16 Oct 2017, 20:09

On the BM3, do you have a digout triggering the relay-open coil if there's a Mosfet failure?)


Yes. Also triggered by red button...
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 16 Oct 2017, 20:59

I was sure you had a stop button, but glad to know it's also triggered by a digout.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 20 Oct 2017, 21:49

A REMINDER

I would still like you to test "analog 2017_10_11a". I don't expect it to help with sensorless compensation, but I would like to now if the changes I've made cause any unexpected behavior or anything else you haven't encountered before.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 20 Oct 2017, 21:54

I will as soon as I can. Currently eating antibiotics with blader infection! :fencing :cussing

Palitrex 1000mg every 12 hours... On my bed shivering.
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 21 Oct 2017, 08:54

Cripes, hope your better soon.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby MikeGrok » 21 Oct 2017, 23:43

I am not as familiar with your issue, but I thought that the problem could be caused by effectively not though resolution in the hall sensors.

If you used encoders to force a higher resolution of motor / wheel turns, then that may help.

-Michael
MikeGrok
 
Posts: 10
Joined: 18 Sep 2017, 17:11

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 22 Oct 2017, 02:56

These are brushed motors and do not have Hall sensors or an encoder. IR motor compensation uses motor resistance (assumed to be constant though it's not really) and current to estimate back emf and then adds that to the command value to hold speed nearly constant as load changes. Actually, a bit less than the back emf is added as it's positive feedback and adding a little too much leads to instability. Even in situations where closed-loop control is possible, many people prefer the "road feel" of motor compensation to the too-precise feel of a tight closed-loop, but I suspect that with "loose" tuning that varies the pid parameters in different situations would be a good alternative for brushless (or other sensor equipped) motors. I'd try to develop that if I had some brushless motors and a brushless controller, but I have neither.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 22 Oct 2017, 20:06

I now have the CANbus version of the script nearly done with current sensors re-installed. The only thing not yet done is to code a SensorFault message and graphic for Display. This differs from the analog version only in that user settings are done via the Programmer module rather than having to connect to the Roboteq. If set to UseCurrentSensors = true, both have the automatic detection of sensor fault at startup that turns off all motor compensation if there's been a failure, and detection of sensor fault during running that just switches to sensorless MotorCompensation until stick centered, when it tries again in case there's just been a momentary glitch. The safe-fail detection has also been simplified from the idea I outlined a few posts back.

I have re mounted the sensors inside the power distribution module on my bench setup and tested the fault detection every which way from Sunday on that. I then installed the software on Rachi's chair which doesn't have sensors at all (I've ordered a fresh pair of Allegro breakout boards for it). First check was to leave UseCurrentSensors = TRUE to make sure that this will be detected as a fault during startup. Indeed it does, and without any compensation the chair is just barely driveable - virtually no turn-in-place ability. I then set it to UseCurrentSensors = FALSE to check that it uses the sensorless algorithm. It does, and it drives exactly the same as it did with the sensorless-only version of the script.

As soon as you are up and about again, test that last file I posted, and tell me that it doesn't behave any worse that the version that preceded it, I will post a new release version of everything on google drive.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 22 Oct 2017, 20:27

Will do. Just finished antibiotic, and feel crap... The sort of UTIs paraplegics get are complex. Right now I had an hour of coughing fluid up suddenly, blocked nose, came on fast. Turned off heat, opened a window, and its gone but I am cold! :argument And now its all ok again... May get up tomorrow see what happens. That supplemental oxygen generator is a godsend when you are struggling to breath and coughing up fluid. You can relax!

BM3 finally back in my room so will have it strung up on that hoist soon to see what broke!
User avatar
Burgerman
Site Admin
 
Posts: 65051
Joined: 27 May 2008, 21:24
Location: United Kingdom

PreviousNext

Return to Everything Powerchair

Who is online

Users browsing this forum: loky, shirley_hkg, tettralytic, woodygb and 93 guests

 

  eXTReMe Tracker