PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

Good then.

Rain here too. And salt. And wind! And its still cold. I was lulled into a false sense of security by 2 warmer brighter days at the weekend! I hate cold.

[wilsonintexas]

In Dallas we have had 3 ice storm and 2 inches of snow over the past few weeks. Last night, the weather guy said that it was all over, that the jet stream was moving back in and the cold weather was retreating north. We are supposed to be on the high 60s100's(15c) to 70s(21c) this week. Then probably 100 (37c) by July..... I hate cold, but I also do not relish 100s.

I miss the moderate British weather. I was there for 12 years, and would take it again in a heart beat....

[Burgerman]

I will swap you...

[Burgerman]

I still get a bit of issue zero turning in grass or mud,

I suspect its to do with either motor compensation without sensors working or working correctly, or the fact that brushless motors have some issues with starting torque. Although yours are geared so maybe not that.

can say mines super strong turning even at really low pulse width. Set to geological turn rates. 3mm of stick, and it turns regardless of slope or surface very predictably. But sometimes you just feel it shudder a fraction doing this. Like resolution is a little borderline. I thing going to even higher volts would be a mistake. But having enough speed to overtake cars makes this an easy compromise!

[LROBBINS]

Just realized why I may be having more problems with turn-in-place than you, though I can't test this till this evening when Rachi's out of her chair. Top speed on your chairs is ca. 15 mph. Top speed on Rachi's is about 5.5 mph (let's say 5 so it's 1/3 of yours). Acceleration settings in Roboteq essentially define "time to top speed", whether that be by n change of PWM per second (brushed motors) or m change of RPM per second (brushless). So, if I have the same acceleration parameter values as you, in absolute terms the change in mph per second (or g ) on Rachi's chair is only 1/3 of what it is on yours. I think I need substantially higher base settings.
Ciao,
Lenny

[Burgerman]

Because I have to use 1/3rd the acc rate, it takes longer to go from 0 to 0.1 than yours will. This is the real source of my delay I think.


So yes you need much higher acc rates. Mine are set super low anyway. For testing.

[LROBBINS]

OK, tested. Yes, increasing Accel and Decel settings seems to have about the same effect as using AccelComp and DecelComp, at least at the low speeds I can use in our living room.

I've also made a couple additions in the CAN version of the Roboteq script; one for safety, the other for responsiveness.

Because script commands satisfy the Roboteq serial watchdog and the script is constantly sending commands, that watchdog can never be triggered. Thus, if my joystick should stop sending messages, the chair would just continue on and on at whatever last values it had received. I've now added a CANwathcdog timer (using one of the four timers available in MicroBasic) and if a joystick message is not received for 100 msec throttle and steering are forced to 0. At the full speed of this chair, 5.5 mph, that means the chair will runaway on CAN failure for all of 2 cm before coming to a stop. This would not apply to analog joystick input, but should be done for RC if you use the RC inputs of the Roboteq (rather than Woody's RC adapter).

Motor control has priority over the script interpreter, so the more motor commands are sent the more sluggish will be the script. The script, both mine and yours, does

Code: Select all

SetMotors:
   SetCommand (_G, 1, C1) 'THROTTLE
   SetCommand (_G, 2, C2) 'STEERING
RETURN 'End of "SetMotors:"


at every cycle of the main loop. However, once the motors have reached the commanded power output, there's no need to keep doing SetCommand (_G,...). So, my script now has:

Code: Select all

SetMotors:
  M1Power = GetValue (_MOTPWR, 1)
  M2Power = GetValue (_MOTPWR, 2)
  IF (M1Power <> M1Calc) OR (M2Power <> M2Calc) THEN
    SetCommand (_G, 1, Throttle)
    SetCommand (_G, 2, Steering)
  END IF
RETURN 'SetMotors:

where M1Calc and M2Calc are the target values found in MixAccel. As long as the motors haven't reached those targets, the command gets sent, but once there they are not sent. This is especially important in the CAN system because I want the script to see arriving messages ASAP, but it wouldn't hurt to have this in your scripts too. I'll try to remember to do this whenever I post a revision.

Ciao,
Lenny

[Burgerman]

Is your motor compensation and other settings all still working well?

I am considering a second Roboteq for another chair. Seems pretty good now. Mine working well, and a bit overpowered but the speed knob can be used to make it sane. And Wills pretty good.

[LROBBINS]

MotorCompensation is working, but I'm still not satisfied with the turn-in-place; it's less positive and jerkier than the DX, so still needs some tuning.

Ciao,
Lenny

[Burgerman]

I am surprised. Mine is having an easier time (large casters low weight over them) but this is very smooth and predictable. I suspect a little more compensation? Or is it the speed it is applied?

I am very suspicious that motor compensation on a mobility controller is allowed to override the usual acceleration limit. So that it can react fast enough to still be affective when we want our preset acceleration (of the chair rather than the pulsewidth) to do its thing.

But I am wary of 14kw flipping me inverted when it has a fit! It can do the full 14kw at about 8mph on mine...

[LROBBINS]

A tired but happy camper here. Finally got the chair outside today to be able to drive it a bit at faster speeds. The turn-in-place was cured by raising milliOhms a bit, and the seeming jerkiness turned out to be having too high a turn rate - min turn was 20, now 14 and min turn in reverse is set at 10. Reverse min turn doesn't enter into turn-in-place because I've set reverse turn to take effect only with throttle below -150 (out of 1000).

As I mentioned in some earlier post, I've changed my throttle and turn parameters to be separate items rather than modifying one set with different weightings for different conditions. (Except for turn reduction at full speed which I want to have available because this is a FWD). The parameters in my CAN program are now:

SpeedPotFwdMax = 100
SpeedPotFwdMin = 20
SpeedPotRevMax = 70
SpeedPotRevMin = 15
TurnPotFwdMax = 40
TurnPotFwdMin = 14
TurnPotRevMax = 30
TurnPotRevMin = 10
TurnAtFullSpeed = 50; // 100=no reduction of turn rate with speed, 0=turn rate goes to 0 at full speed

If you guys would like, I can rework the analog script to be like this. (Would have to work out how to do the equivalent of Arduino's handy map () function, but that's just a bit of algebra.)

I have deliberately caused contactor, brake, joystick and speed pot failure, and CANbus interruption - all safeties working as designed. I haven't checked what happens if the current sensors fail, but should do that - but I'll have to cut some traces for that. Also haven't yet dug into the seat elevator box (where the DX CLAM module and tilt, lift and lights wiring are) to hook up the seat actuator and lights control - that's going to be another all nighter. CANbus is running at 500 kbps, way faster than needed, but I want to "stress" things. Another thing I've yet to do is re-burn the Atmega processors to set brownout protection to 4.3 volts instead of 2.7. I do have to do this because power failure, such as pulling the emergency-stop plug, does sometimes cause EEPROM corruption - giving weird values for accumulated total time. Supply voltage take some time to drop if disconnected without the MCU being properly turned off. This causes mis-writes if the EEPROM is updating the time data when this happens. Raising the brownout will cause the MCU to go into reset state before that can happen. I also want to clean up some of the fault messages for the display and log file. So, there's work yet to do.

I have also laid out a board to use STM integrated motor controllers rather than relays for tilt and lift, and bought a couple of those chips, but it will probably be months before I have more boards made, so will continue using the relays for now. If anyone is looking for inexpensive H-bridges for up to 30A & 36V these look like a good bet, and they're much cheaper than what you'll find at places like Pololu. In fact, they work out as cheap, or cheaper, than using relays. The part number is: VNH3SP30-E, RS number 809-1335. I'll be using a diode for reverse polarity protection, and I have a bunch of 12A diodes on hand for other purposes, so the chair will be limited to 12 Amp actuators for lift and tilt (the ones on the chair now are 5 and 7 Amp max).

Tomorrow I'll finish mounting the Roboteq and power distribution module to a piece of plywood so I can easily swap it for the DX-PM inside the chair. Well, sort of easy except for what lifting the batteries in and out is likely to do to my back.

Ciao,
Lenny

[Burgerman]

Sounds good.

Changing those things would make it easier to configure. No urgency/hurry here though as its still bloody freezing and wet...

[Burgerman]

Just a thought.

Not 100 percent sure what the turn rate settings are doing.

Reverse turn rate scaling? Forward turn rate scaling? Presumed it was the rate of rotation seen from above with the stick behind or in front of the 0 throttle point.

So if forward turn rate is set higher than reverse turn rate then there will be a "step" in turn rate (rotation) as you cross the 0 throttle point. Since the rate of rotation should not be related to the throttle position I always set these the same (symmetrically) anyway. The thing is then separated and clean.

Then it occurred to me that it may do this instead:
It controls the left or right wheel speed rotation in reverse or forward motion as you turn on the spot. So that if its set to be a greater figure "forwards" than "reverse" the chair will not turn on the spot but move forwards at the same time.

So which does it do?

[LROBBINS]

It's the first of your descriptions, and indeed if Steering switches from "forward" to "reverse" at exactly 0 Throttle there will be a step change in turn rate at that point. That is the way it is in your script, and it would be at least annoying if you didn't set the two weightings the same - with throttle just above 0 you might be able to turn in place, and with it just behind 0 you might not.

That's why I now have mine set so that Throttle goes from "forward" to "reverse" scaling at 0 Throttle, but Steering goes from "forward" to "reverse" scaling only if Throttle < -150 (out of 1000). When I get the changes in parameters done, the new version of your script will also have this change.

And some others. The other day, when I'd just switched back to the DX, I didn't get one of the motors properly plugged in. The DX system detected this, inhibited drive and posted a Right Motor Fail message. Good thing too, because otherwise pushing the stick forward would have given a medium hard right turn instead of straight ahead. In the Roboteq scripts I had added a test to detect motor open conditions, but had never done anything with the result, so I've now made it so that with either motor open Throttle and Steering are set to 0 and kept in that state until the controller is turned off and then back on (wouldn't want the chair to start moving while someone is underneath checking the wiring). This too will be incorporated in your next script. I don't yet have the Roboteq sending a CAN message to Display to show and log Left Motor Open or Right Motor Open messages, but will add that too (though not in the non-CAN script as you don't have a display or SD card).

Also, instead of using a timer to block motor compensation after brakes are set, I've changed it to directly read the state of the brake digout flags. This too will be in your next script.

There is also something I had to add to the CAN script that isn't needed in yours. In mine, I turn the (non-latching) contactor on and off in the script, so had to add my own Runaway protection to be able to control that pin at will (if configured to Open on MOSFETfail, you can't open and close it from the script). In my routine, as in Roboteq's, MOSFETfail fault flag or runaway (current flow for 500 msec when no joystick input) opens the contactor by resetting that pin rather than by configuration profile. But when I tested it, I had a surprise -- if a non-zero JOYSTICK CAN message arrives after the contactor was opened by MOSFETfail, it closed the contactor, so the contactor ends up chattering on and off every 50 msec. I've now used the same code as for motor open to keep Throttle and Steering at 0 -- once open because of runaway the contactor now stays open until the controller is turned off and then on again (assuming that whatever caused the runaway has been fixed, or it will also stay off when the controller is again started).

I'm still in the midst of testing these changes in my system; today on the bench, tomorrow on the chair. I've also re-written ypur non-CAN script as described, but will not post it until I test it with the analog joystick hooked up.

Ciao,
Lenny

[cdb0ewm]

A quick question about the Roboteq. On page 22 of the manual there is a diagram, Figure 2, showing a the on/off power switch, labeled SW1/Main. Does anyone know what the voltage of the Pwr/Cntl.
Thanks

[Burgerman]

Its kind of floating.

I have a 1k resistor pulling it to ground - to make it firmly off. And a 12v supply pulling it up for on. A latched button on the pod. And the status lamp for on and error flashes etc. From memory.

[LROBBINS]

HD24xx spec sheet, Table 7, 0 to 65 Volts., minimum operating voltage (i.e. this voltage at either the control wire or power stage turns it ON - there's a diode in most models, but not all, that feeds voltage from the power stage input to the control lead) = 9V.

[Burgerman]

I may have mine the other way around? Ground for off, pull up resistor. But either way should work.

[cdb0ewm]

I'm trying to figure our the best way to open and close SW1. I believe using a relay with a 12v trigger is how I want to go. I am not sure how many amps the relay must be able hold.
Any input would be appreciated

[Burgerman]

SW1 ?

[cdb0ewm]

On page 22 of the manual there is a diagram, Figure 2, showing a the on/off power switch, labeled SW1/Main

[Burgerman]

I'm trying to figure our the best way to open and close SW1. I believe using a relay with a 12v trigger is how I want to go. I am not sure how many amps the relay must be able hold.
Any input would be appreciated

It needs no Amps. Or a relay. Its only looking for a signal "state".

You need a latched button on the "pod" and 1x high value resistor to pull it high or low.


You can use any switch to hold it off or on. And a high value resistor to pull it up / down to hold it on or off depending which way you have a switch.
Basically you need 1 switch and 1 resistor.
0V turns it off. By switch or resistor...
12V or anything over 7V turns it on, by resistor or switch.

The resistor holds it to your + POS, OR to - NEG and the switch overides this. Doesent matter which way around you do it.

What will this relay do?

[cdb0ewm]

My idea is to run only 24 gauge wires to the joystick and the on/off switch. The wires for the Robotek SW1/Main are much larger. Extending them to with 24 gauge wire will most likely result them in getting roasted when the SW1 is closed. The relay will be used to close the SW1/Main circuit and I can drive the relay with a 12v relay triggered using 24 gauge wires.

What am I missing here

[Burgerman]

The wires are carrying only a signal voltage. There's no significant current. No need of a relay, thick wires, or anything.

[cdb0ewm]

Is there a wiring diagram addressing this

This can't be as complicated as I'm making it

[Burgerman]

Its not.

It "senses" a voltage. It basically floats. If it sees a high voltage its on. If it sees a low voltage its off.

So you "pull it" up to 12, 24, or whatever voltage to make it on. (with a switch)
You pull it down to ZERO VOLTS so its OFF with say a 2k resistor to ground, to hold it OFF so it doesn't power up when switch is off.

OR the reverse.

You pull it UP to a 12 or 24V or whatever with a resistor, so its ON, and the switch makes it or connects it to GROUND or ZERO VOLTS. So its off...

It cant be any simpler.

The only time any current flows of any note is across the resistor. And its so high value (Ohms) that its pretty much irrelevant.
Do you understand Ohms, or Ohms law?
See: http://www.cybersoftware.co.uk/gcse_ele ... _law.shtml
http://simple.wikipedia.org/wiki/Ohm's_law
http://www.ducksters.com/science/physics/ohms_law.php

[Williamclark77]

To help imagine how it works, with your main power wires connected, touching the on/off switch wires together turns it off. Pulling them apart turns it on. Backwards from what you would think "on/off" wires would do.

If my memory serves me correct that is.

[Burgerman]

Correct but its not firmly on until pulled up to a secure voltage. It "floats"... Hence the resistor.

[cdb0ewm]

SW1.PNG (54.63 KiB) Viewed 6638 times

Thanks for the input and guidance. Does this look right?

[Burgerman]

No. If you use a switch with 3 connections you don't need a resistor at all but it means more wires to the pod.

At the roboteq, I connected a resistor between the black 0V and the on/off sensor wire. So its normally held to zero volts and so firmly OFF.
Then at the pod, I added a switch to send +12V to the sensor wire. This overrides the resistor. You need a 12v supply in the pod anyway to work the emergency contactor off switch. So you only need 1 on/off wire. A simple latched switch.