PINNED - Roboteq Controller - developing for powerchairs

[Burgerman]

https://www.youtube.com/watch?v=Fg0pN9ahZWo

John Dingley sent me this. He builds DIY segways, and lots of other balancing machines. The vid is not him!

He says he can send me a box that plugs in between the RC receiver and the roboteq that allows the same thing. Should be fun!

[snaker]

It's magical !!! I feel the man in the video like working in a weightless environment.

[ex-Gooserider]

https://www.youtube.com/watch?v=Fg0pN9ahZWo

John Dingley sent me this. He builds DIY segways, and lots of other balancing machines. The vid is not him!

He says he can send me a box that plugs in between the RC receiver and the roboteq that allows the same thing. Should be fun!

I agree, that is SERIOUSLY cool.... I'm just imagining the effect of showing up at an abilities expo or other wheeler related event and using that....

Maybe someplace where Junky Mark is shilling his elevator seat, and say that instead of an "Ilift" you have an "I-TILT".....

ex-Gooserider

[Burgerman]

Turbo iTilt!

In the script, I will need to turn acc and dec rates up high for RC input only however. And as it is both inputs work, so joystick will override RC to steer etc anyway.

[cdb0ewm]

Is there a place where the latest Roboteq script is available and is there a diagram or table that lists Roboteq pins and their use in the script?
Thanks

[Burgerman]

Latest script that I am using is always here. http://www.wheelchairdriver.com/BM3-con ... Script.txt

But settings are set "safe". A starting point for 45V. Will be very steady well balanced, on slow or fast speeds... On 24v it will be super super steady... But safe.

The actual pins on the connector are shown in the roborun software, depending on which number analog, digital in/out etc you use for which inputs during initial setup...

Heres my profile (zipped up) if it helps. In the Roborun software, free to download, choose hdc2450, then load this profile. You can then see my roboteq setup, and my pin out diagram.

[Burgerman]

Yours will likely be different!

[Burgerman]

latest firmware installed, took 10 secs. Works fine. But no difference here.

Ver. 14b-033115

[Williamclark77]

That wheelie chair is really cool. Another project for another day.

I haven't updated my firmware. No need yet.

After using the chair I have the same results as BM, 10 is way too many reads. Far too much delay. Nowhere near as bad as factory powerchair programming, but no door jam was safe. After getting used to instant reaction that split second delay, mainly when doing a direction change that crosses 0 on the axis, I had to drive "ahead" of the chair to keep from hitting stuff.

I currently have it set on 5. I can still feel the delay. I'm going to leave it there to see if I can get used to it and quit noticing it because it smooths my chair feel. I had to change all of the pot settings. My initial run around the house before my last reply didn't cover enough.

I did gear it up for a few more mph. I haven't tested it enough to see if it'll be good. It feels fine around the house and yard.

[Burgerman]

I can feel it on 0 or 1. Set higher it becomes a pain.

Without it at all, there is still some delay before response. Maybe 1/4 of a second. Its as if the roboteq is .25 of a sec behind the driver. Doesn't sound much but it isn't direct. It allows you to end up with either over control or ending up accelerating in a slightly different direction to what you expected. At least if you are driving it like you stole it.

There is some delay in PG systems too, all the maths takes a finite time. For radio control systems this is known as latency. Good systems have less. And a 100th of a second is considered a lot. It makes flying fast stuff, or 3d helis hard work.

But theres no way to remove it completely.

[ex-Gooserider]

In one of the other threads, someone pointed at this link for a home-build Segway http://www.trevorblackwell.com/#scooter2clone.... http://www.trevorblackwell.com/#scooter2 The author is someone that sounds like a experimental developer type that is willing to look at improvments - our kind of people...

While the link as whole seems well worth reading, I noticed one paragraph that jumped out at me as being particular relevance in light of the discussions about the response lag that Will and BM seem to be having....

I seem to remember Lenny saying that the Roboteq's internal processing was on the slow side, but there wasn't a way to talk directly to the speed control electronics... It seems like Roboteq may also be slow going between its internal micro and the actual PWM controller... This guy appears to be using an external micro to talk directly to the speed controllers and thus minimizing the lags...

I also replaced all the electronics. Version 1's electronics were chosen for maximum convenience. Version 2's electronics are designed for performance. I replaced the dual-channel RoboteQ motor controller with two OSMC controllers. While the RoboteQ is fine for many applications, its use of a 9600 baud serial link for control added too much delay to the feedback loop for good performance. The OSMC controllers take a PWM signal directly from the microcontroller. I also get more precision in the PWM control: 9 bits instead of 7.

ex-Gooserider

[Irving]

Hi ex-G

One reason why I'm not going to using a Roboteq but a homebrew controller... you can't afford the delays of an interpreted system once the complexity gets beyond a certain level...

[Burgerman]

Well I wouldn't consider it enough to be a problem, its about the same response running lennys script, as a tuned up all out pilot plus, but with a lot more power. Its only noticeable if you are a bit of a hooligan.

[Williamclark77]

I can't feel any delay with certain settings. I can definitely feel it with others though. Hopefully soon I'll have time to look at Lenny's coding itself as well as fine tune the settings a bit more.

Irving, just how complicated are you wanting to get? I'm much too into the KISS approach. If it doesn't have a function that is NECESSARY for use then I don't want it. Especially if it's something that could cause an issue when (not if) it fails. Where are you at in the development of this controller? I'd ask specifics but elektrickery isn't my strong point. How about the mechanical portion?

I'm not the type that subscribes to the "good enough" approach to doing things. Could it be better? Of course. I'd just hate to see a final product never happen due to overkill engineering features.

Mine has developed an intermittent squeak. I can't make it do it when I'm where I can find it. Let me go down a quiet hallway full of people though.... creak creak creak.

My poor casters take a beating. I don't know if they get more abuse at high speed or low speed crawling like this. Click to play.

http://www.willsjunk.com/Other/WillChair/n-kfRtm/i-Gwrk5Fq/A

[LROBBINS]

I've been away from home the last couple weeks (in Montana - Glacier Natl Park, Bozeman, Yellowstone) so haven't chimed in. Just a couple quick comments though.

It's only the Roboteq script that goes through its MicroBasic interpreter; most of the calculation is handled by their C programming of a 32bit ARM processor, some is actually done in a CPLD on the power board. It's hard to know how fast or slow the script runs, however, because it is given only a "slice" of processor time every 1 msec, after all the other calculations are done. It would certainly be faster if I can ever convince them to move motor compensation and acceleration mixing into their firmware - those are the only calculation-intensive parts of the script. I am beginning to have a good relationship with their tech people, so who knows.

What John is experiencing with damping (moving average of joystick position) is not actually latency - as soon as the joystick is moved, the motors will be commanded to a new level, but that level will not be the final level until the averaging has gone on a while. Most of the damping effect actually will happen with this parameter set to 2 or 3 (i.e. moving average of just 2 or 3 readings) and at that point I doubt if anyone could feel the delay unless accel/decel values are set lower than they should be. If 2 or 3 aren't enough stick damping, but averaging a higher number of reads makes for too much delay, one can probably compensate by increasing the accel/decel values.

My system is a bit different in that the averaging takes place in my Master node's MCU and is then sent as a CAN message to the Roboteq. I don't feel significant hesitation on acceleration or deceleration even averaging 10 reads, but if I set it to average 20 reads it doesn't stop turning snappily enough for me. (Remember, I'm walking alongside so there's no "seat of the pants" feel for me - John would probably notice lag with 10 reads even in the CANbus system.)

Ciao,
Lenny

[Burgerman]

I've been away from home the last couple weeks (in Montana - Glacier Natl Park, Bozeman, Yellowstone) so haven't chimed in. Just a couple quick comments though.

Hope you are having fun! Its grey here...

[Irving]

The controller I'm working on is a derivation of one designed by a friend. Its brushless, can handle 180A stall current per phase at 100V using 2mOhm mosfets, 6 per phase (3 up/3 down, 18 in total per motor) at ambients up to 40degC. Its modular, so has two motor drives each with local 32bit MCU for PWM generation, current regulation, temperature management, torque control and drive management/logging and one 32bit MCU to do mixing/steering, I/O and balance management (for Segway-like devices). With a little reprogramming the motor drives could be used for brushed motors by ignoring and/or not populating one phase.

[Williamclark77]

Irving, any working prototypes of the controller?

I tried fine tuning on the programming today. Setting the damping on anything other than 1, 5, or 10 is undriveable. All I had tried was 10 and 5 until today. On 3, even at 900 rpm/s of acceleration rate it would not wheelie and felt like it was a full second or more behind the joystick. 2 was still way overkill with much more delay than 5. Didn't try 4 or 6 to 9. I haven't had a chance to look at Lenny's code yet. I'll try later after supper.

Either something is up with the math or I have another setting conflict.

BM, does 5 feel like less damping than 2 or 3 on yours?

[LROBBINS]

Will,

That certainly should not be! I will take a look at the code later this week.

Ciao,
Lenny

[Burgerman]

>>>BM, does 5 feel like less damping than 2 or 3 on yours?

cant remember which settings I tried. Tested a few. But all introduced more delay than off. Which is where I left it. Don't think its aimed at me. More for those that dont fly model helis!

[LROBBINS]

I looked at the code and indeed found a really stupid mistake in the SetThrottleSteering: subroutine.

Look for the lines that read:

Code: Select all

    FOR i = 0 AndWhile (i <= (Damping -1))
      SumThrottle = SumThrottle + ThrottleStack[JSRead]
      SumSteering = SumSteering + SteeringStack[JSRead]
    NEXT


and change it to read:

Code: Select all

    FOR i = 0 AndWhile (i <= (Damping -1))
      SumThrottle = SumThrottle + ThrottleStack[i]
      SumSteering = SumSteering + SteeringStack[i]
    NEXT


I can't guarantee that this is the only mistake, but it certainly won't work right with the wrong array indexing variable!

Ciao,
Lenny

[Burgerman]

I can just find this and swap code.

As soon as I get off this damned bed. Pressure sore from years ago looking a bit bad. So stuck here for a while. Better safe than sorry.

[LROBBINS]

Where it says "JSRead" in those two lines, just change it to "i".

[Burgerman]

got it. Thanks!

[LROBBINS]

John and Will,

Sorry to do this to you, but I realized last night, through my jet lag fog, that there was a second (minor) error that I'd also fixed. Rather than editing that subroutine, the attached file has a new subroutine to substitute for the old one.

There are separate versions for John and Will because Will has a divide by 2 in his for pulse steering - I don't know why.

Ciao,
Lenny

[Burgerman]

Thanks.

[Williamclark77]

Is the "divide by two" you're referring to up in the mode selection? That only affects rc. I did that because the steering was too darty when driven by radio. Too hard to keep in a straight line.

I'll try to give the update a try as soon as I get home tonight.

[Burgerman]

Darty? Really? That's odd, Mines exactly the same as with joystick. Easy to drive smoothly.

Must be to do with the fact that I am using the current sensors. Unloaded chair doesn't get much added feedback. Set that to off and it drives horrible.

All throws set to 100 percent.

[Williamclark77]

Square joystick on my radio. Cut in half by the /2 I added and it feels about the same as the regular round joystick.

And yes, I know to set profiles on my DX6. I just prefer to be able to use one model memory for all of my radio stuff by matching the hardware of the models vs radio settings. The button navigation system Spektrum uses is borderline impossible for me to operate.

[Burgerman]

Square joystick difference. I See. I use a software "ring" for helicopter swashplate mixing on my tx to achieve the same thing as a round joystick.

Hardware version http://www.fortunemodelproducts.com/cyclicrings.html