PINNED - Roboteq Controller - developing for powerchairs

[Williamclark77]

Oh, I've tried all 3 mixing modes. Just number 2 today. Mixing mode 3 is just weird. It does fine going slow or fast. In between though and it's like.... well, weird. Doesn't go in the direction you point. Reminded me of trying to paddle a long canoe from the back against the current.

And yes, I'm very happy with it. I do wish I had gotten the 5:1 planetary instead of 4:1 though. If I had, my second reduction would be pretty equal in size instead of one much smaller if I gear it down more. Chain noise is not bad at all. Dead silent below 4 to 5 mph. I wasn't really paying attention to it though.

I was hoping my casters wouldn't wobble at speed. Glad yours doesn't. Mine are horrible with no preload. I will try balancing them when time allows. It made little difference on ones I've done before though. Like you said, they eventually wore to smooth running then eventually started back. Mine not having much offset doesn't help. I'll get total measurements of my chair and update my build thread in the next few days. It's shorter and narrower than my Permobil c350.

36 possible connecting relationships between the ABC hall wires and ABC/UVW phase wires. Only 1 will get the best forward direction and 1 the best reverse direction if they're neutrally timed. These are supposed to be. The rest of the wiring combinations give everything from a locked up motor to just wobbling back and forth to sounding like a food processor to ALMOST working right. The Goldenmotor motors took us a long time to figure out. I had no idea what color wire was A, B, or C. Someone on Endles-sphere made a chart of the typical connections that work. I'll have to dig for it.

You must get yourself a test dummy! Preferably a gullible one with a quick reaction time!

[Burgerman]

And I think you will be better with the turf tyres and alloy hegar rims too. As for casters, try some smaller or flat profile treadless slicks as they do not ever seem to shake.

Or a set of these should be OK too http://www.aliexpress.com/item-img/9-ol ... 61706.html

http://www.ebay.com/itm/Kenda-K372-9x3- ... 65&vxp=mtr

http://www.tyreandtubeaust.com.au/categ ... tli-kenda/ Or the smooth ones... in 8 or 9 inch sizes as shown here.

Then we need a race, and a range competition! Should be very similar

[Williamclark77]

You can have the top speed title! GPS tested at 14.5 mph was a bit fast with my old motors. The terrain and woods where I spend most of my time is too rough. 13 to 14 mph should be the sweet spot for torque vs speed gearing that I will like best. We will see. I'm off work this weekend and will (should) have two full days to figure out what I want. It'll probably be then before I get to get back in it.

I will eventually go to aluminum wheels with tubeless tires when my budget allows. I got the cheap steel in this size so I would have spares for the younggun's atv if this project was a flop. All that time I spent making sure the hubs were perfect with no runout is wasted on them.

[Burgerman]

You will find those tyres wear out in weeks on hard surfaces. So better start saving for turf tyres! I took 3 years to wear out a set of those. And 7 sets of caster tyres down to the canvas.

[Burgerman]

THIS IS A MARKER
This is the current best and usable script complete with best settings.
Its extremely workable and better than a stock powerchair.

Set ROBOTEQ Acc and Dec to 700 and 800 respectively.
Set COMPENSATION to suit motors
Set CURRENT SENSOR input numbers to suit your setup (lower in script).

download/file.php?id=3130 DOWNLOAD

I have tested this one to death and spent ages getting it to be balanced and smooth for a 15mph chair. By RC ONLY, but with occupant.

___________________________________________________

Every thing from this point on is a new way of doing stuff, all changed!!!

[Williamclark77]

I'm using that one. Thumbs up to it!

=========================================================================================================================================

Attached is the script Lenny last posted with my settings.

The M1Accel and M2Accel settings at the very top do not change the motors independently. They get averaged. Ie - setting 1000 on M1Accel and 5000 on M2Accel gets the same result as setting both to 2500. Same with the M1Decel and M2Decel. Motors turn at equal speeds.

Forward and reverse scaling and turning looks to work great on the graph. Release the stick from a turn and both lines come together then go to zero.

As long as you don't cross zero that is. Crossing zero while turning gets odd results. I took screenshots to show it so maybe you two can picture my explaining.

Pot on 30% to make it easier to see. Stick straight left. One tire is going forward and one rearward for a zero turn correctly. The flats in the graph. Joystick is slowly moved from full left to full straight reverse against the edge of its travel. Basically making a C shape. The power curves should have came together below zero and maintained a straight line. Instead, motor 2 doesn't go far enough. Full reverse stick = turn in the wrong direction. Release to zero then reverse and it reverses correctly. Clear as mud?



Stick applied from full reverse to full left stick to full forward. Basically a C shape against the left turn from full reverse to full forward. Same results but in the front direction. Reverse was going fine. Graph shows both motors reverse power. Left turn was correct. It's ok by my eyes and the graph until crossing zero, then it goes screwy. Full stick forward is turning.



I didn't get to test the other settings yet. I can if needed tonight.

[Burgerman]

That's more or less what I was seeing on the previous pre pressure sore testing. And why I suggested not driving it yet!
Lenny was getting frustrated with the way roboteq does things I think. And the version you are testing here doesn't seem to have changed anything.
The two numbers at the top must be changed together.

[LROBBINS]

Rachi and I have an appointment with the health service bureaucrats this morning so I'll not get to this till this afternoon, but then I'll have a look. The separate M1 and M2 acceleration parameters are there only to deal with the unlikely possibility of two grossly different motors - the script doesn't actually average them, but the mixing algorithm will attempt to balance things despite motor differences. If the two motors are similar, you'd never notice the effect. If the two motors are grossly different in their intrinsic acceleration rates (e.g. if you mount an 8mph Groove motor on the right and a 6mph F55 motor on the left), there might be some wandering around a straight line during acceleration/deceleration and then, and only then, would making these values different from each other have any effect at all. I know, what I just wrote is probably unintelligible, but if you go back a few pages in this thread you'll see a lengthier discussion of this. Eventually, I'll get around to changing this to just one parameter, but it was actually reassuring to see that John's results show that the algorithm fights the difference as it should.

I couldn't follow what WIll wrote at first read, partly because I have trouble visualising what happens to fore/aft and left/right movement from just motor power curves, but when I come back to this I'll turn on motor simulation, run through his stick movements and see what that tells me. Obviously, something is not right as my last change went from not being able to turn at all while decelerating to turning strangely when crossing zero. First guess is a problem in a the longish chain of IF statements.

Ciao,
Lenny

P.S. Yes, I am frustrated with Roboteq, and right now particularly because there's been ZERO response to postings on the forum about the steering during acceleration/deceleration problem - less po'ed about the lack of response to postings about bugs in their script commands or suggestions for improving Roborun+. BTW, I have now confirmed from the Roborun console with the HDC2450 connected that the _ACCEL command does absolutely nothing at all - it's not even recognized as a command string. It's just plain broken.

I am also frustrated because I haven't been able to read Roboteq CAN messages, I don't know whether it's working and I'm not, or whether this unit is broken (as the very low CAN-lo voltage suggests to me, but Roboteq gives no specs for what it should be), and that without an oscilloscope I can't verify whether there's a CAN signal at all nor is there anything, even as trivial as the LEDs I put on my boards, to tell me that CAN messages are actually being loaded into the transmit/receive buffers. If I needed one more than once a year, I'd buy a decent scope, but my need for it is rare and I really haven't enough room to just store a $hundreds piece of equipment. Wish Siena wasn't so technologically backward that we have no maker/hacker group - were I in Milano or Roma, I could join something like ex-Gooserider's asylum and make short work of some of this stuff.

[LROBBINS]

I see that a couple posts from yesterday got lost in the changeover, so I'll remind you of my request for help.

I would like one of you who has a Roboteq to check the CAN-hi and CAN-lo voltages. If they're like on mine, it will be safe to assume that I'm just not understanding how to use their CAN scripting commands. If they're closer to those on my other nodes, there is probably a hardware defect. To do this:

In Roborun configuration tab, enable RawCAN and update the controller
Turn off the Roboteq, disconnect the USB cable and leave it disconnected (CAN is disable when USB is plugged in)
Turn on the Roboteq WITHOUT reconnecting the USB (CAN is only enabled after restart).
Measure from ground to CAN-lo and CAN-hi. On the HDC2450 these are: ground = DB9 pins 3 and 6, CAN-lo = DB9 pin 2, CAN-hi = DB9 pin 7.

Attached is a new script to test. I think I found all the errors, more typos rather than logic errors. I've simulated some 60 or so different joystick transitions and all seems OK, but you all will probably find the conditions I didn't have in my list that don't work right.

Ciao,
Lenny

[Burgerman]

Would do it for you now. But glued to the damned bed...

[Williamclark77]

I'm still at work. I'll be home (hopefully) about 7 pm central us time. I will check the voltages and test the script then.

Something odd testing the last script: Normally all I do is stop the script running in Roborun, hit download to device, then click run on the script and it works fine. Changes take place immediately. Twice it did screwy things. One time motor 2 wouldn't work. Another time it just seemed to turn the tires randomly. Rebooted the Roboteq and it worked perfect. I started rebooting it every time I changed something in the script and never had another glitch.

====================================================================================

For your humor and sympathy at the same time - Monday I was home and planned to fully charge my chair and do range tests. A friend was at the house. She offered to plug the Hyperion to my computer for me since I had the chair in the way of the tower and the jack from testing settings so I wouldn't have to move everything. As she plugged the usb cord into my computer sparks flew from the port and the Hyperion looked as if it was full of exploding fire crackers. She had plugged the charger end of the cord into the temp sensor port. How, I don't know. But she did. She must've been the kid in preschool that could fit the square peg through the round hole. This is exactly why I prefer struggling with stuff myself. Oh well. I haven't had a chance to disassemble the Hyperion yet to check out the damage. It doesn't work though.

[LROBBINS]

Thanks Will. 7PM CDT = 2AM tomorrow here in Italy. I probably won't be awake then (though too often I actually am). BTW-I tried my monitor node on my CANbus just to be sure it is actually working (I have been known to screw up even simple programs). It works. So I then set the Roboteq and my monitor to 125 kbits/sec (instead of 1M) and had the Roboteq send a message 100 times. Saw zip once again.
Ciao,
Lenny

Irving - don't know if you saw my earlier note before it went into IT hyperspace. That Hantek is sure cheap enough and small enough even for my apartment. The 20MHz bandwidth would be marginal for seeing waveform on 1Mbit/sec CAN messages, but should do pretty well at lower bit rates. I might opt for a 6022BL that includes a logic analyzer in the same box: that would be handier for deciphering messages.

[Burgerman]

Twice it did screwy things. One time motor 2 wouldn't work. Another time it just seemed to turn the tires randomly. Rebooted the Roboteq and it worked perfect. I started rebooting it every time I changed something in the script and never had another glitch.

Yep same here. Only with the new script(s). Never a problem with the old sorted one. No idea why.

[LROBBINS]

John,

Don't know why I was ruminating about this, but I was thinking about why a disconnected current sensor could give a runaway condition. Given that there's a 33k pull down built-in on the analog inputs, if a current sensor is disconnected that pin will see 0V. But 0V is not 0 current, it is -1000. That means that even with a small milliohms set, some compensation will be added to the motor commands so that even if steering and throttle are 0 the motor will be powered and turn. The same thing would happen if there were a short to 5V (for example, an internal short in the sensor itself). It would be like having the motor neutral point moved away from stick center.

Setting a guard band e-stop in the Roboteq would not be ideal because the chair would then be un-drivable if a sensor failed. What could be done, however, is to not apply the motor compensation if current < -990 or current > 990. That way, a broken connection or shorted sensor would just cause a loss of motor compensation but you could still drive. You could even have that trigger a dout (if you have any free ones) to tell you that there's been a sensor failure. (In my case, if I ever get the Roboteq to talk CAN, I'd just send an error message to the display). Of course, that light would also blink and you'd lose compensation any time current really went to 99 Amps.

Ciao,
Lenny

P.S. I noticed that in your profile you have the amp trigger point set above the amp limit. It won't do anything because you can never reach it. A trigger point (with delay time) set below the amp limit protects against long-duration high current situations, such as backing into a wall and not letting go of the stick. Don't laugh, an aid in Rachi's high school, who insisted she knew how to drive the chair, did exactly this with herself between the chair and the wall. I had to actually pry her hand off the stick.

[Burgerman]

Of course, that light would also blink and you'd lose compensation any time current really went to 99 Amps.

Every time I turn fast...

P.S. I noticed that in your profile you have the amp trigger point set above the amp limit.

I have not configured that for use yet. I expect to set both to 150, once sat in it. But its configured to do nothing. Because it is way too sudden...

And its actually untrue to that it wont do anything set higher, because it can momentarily exceed 150A before current limiting throttles it back. Up to 250 peak/pulse. Hence the short circuit cut off settings.

Trigger actions:
None
Safety stop, (locks wheels, and then applies brake)
Emergency stop, (locks wheels, applies brake, turns off controller...)

[Williamclark77]

Quick test on the CAN-hi and CAN-lo by checking the voltages between pins 6 - 2 and 6 - 7 on my HBL2360. My manual says they're the proper pins.

CAN-hi shows 2.17 volts. CAN-lo shows 2.22. Sound right? I have no clue what it should be.

Just to check, I disabled CAN and the voltages were the same. Even with usb plugged in they were 2.22 and 2.17. I didn't change anything under the default CAN settings for node, bitrate, or heartbeat. I did try setting the CANOpen autostart to enabled. Same voltages.

No testing of the script yet. I'll try to tonight and post back.

[Williamclark77]

Re current sensor endpoints: My 40mv/a 50a sensors should, in theory, put out 2v above and below the center. I calibrated the end points slightly above that with it sitting on 2300mv with no load and set it to trigger a safety stop. It would still trigger a safety stop occasionally (which I thought was the short circuit protection at first) when releasing the joystick at speed or applying back stick. I kept bumping each endpoint up until it quit. It hasn't triggered a safety stop since and disables the Roboteq if unhooked. Not the best case scenario if one fails or wire breaks in a bad spot, but better than a runaway. Is there a better way? (besides scripting a cut off)

I haven't tried the sensors with no center deadband yet. I think that'll help with the tiny bit of jumpiness at very low input turning.

[Williamclark77]

20 or so minutes on the jack and this version appears to be working correctly. The tires look to be doing correctly as well as the lines on the graph in Roborun. It's 10 pm and I've been in this Permobile since 4am this morning. I'll try to get my idiot/test pilot to ride over tomorrow afternoon and butt test it for safety before I get in it to test the feel.

[LROBBINS]

Hi Will,

Thanks for checking those voltages. Yours are correct and similar to what I have on my homemade bus. That is, there is roughly equal voltage on both lines. Your Roboteq is a bit lower than my 2.7V, but my 5V is, however, at 5.5 V and your Roboteq is probably somewhat lower, say nearer 4.5. My Roboteq, however, sits at CAN-hi = 2.6V and CAN-lo = 1.45V. There's pretty definitely a fault in my unit, which means I'll be contacting Robots-Italy and asking them to repair or replace it (so I'll see whether they actually balk at applying the European Guarantee of Conformity) and I'll write to Cosmo to ask whether there's the possibility of an in-the-field fix. I could open it up and take a look, but won't do that unless told to do so by Roboteq as that might be enough of an excuse for not honoring the warranty.

As to there being voltage on the CAN pins whether CAN is enabled or not, I'm pretty sure this is normal, or at least Dynamic does the same - the CAN transceiver chip gets power as long as the unit is plugged in, in Dynamic's case even if the controller has been "turned off". My Roboteq does the same, though always with those abnormal voltages. BTW, a 1V or so difference between CAN-hi and CAN-lo is what one should very briefly have when a bit is actually being sent, something you'd would never see with a meter. Seems like my Roboteq is permanently stuck in a "bit dominant" state.

Glad to hear that the newest script seems to be working OK so far and hope that this continues. With this algorithm it should be easier to fine tune and to maintain as other things are changed; the previous one, though it worked, was rather a kludge.

On the current sensors, I'll wait a bit before changing anything in the script. Your (Will's) approach of pushing the limits outside the normal envelope looks like it avoids false stops, but it still means that the chair will be dead in the water if a real sensor fault occurs. It will be easy to simply not motor compensate rather than stop if limits are exceeded, but I can see that user settings for those limits would be needed as different chairs can have (and do have) different sensors. Doing both might be the best idea: set a script band to avoid adding motor compensation to what should be neutral, but make the limits wide enough to avoid false motor compensation drop outs.

I have to take a look at my 100Amp sensors as well. Instead of giving me 2.5V (relative) at 0 current, they are giving me 1.7V and I haven't yet tried to find out why. As they are both the same, I don't think that I over cooked them when soldering. I suspect that the added filter may actually be pulling it down, but haven't checked yet nor even looked at the schematic with this in mind. With the filter, the Roboteq sees only 1 mV noise on one sensor, and 0 mV on the other.

Ciao,
Lenny

[Williamclark77]

Lenny, not that I'm doubting you at all since you are 100x farther advanced at this elektrickery than I, but are you sure you are not looking at the pinout diagram in mirror image? It doesn't exactly say if the diagram is from the front or rear view. I did that with mine and had to redo nearly every wire (or Sommer did rather and threatened my life when I found my mistake). Checking my voltages as if the pinout diagram is from the other direction gives me a reading of 2.22 and 1.60. The positive doesn't match right though. Anyway, just making sure before you do a lot of extra work.

My 5v on the 25 pin connector is 4.7v if I remember correctly. I didn't test the 5v supply on the 9 pin connector when I had the covers off last night checking. Already buttoned it back up when I saw your reply this morning. I can check it when I get back home this afternoon if you need. It'll be easy.

Good luck with them replying about a fix. I still have my HBL2360 unit here with the blown mosfet. I asked them about repairing it, giving me credit exchange toward a new one, or at least selling me the parts to fix it myself and that I wasn't trying to get it fixed/replaced free under the warranty because it was my fault. I shorted the motor wires. No reply. I could've lied and played dumb about why it failed. It was still well within the warranty period. Oh well. Honesty rarely gets you ahead.

Talked to my brother (test dummy) today. He's out of state until next week. I'll try to rig up my test setup I used to use in case the worst happens and try out the script tonight.

That is low on the current sensors. Unloaded, both of my 50amp current sensors sit on 2380mv and bounce around with noise between 2375ish and 2385ish. I have the centers set at 2380.

On another note, I will later have to up the gauge of my motor wires. When I ordered my motors their standard option was 12ish gauge wire (it's a metric size and I can't recall the exactly what it is). When I asked about heavier wiring for a high amp application they said it would add about two months lead time to getting them because they had none stocked. Impatiently, I didn't want to wait. I shortened the stock wires to about 5" long and they're fine for normal use. However, a few days ago they got very hot while using the chair in the woods with my 5 year old in my lap. Lots of low speed high amp use. The 8awg Roboteq motor wires as well as the motors themselves never got the least bit warm. Another task for another day.

BM, I'm ready for you to get healed up and back in the BM3. I look forward to video, pics, and comparisons!

[LROBBINS]

I've now wired up my old, airline-damaged joystick and a 10k trimmer as speed pot and run the controller (no motors connected yet) with the last script I posted (just changed some pin numbers to match the ones I'd already assigned). Head scratching for a bit because the brakes never set, but then realized that this old stick doesn't center well, has short voltage swings and is rather noisy. Changed deadband to 15% and the brakes work. Of course, the brakes have nothing to do with the script, but it seems to be working A-OK as well, or at least I can't see any strange behavior in the Roborun graphs.

So, John, tell that sore to heal up already!

Also, my memory played one of its tricks on me in my last post. My current sensors are not at 2500 mV at 0 current, but they're not as far off as I said above. They are both right around 2070 mV.

I have my fingers crossed (no, I don't really believe that does anything) that the Roboteq CAN fault can be cured with something as simply as re-burning the PLC (for which Roboteq would have to send me the file as they don't include it on the download page as far as I can see). At least I think that the HDC2450 has two PLCs since both update PLC (controller and power logic) boxes are active once the controller's been recognized.

Ciao,
Lenny

[Burgerman]

So, John, tell that sore to heal up already!

Working on it... At least I got the forum moved and speeded up while I am stuck here

[LROBBINS]

I wrote to Cosma Pabouctsidis of Roboteq around noon my time (middle of the night in Arizona), and had an answer from him an hour or so later. This is a field-doable repair and he will send me a control board - at least once he's convinced that my CAN isn't functioning. I'm convinced, but he seems to want an oscilloscope trace. (Attaching a CANbus analyzer would be a waste of time; there isn't going to be any signal to analyze). In any case, I am pleased by his responsiveness, and pleased to not have to re-do all the AWG8 wiring. I'll try to attach a copy of our exchange - it's actually a small pdf with ".zip" appended so I could post it here.
Ciao,
Lenny

[woodygb]

Lenny ..did you spot Will's question ..last post previous page ...about pin numbers and measured voltages?

[LROBBINS]

Thanks for the heads up Woody. I had missed that one, so I'll double check my wiring. I went by the actual pin numbers on the connector (seen under a stereoscope as my eyes are not up to it without magnification). I know that all my wires on the DB25 are connected correctly, but I might have screwed up the DB9. It wouldn't be the first time I have egg on my face though.
Ciao,
Lenny

[LROBBINS]

I just double checked my pinout - it's correct. Just to be sure, I also checked to make sure the factory didn't "mirror" connect the socket. It's correct too.
Ciao,
Lenny

[LROBBINS]

A note just arrived from Cosma saying that he's shipping me a new board and that it has been tested for CAN function. I'd class that as excellent service. After I get things running and send a proper thank you, I think I'll post what I'd put on the Roboteq forum directly to him. Ciao, Lenny

[Williamclark77]

Awesome news! I will try to email him direct one day about replacing the blown mosfet in mine. It's currently buried in a box somewhere. I had emailed their regular support link through their website.

Sorry, but I have still not been able to butt test your latest script. No test rider and been too busy using it.

[Burgerman]

going good?

[Williamclark77]

Very. Other than I must pull the motors off to redo the factory wires that is. It doesn't have to be done any time soon, but for permanent use it does. They're too small and get hot when pushed hard. Very hot. As in melting the wire loom hot. The 8 awg Roboteq motor wires, motors, not Roboteq itself gets more than warm. I have them shortened to just a few inches long, but for a permanent fix they'll need to be replaced. I wish I had been patient enough to wait and had the motors built with bigger wires. Oh well.

I do have some mini 40mm computer case fans ordered for the Roboteq. Probably unnecessary, but rather have the option already installed if every needed.