PINNED - Roboteq Controller - developing for powerchairs

[woodygb]

for 3rd serial mode replace...

' vS1 = getvalue(_CIS,1)
' vS2 = getvalue(_CIS,2)

with

vS1 = getvalue(_CIS,1)
vS2 = getvalue(_CIS,2)

[Burgerman]

I have no idea how! Or what 3rd serial means. They look the same?

Going to copy and paste the full thing from your post 1 above.

I do however really appreciate the time and effort both you and lenny have spent on this (on me!) sorting this out.

[LROBBINS]

Here's a version with everything except serial.

[woodygb]

I do however really appreciate the time and effort both you and lenny have spent on this (on me!) sorting this out.

Your very welcome... it's nothing more than you have done for others in the past.
I must however point out that Lenny has done ALL the real script work on the program .

[Burgerman]

Yes. And it WAY beyond me!

Thanks Lenny.

[LROBBINS]

John,

I can't stop trying to find plausible reasons for why your system sometimes does and sometimes doesn't compile MicroBasic properly, and I haven't come up with any ideas that actually convince me. There might be some things worth trying, however.

(1) Open Roborun after a fresh Windows boot from a completely shut down computer. This will get rid of any accumulated memory leaks and orphaned processes. Does "build" still misbehave?

(2) Use CCleaner or similar to disactivate all non-essential startup items. Re-boot and try again. Does "build" still misbehave?

(3) I have twice had hardware problems mask themselves as intermittent software bugs. Because you are having this problem on both the desktop and laptop, that's unlikely, but I guess still possible.

The first time was with an HP tc4200 tablet that stopped being able to load one of WordPerfect's DLLs. Not always, but most of the time. I tried everything to diagnose what seemed to be a software problem. Then HP started replacing all components of the computer, eventually gave up and replaced it with a brand new tc4400. The new tablet worked fine, until I plugged in my secondary battery, and then it once again would not load that DLL. The battery had a bad "smart" chip that created a memory conflict!

The second time was with a Fujitsu T5010. It would fairly often, but not always, balk while executing particular instructions in a huge (ca. 20,000 line) Perfect Script macro (the scripting program of WordPerfect - much, much better than MicroBasic; like a macro scripting language + complete Pascal-like general programming language + various OS hooks for inter-application communication). Again, I wasted a lot of time looking for a software flaw, even replacing Win7 with WinXP, and could not get the macro to run consistently. So I ran a fairly rigorous HDD test program (HDTune) - no problem there. Then I ran MemTest86Plus and found the problem. The computer had two 2G Crucial sticks, each one had two "iffy" addresses. Crucial customer service said "If MemTest showed a flaw, there's a flaw, here's an RMA number". Sent them back to Crucial and with the replacements the problem was gone. I guess that my macro was the only software that was repeatedly addressing one or more of those four memory locations out of 4G. The reason that the macro sometimes worked and sometimes didn't is that the PerfectScript compiler, just like Basic compilers, is what is called an INTEPRETER - it does not assign fixed memory addresses during compilation for what it's doing. The memory addresses only get assigned when the program runs. Those addresses, depending on what the computer is doing at the moment, can be different each time the script is compiled or run.

So I have a some suggestions for testing your hardware:

(a) Use HDTune of similar with its most intensive settings to test the HDD. The BIOS-based HDD tests are totally inadequate.

(b) Use MemTest86 or MemTest86Plus with its most rigorous settings to test the RAM. Again, the built-in RAM testing that I've seen is pitiful.

(c) Especially because you've overclocked, use IntelBurnTest to test for processor and/or RAM instability. This reasonably user-friendly program uses the same routine Intel uses for extreme testing of their processors. It is the most punishing processor tester I'm aware of. A minor instability that causes a pixel to flicker when running most applications could cause a compiler to create a bad program, so something tolerable, or even not noticeable, in daily use can wreck havoc when programming.

All of these programs are freeware and I'd suggest googling for them and downloading the latest versions.

Ciao,
Lenny

[LROBBINS]

Rachi is going into hospital tomorrow for more surgery (on Thursday). I'll try to check in once in a while, but will probably not be very active here for the next week or so. Not because I won't have time on my hands; I'll be mostly sitting in a hospital room with nothing at all to do. (I'll buy some mysteries to read.) Rather, it's because the only connectivity available in this hospital is a WiFi node that allows all of 15 minutes a day use. Even for the hospital's networks, there's no wifi signal in this particular unit. Ellen and I will swap between hospital and home alternate nights, so I won't be completely isolated from the wider world, just relatively so.
Ciao,
Lenny

[Burgerman]

I hope all goes well.

As for mem testing, overclocking etc, this was the first thing I did. Runs memtest perfectly, also runs 8x prime 95 instances all night without error. Makes a good 1kw heater!

But I too would expect this to be the problem. If it were not for the same issue on laptop! But both are running almost identical operating system and software. So who knows.

The thing WILL build occasionally. Usually if I uninstall and reinstall a copy of Roboteq software its OK at first go! Machine is clean and lean, practically no startup stuff that I dont want and no startup stuff I do not understand.

This is very useful to see exactly what will startup, and lets you get rid of it. Freeware. Called startup.exe Renamed here to .zip so rename it back to .exe, as its really useful on your desktop! All PCs should come with this.

[Burgerman]

http://www.wheelchairdriver.com/gopro/2.avi

Shows me "driving" via the pulse (Radio Control) input.

This is configured as follows. Tank mixing 1
100 percent turn, 100 percent forwards/backwards at the transmitter/input.

Graph shows output, not the instant input. It has delay or acceleration, set to 700 acc/dec for all.

I USE full control movements to show what the motors will do. Forwards and back, and full steering, and both together. It lets you see what you will get. Thios is set to 95 forwards and 40 for everything else in your script. Ignore the downward spike, my finger slipped!

[Burgerman]

What will it do, (roboteq) if I use a pulse width RC style output Joystick instead of analog? AS WELL as Pulse RC? How will it decide which to use? Or will it average the inputs? So that BOTH work in unison.

The question arises as there are many Pulse inputs, and all can be configured and calibrated as motor control? Because I can get a pulse output joystick, which should be safer?



You may wonder why I need RC at all? But trust me, I have RC on other chairs now, and it is UNBELIEVABLY useful for moving them about, swapping chairs, sending one to the shower room for a clean, loading one in a van while sat in another etc. Cant live without it now!

[woodygb]

Hmmmm ..might be asking for trouble unless there is a way to differentiate between the two or turn off the wheelchair joystick.

[Burgerman]

At rest both RX and Joystick will output 1500 pulsewidth. With no radio signal on failsafe.
I GUESS it will take both streams of input and average them So as long as the wheelchair joystick is untouched then both will work, but if it IS touched they will add/subtract from each other. May plug in another reciever and test it. If it works then the on board rx can stay energised 24/7 and just turning on the coded/locked transmitter will give control. Thats even better than needing a button to power up the rx. Anytime I can see the chair I can take over.

[LROBBINS]

John,

Sounds like you've got the hardware and startup issues covered. I'm with Woody that, pending actual testing, having two pulse inputs simultaneously connected might cause trouble. You might be able to use a simple SPST switch on one of them and test (in the script) each of those pulse inputs (the raw input is I think available among the Roboteq _xxx variables). One might stay connected all the time. If the one with the switch is ON and has output, it could take precedence and the script could ignore the one that's always connected. If the one with the switch is OFF (those pulse inputs will be 0,0), the always on one would take precedence. This is the way that Dynamic handles switchover between user and attendant controls: though, of course, it's by CAN.

Scripting is not hard (you will get the hang of it once you read a primer and the manual with the same care you want others to devote to what you write) and quite flexible. Want a speed pot? Connect one to another analog input, say number 5. Read that with _AIC, 5 and use that value to set the value of vForwardScaling. About 9 lines of code and two of those are a SpeedPot label for the subroutine and a RETURN - just a few lines that actually do something.

Code: Select all

SpeedPot:
     vForwardScaling = GetValue (_AIC, 5)/10 'assuming that you've scaled the pot to read 0-1000, and the voltage is offset to scan 0.5 to 4.5 volts.

'avoid runaway if pot goes over-voltage, but still allow driving at a reasonable speed
     IF vForwardScaling > 100 THEN
          vForwardScaling = 80
     END IF

'allow at least slow driving at minimum pot and even if pot gets disconnected
     IF vForwardScaling < 10 THEN
          vForwardScaling = 10
     END IF
RETURN

Notice that we're starting to run a fair number of wires: power and output from your joystick, RC receiver power and output, speed pot, current sensors (though these could be mounted right at the Roboteq outputs), lights, actuators. Moreover, any time you decide to make a change means changing the harness. One of the other advantages of a CAN bus is that communication is on the same 2 wires to all (data, not actuator) devices, so you can use the same 4-wire cable for all connections: B+ and B-, CAN-hi and CAN-lo. At the moment the Roborun software support of CAN is very primitive. To implement it you'd have to pretty much manually write every frame of CAN information. That script would look like the window that comes up when you build a MicroBasic script, except that the programmer would have to be writing all of that for CAN rather than having the Roborun compiler do it. Maybe by the time I have need of a Roboteq, they will have put some CAN-writing tools into their software, because I'm sure not up to manually writing the many, many CAN frame specifications that would be needed.

By using a pulse joystick you automatically become pretty resistant to EMI, but if you add a speed pot, you now have an "antenna" again. That's another advantage of CAN: it is quite noise resistant. Lastly, with CAN it would be like having an (effectively) infinite number of inputs and outputs on the Roboteq - all CAN devices share the same 2 wires and one CAN-lo and one CAN-hi port. It's like USB. Each module has an identifier, they all transmit simultaneously and repeatedly until a message been acted on. The computer has priority levels for each ID, and it eventually (at computer speed) responds to all of the requests. USB might even be just as good as CAN, but CAN has a long history in vehicular applications so it's become the de facto standard for auto and other mobile applications. Standard is a strange word for CAN - the standard is actually so flexible that manufacturers can do implementations that, unlike for USB, won't talk to each other. That flexibility means that the same basic protocol is still usable after 30 years of hardware improvement, but it does mean that manufacturers can protect "proprietary" interests. I wish I knew enough about it to hack existing protocols (e.g. Dynamic's), but I don't.

Ciao,
Lenny

[LROBBINS]

John,

Thanks for startup.exe; it will be useful.
Prime95 overnight is about like five minutes of IntelBurnTest which is why I prefer the latter. Eight instances of BurnTest might overtax even your water cooling!

Downloading your video now. It will take a while with our great (sic) ADSL speeds.

Ciao,
Lenny

[LROBBINS]

Oh yeah, why do I prefer load testing in 5 minutes rather than an hour or more? Because I used it to undervoltage our tablets, reducing voltage bit by bit for each speed step, testing until reaching instability and then then setting the voltage a little higher than that. Got temperatures down by ca. 30o on the Fujitsu. Ciao, Lenny

[Burgerman]

http://www.roboteq.com/sensors/mgs1600- ... ing-sensor

These look interesting. Magetic tape cheap too. I visualise my chair doing 15mph through all the rooms and doorways im my house inch perfect. More seriously, there are MANY people that are not very accurate, cant do the van ramps or drive indoors accurately. I wondered what the roboteqs pulse sensors "mag" setting was for!

Now I can send my chairs off to the garage on their own out of the way for a sleep. For what its worth this tape works UNDER carpets too.

[Burgerman]

>>>Downloading your video now. It will take a while with our great (sic) ADSL speeds.

Its not very exiting. You will see I am sacrificing some turn rate at full speed to maximize speed! As you do...

I really think you should get yourself one of these Roboteq HDC 2450 controllers to play with. You can then move to lithiums, with higher volts, lower geared motors, and smaller batteries, motors, and have same speed and range as before with way less size/weight and greater reliability and battery life.

[LROBBINS]

Just looked at the video. Still an upside down mirror image on my computer, but this one is simple to interpret and IS LOOKING GOOD.

BTW, I suspect that you'll find Mixing Mode 2 more comfortable than 1 at least at large stick deflections. I haven't any idea what mode 3 would be like as the table seems quite messed up - take a look at the 3rd row from the bottom. Stick part way forward and turn mildly left, move it further forward and according to that table you'll start turning right. Huh?

Ciao,
Lenny

[woodygb]

All the 1000 throttle values in the mode 3 table seem wrong.

I have a question concerning modes and the actual shape transcribed by the joystick ... Lenny said that wheelchair joysticks ..in the main .. have a round restrictor plate ..thus their movement range is circular ..R/C Sticks haven't got a restrictor and thus their movement is contained in a square with corners...how does this effect driving when switching between the two ..and would it better to have a mode for each "shape"?

[Burgerman]

It doesent seem to make much difference.

I fly helis. The swash plate that controls the cyclic "prefers" a round joystick, so many pilots fit a physical metal "ring" to stop the stick going into the corners.
Otherwise you get more swash plate movement (in degrees or in blade pitch) when in the corners than top or sides. But in the case of an electronic controller, this doesent happen. You are looking at two channels. Each INPUT can go from 0 to 1000. The mixed output also goes to 1000. So if the mix needs say 1050 output in the corners you just cant have it! So you get the round stick effect without the mechanical need?

I think???

[woodygb]

The mode 3 seems to me to be applicable ONLY to a joystick with a round restrictor plate.
The formula seems to add ..in the three columns shown... 120 160 and 200 to the starting throttle value for each 100 throttle increment... thus the 1000 is wrong in the first column.
Go into a corner and your just going forward or reverse on both motors flat out.

mode3robo1.gif (201.75 KiB) Viewed 13601 times

[Burgerman]

Mmm.

I just tried it. Seems pretty similar to 1 to me? At least it looks to be doing the same thing on the graph screen.

[woodygb]

Fair enough.... the numbers must just be wrong in the chart.

[Burgerman]

If you are a speed freak (I am) then 2 works best. It allows 100 percent go, but at full power it does all steering by slowing one wheel. They all do. But 2 does it by the same total amount (40 steering) even at full speed. In other words as you get to the top of the graph, it adds the turn to the slower wheel so you dont lose steering response. In other words it allows 100 percent speed and full turn capability.

[LROBBINS]

John,
That's a good description of mode 2 and it's the way Rachi's dynamic is set (for driving from the attendant joystick). I find this adding back the truncated throttle value into the turn more comfortable than having just the truncation (mode 1). I'm decidedly not a speed freak, and sharp turns at speed are mechanically restricted (see below), but I still like this mixer for shallow turns at full throw or near full throw. The chair doesn't slow down as much when I turn because half that speed loss is coming back through one wheel. Mode 1 feels sea sick to me.

Woody,

I don't know if most WC joysticks have a round restrictor. The gymbal geometry itself, at least on inductive joysticks, usually imposes a circular rather than square pattern because the ball is well below a circular-opening top plate, but restrictor plates are often added to that. Rachi's first power WC with its analog computer used an inductive stick with a square restrictor turned 45o , but the ACU on the dynamic has one with an asymmetric pentagon so that turning when going backwards is very restricted. It's like a square with the front corners cut off and the rear reduced to a triangle. That's standard dynamic, not a special issue because it's a FWD chair, but they may use this because the stick will at least sometimes be used on FWD. Or it's just a general stability precaution - prevent sharp turns when going fast. You can see what this looks like in the Apem (CH products) brochures for the 9000 series inductive stick http://www.chproducts.com/9000-Series-v13-d-732.html or the 3000 series Hall sensor sticks http://www.chproducts.com/3000-Series-v13-d-748.html. In one brochure the drawing refers to the "X lever", in the other it refers to "X limiter".

JoeC - do you guys take out the restrictor plates for wheechair soccer?

Ciao,
Lenny

[LROBBINS]

John,

That magnetic strip sensor looks neat, but be sure to mount it on something that can swing out of the way - the working distance is 10 t0 60 mm so it's going to rather reduce your ground clearance.

Ciao,
Lenny

[Burgerman]

Well I wasnt really meaning for myself, that was just my attempt at humour. But for those that struggle to control powerchairs, as an add on.

[Burgerman]

http://www.wheelchairdriver.com/BM-MK3-roboteq.htm

Updated the roboteq page since this stuff reminded me!

[Fulliautomatix]

Updated the roboteq page since this stuff reminded me!

Are you having a monitor?
I'd like to retain the 'fuel gague' rather than just a low voltage alarm.
http://www.chargery.com/cellSaver16S.asp ??

[Burgerman]

I am, but not sure which yet. I have a few such ones laying around as used on my planes and helis on the flying feild. Although not as good as that one!

The fuel gauge though wont work just by measuring voltage, since all those devices are linear.

Voltage on the headways initially drops from 3.65v (as recommended by headway for dirty fast charging with awful cheap bms that cuts out charging too early) or 3.60 as recommended for best capacity with long soak times for hobby use type chargers, and faster balancing, or 3.450v as I do - because you lose less than 0.05 percent of capacity but balance takes longer and lithiums are longer lived -- to around 3.3v in the first 100 yards.

So you lose .35 of a volt almost instantly. Then it stays there at 3.3 and a bit for the first 1/3rd of a charge. Literally without moving. At least enough to detect without 3 decimals. At which point it drops suddenly to 3.25 volts. This is like a step. Then, it stays there for another 30 percent with almost no volt change. Then, it starts to fall slightly right near the end, at wich point it falls from 3.2 plus to around 2.7v over a very short distance or time. At this point detection by your backside is easy as you have lost a big chunk of your speed or voltage over the length of a block of houses. Still no damage will occur as you can run these cells to 100 percent discharge safely - and thats even lower at 2.5v per cell. Where the chair will be slowing as if you have run into a wall.

What I am getting at is that other than the start - 100 meters, the step in the middle at 30 to 35 percent, and the drop off a cliff at the end the "curve" is flat. So a voltage base fuel gauge will not be able to tell you anything. Although there are capacity based ones available, which due to the lack of peukert on lithiums, are absolutely accurate in the way that the gauge on your existing chairs controller never can be.

So while these gauges are useful for detecting end points, and I will uses one, they will not really be any use for telling you whats left! In a LiPo battery they work great. They have an easy sloped graph to be able to say how much is left and its proportional to charge. But LiFe cells are all a bit different. Effectively a cheap low voltage buzzer, on the cell or row of cells with the lowest voltage set to detect 2.7v after a 10 sec delay will be just about as useful.

The Hyperion of course will tell you very accurately how much you put back in Ah. So you will have a good idea each day of how discharged it was. But I suspect you will wear out each day before the battery does!

I will discharge my 78 cell pack on the hyperion and show the shape of the curve over many hours at a slow discharge so you can see what I am talking about! And post here tomorrow.