Feeding a Roboteq from a Powerchair controller

[Yennek]

Was talking with a friend, and we got on the topic of cranking up the speed on his powerchair and the easiest way to do it. It got me thinking, would it be possible to feed a Roboteq input from the output of some other powerchair controller? Like take the PWM output of the controller that's already on the chair, put it through a some sort of LC lowpass filter, and then a voltage divider into the Roboteq analog inputs.

I know most controllers give some sort of error if they don't detect a motor connected - what does it look for? Could I just toss a 100ohm resistor across the outputs and make it happy? And for that matter, even if it does report a fault, does it still try to operate?

Or would having 2 controllers just introduce too much delay. What is the delay through a Roboteq anyway? Reading the programming manual, it sounds like it does something once every 1ms, so is that how often the logic stage updates the motor output stage? So, delay would be probably in the 1 to 2ms range? Would that even be noticeable?

Oh, and for reference, the controller we'd likely be dealing with is an Invacare MK6i.

Thanks in advance, and sorry if this has been covered in some other thread. I tried searching but all I found was this one: viewtopic.php?f=2&t=145&p=893#p893

[Burgerman]

Trust me its way way from that simple.

Its easier it the end to just use the robotec and a script, and a DIY joystick. And even thats is not remotely simple.

[Yennek]

Trust me its way way from that simple.

A few hints on what kind of issues one would run into doing that approach? I figured it wouldn't be too simple, or someone else would have already done it.

Its easier it the end to just use the robotec and a script, and a DIY joystick. And even thats is not remotely simple.

Yeah, it is the complexity of not just doing a DIY joystick and interface, but also adding a sip/puff control system, and controlling the tilt and other seating things that would make it more complicated for this use case as well. Just brainstorming at this point to see if what's the easiest path with our resources, skills, etc.

[Burgerman]

Try and speed read the roboteq thread!

[LROBBINS]

With sip and puff and actuators as well, I suggest you consider the full CANbus + Roboteq system I'm using on my daughter's chair (soon ?? to be chairs). Still a big DIY job, but the analog version of the Roboteq script can't do these things, and, as John suggests, trying to control a Roboteq from a conventional wheelchair controller will probably open quite a can of worms.

[Burgerman]

One thing in your can of worms it this. Motor load compensation. The only reason that a powerchair controller works at all. It is involved in every single movement of a chair. Including slowing, accelerating and turning. And you have removed all the current sensors motor feedback just by connecting it to the roboteqs input. And without a complex script, the roboteq has non.

I can also think of more issues. But the one above almost writes off the idea in one. Your chair wouldnt zero turn. You would have so little torque at low speeds that you couldnt do a threshold without loosing control. Its a non starter.

[ex-Gooserider]

A major part of the 'worm can' is that none of the standard issue power chair joystick pods put out a signal that the Roboteq can deal with... It might be possible to 'gut' the pod and use the joystick as an input, but this is non trivial, and mostly is going to either need some fairly complex wiring the way BM set up some of his chairs, or an equivalent to the system that Lenny was talking about previously... Neither is easy....

A second factor is that you really won't get any significant speed boost from the Roboteq UNLESS you also increase the voltage of your battery pack.... The stock controller already gives about as much speed as your motors can deliver on 24VDC, as motor speed is a function of voltage, and the stock controller can give whatever voltage the batteries can supply (and a stock system won't work on more than about 30VDC)

As mentioned, take a look at the (VERY LONG and detailed) roboteq thread.

ex-Gooserider

[Yennek]

With sip and puff and actuators as well, I suggest you consider the full CANbus + Roboteq system I'm using on my daughter's chair (soon ?? to be chairs). Still a big DIY job, but the analog version of the Roboteq script can't do these things, and, as John suggests, trying to control a Roboteq from a conventional wheelchair controller will probably open quite a can of worms.

Yeah, I was looking at your design. Intriguing. Initially I wrote it off as too much work, but possibly not.

One thing in your can of worms it this. Motor load compensation. The only reason that a powerchair controller works at all. It is involved in every single movement of a chair. Including slowing, accelerating and turning. And you have removed all the current sensors motor feedback just by connecting it to the roboteqs input. And without a complex script, the roboteq has non.

Right, I was expecting to have to implement some sort of motor compensation in the Roboteq. I had looked one of the scripts that was posted (not sure if it was the latest) and it was commented well enough that I could get the gist what it was trying to do. I hadn't read through the MicroBASIC programming guide at that point though, so some of the details of the actual implementation went past me.

A major part of the 'worm can' is that none of the standard issue power chair joystick pods put out a signal that the Roboteq can deal with...

Yeah, not directly anyway, but a PWM output can be filtered down to an analog output. I was messing around with some circuit analysis tool, and assuming the PWM frequency of the powerchair controller is 10kHz, I could get an output to stabilize with a ~1% ripple within just a couple of ms, using a 3rd order Chebychev filter and reasonably size components. I was going to try to figure out how it did with a PWM that varied, but at the moment I'm having trouble getting the voltage generator element to read my input file.

A second factor is that you really won't get any significant speed boost from the Roboteq UNLESS you also increase the voltage of your battery pack....

Yeah, that was the basic point of using the Roboteq.

As mentioned, take a look at the (VERY LONG and detailed) roboteq thread.

I've read a lot of portions of it so far as it has came up in searches, but I'll probably start re-reading it from the beginning.

[ex-Gooserider]

I'm not sure you are following me, or possibly the other way around... Joystick pods don't put out PWM (unless it's one of the clunky 'all-in-one' pods) they put out a bunch of different sorts of data streams, the exact details depending on the controller brand / family, but NONE are straight PWM. The only place you will see PWM is at the output of the MOTOR control module, and the motor modules are using high power MOSFETS to supply amps to the motors. The Roboteq would be looking for 'signal level' PWM as an input. I'm not sure what would happen if you put motor drive PWM into the Roboteq, but I suspect that it would not be pretty....

Essentially the joystick can in the joystick pod (usually) puts out an analog swing voltage that goes to a microprocessor on the board in the pod, which combines it with things like mode settings, speed pots, etc. (including stuff like switch status, operating status, and lots more) and translates it into a data stream that could be CANbus or any number of other possibilities, all of which are proprietary and mostly not 'reverse engineered'. The motor module takes that data stream and sorts it out, then turns the motion parts of it into PWM that goes to the motors.

What we essentially do in the chairs done so far is to gut the joystick pod, leaving only the can, and either send the analog signal from the can to the Roboteq, or use a different electronic system (i.e. the "Lenny System") to send a digital signal to the Roboteq... We don't use the stock parts for anything other than the can and possibly the pretty housing as a mount for new guts.....

ex-Gooserider

[Yennek]

I'm not sure you are following me, or possibly the other way around...

I think it was more other way around. I was asking about was connecting up to the output of the motor control module. Converting that output to something that a Roboteq can handle is just a handful of passive components. I got that covered, I've designed things like that at work. The question I had was more about what would the motor controller module think if it only saw a few hundred milliamps of current (or less?), no matter what voltage it tried to apply. I'm expecting that it indicates a fault of some sort, but I'm unclear if it would also inhibit the output all together. Also, I'm curious if it internally does motor compensation similar to how the scripts being shared around here do. If it does, then I like that, because it basically turns the compensation to zero because it will measure near zero motor current. (And thus being able to implement compensation inside the Roboteq only, as opposed to having 2 motor compensation systems potentially battling each other.)

I'm only about 1/3 of the way through a complete re-reading the Roboteq thread. So far it has been informative to the development process and knowing what pitfalls to avoid. I also read Lenny's design documentation and Roboteq code for his CAN bus system. I'm very impressed by the amount of work he put into that.

[Burgerman]

Also, I'm curious if it internally does motor compensation similar to how the scripts being shared around here do. If it does, then I like that, because it basically turns the compensation to zero because it will measure near zero motor current. (And thus being able to implement compensation inside the Roboteq only, as opposed to having 2 motor compensation systems potentially battling each other.)

It will need to see SOME load. For e.g. I tried using a couple of small motors for bench testing a r-net power module. These were small DC motors as used on a car heater. It didnt see a low enough impedance and insisted that the motor was having a bad connection error code.

As for motor compensation, you can set that to zero in programming. But you wont need to do that because it wont see a current increase due to load and so wont actually do anything.

Incidentally if you want to see how a chair responds with no motor load compensation, just set your r-net to 0 mohms. It then is inactive. And the chair is unusable almost.

[Yennek]

It will need to see SOME load. For e.g. I tried using a couple of small motors for bench testing a r-net power module. These were small DC motors as used on a car heater. It didnt see a low enough impedance and insisted that the motor was having a bad connection error code.

Good to know for r-net. Interestingly enough, I was reading the DX and DX2 programming manuals, and they have an option to disable the motor continuity check. Which sounds perfect, except this chair has a MK6i controller. And please correct me if I am wrong on this, but from what I have been reading, even though Invacare owns Dynamic, there is no way to use the dynamic programmer/software on a MK6i controller.

Just looking at the MK6i programmer manual, it doesn't look like it has that option. Unless there is some hidden settings somewhere. I haven't tried loading the IVS to see if it might be hiding somewhere in there.

I'm talking with my friend again tomorrow, and we'll be talking about how much effort he wants to put into a faster chair, various options, etc.

[Burgerman]

except this chair has a MK6i controller.

Old stuff. Best not...