PINNED - Roboteq Controller - developing for powerchairs

[LROBBINS]

If the Roboteq had a means to output it's calculations to a screen (as opposed to a PC) you could easily use it to calculate battery SOC. It already monitors battery current. You'd merely have to sum that over time, say once a second, and send that to the screen. If the Roboteq also had some non-volatile memory accessible from the script, you could even compare the integrated current at the voltage steps to adjust the charge-storing capacity as the batteries age. As far as I can see, the Roboteq controller's microprocessors don't have accessible non-volatile memory to store information.

CAN would again help as a means of sending output, although serial could also be used, then another external and more capable microcomputer, e.g. an Arduino (with CAN shield or just its built-in serial/USB input) and and LCD screen shield, could do all the data storage and calculation and plot the results. That would also give one a way to log and display fault codes, status indications etc., but I suspect that doing this would be a pretty major programming project. Perhaps not. I'll let this idea percolate in the recesses of my brain for a while and perhaps get some idea of how hard this would be to do if we dumped all Roboteq measurements to an Arcuino by serial once a second. A fundamental safety factor is that this Arduino should be reserved to information output and not get involved in controlling the chair - that way a hobby-level board is acceptable because it wouldn't affect driveability.

Ex-gooserider, since you have Arduino experience, how about you giving some thought to this as well.

Ciao,
Lenny
Ciao,
Lenny

[Burgerman]

when running your script, the graphing of the data slows and is uneven. The less things you monitor (un tick all the digital in/out monitors or fault led for eg) and the faster and smoother the graph runs. Its as if the script is keeping the serial port or USB busy. So this may not be possible, or the script may need changing to stop this? Setting wait to different values has dramatic affect on smoothness. And timing seems important.

[LROBBINS]

John

The Roboteq seems to have a very basic microprocessor, so it probably has very little serial bandwidth that's easy to overload. Changing the Wait time in the script from 20 to 40 microseconds will probably smooth out your graphing, but it will make real chair response more sluggish. Whether sluggish enough to be noticeable, I don't know. Of course, when actually driving you shouldn't be watching the PC so that serial load won't be there.

I'd also comment out all of the PRINT lines when using the script on a real chair, and perhaps even for watching the graphs. The Roboteq has a built-in wait after every 32 characters or every print message, whichever comes first. Commenting out the print lines might, therefore, make your graphing smoother. Those PRINTs are there to help see what the script is doing, and they are only visible as far as I can see in the simulator output (console) screen, but add nothing otherwise except microprocessor load, serial data and those delays Roboteq automatically adds because of its low bandwidth, minimally buffered serial.

You can always take the ' marks out again if you want to work on the script from the PC (or constantly keep two versions synchronized - one with PRINT lines and the other without. That's probably what I'd do; have a "master" script with the PRINT lines and a WordPerfect or other macro to make a copy with the ' added. Download the master to the controller for tuning programming, download the copy for driving or looking at the graphs.

Ciao,
Lenny

PS Microcomputers are so cheap these days that from a hardware standpoint Roboteq could easily upgrade capabilities. The hitch is the cost of writing new software for a new microcomputer. Eventually they surely will sell controllers with non-volatile memory (perhaps even an SD card or the like), more serial bandwidth, screen-readable messaging etc., but for now that's just not there.

[Burgerman]

Thanks, will try that. If you watch the output in real time, even set to 100ms, its fast enough to seem instant and still smooth.

So I set it to 50. That seems OK. As a compromise between graph update and algo speed updates.

Oddly some numbers work well while say 53 will be very erratic when watching the graph. The roboteq runs it fast enough, its just the serial data transfer thats slow I think.

[LROBBINS]

Increasing the Wait time slows the controller update as well as sending information to the PC. You might try just commenting out the PRINT statements and keeping a short wait to see if that lets the graphs flow smoothly. It's one thing to have a smooth and instant-seeming graph, it's another to have the most responsive chair control possible.

Would a 100 msec delay in starting/stopping a turn be like having Pride programming? Probably not, but why not aim for the most immediate control possible? Keep delays to a minimum now, and you'll have less lag when you add more functions, safety monitoring, battery monitoring, reading a speed pot, etc. to the script later.

Driving signals should be processed in as close to real-time as possible. Other functions, such as reading a speed pot or sending logging information to a storage system, could run on a much slower cycle. For example, 200 msec for the speed pot would be fast enough, and 10 sec intervals for battery use. Doing the programming gets only a little more complicated. Read joystick and update motor at each cycle through MainLoop, read speed pot only every 10 cycles, and send logging data only once every 500 cycles. That's also roughly how Rachi's DX display works - faults are acted on immediately, but it can take quite a while until they are typed out on her screen. (The DX microcomputer isn't modern high-end either; that's why it can't handle high phase-rate brushless motors, just the slow multi pole gearless brushless as per Invacare.)

Ciao,
Lenny

Ciao, Lenny

[Burgerman]

Commented out all the print statement lines. Graph smooth! Fixed.

Then tried to reduce the wait time to 20ms and it has gone back to not letting me build again... same invalid _xxx stuff again!

So tried on laptop. Same thing.

If I reinstall the roboteq software, or restart everything, and hold my mouth right, it will go back to letting me build and download to device. But yes it works. And I suspect 20 or maybe less will work fine. All that really remains is to test the motor compensation! And figure out a neat way to power brakes with 12v from the 5v switching (digital out) via solid state relay, a small inverter and a 45v battery... And to wire up and power my home built joystick. Then we are in 15mph 45v lithium powered 45 mile at least range, business. With more control, torque, speed, and range, than any other powerchair! I am going to wear the legs off my german shephard dog!

The brake (LED on/off on screen) seems perfect with a 400 to 500 ms delay too. I am using Mix2 and 100 percent speed, for maximum speed. Then all the turning at full speed hapens by slowing inside wheel only, but rate remains the same at every speed.

[Burgerman]

Found the build (compile?) error. At the top of the screen theres a drop down box that says v 1.2. If you drop the box it says 1.2 twice! Top one works, bottom one fails... I have had a few 1.2xxxx versions but it doesent show detail ... Well now I know.

So. Testing shows that the serial data issue goes away at 3ms and so 10, and 20 is too slow? At 3 everything silky smooth. Higher its not. Lower inc zero its not either. So 3 it is!


Do we know if the compensation formula will work? And how do we set it? Same as before? Increase until too jerky and go back a bit? Is 100 a good start point or zero?

[ex-Gooserider]

There are several different LCD shields for the Arduino, so it is certainly possible, though I don't know if there is enough speed / processing ability to do much massaging on the data. Might be worth trying the "Leonardo" series as well, as that version has the ability for keyboard / mouse inputs. One of my fellow Asylum inmates is building / selling a variant known as a "Rascal" that as I understand it has a higher power controller and more I/O stuff while still being able to use Arduino compatible shields. Check out "sparkfun.com" for at least some of the options.

I haven't played with any of the Arduino stuff beyond the EasyVR shield that I'm using in the pedal pusher project, and my Arduino experience is definitely limited, but I can ask around if folks want, we have several experts at the Asylum.

I've also thought that BM might do better to get an Arduino and some really simple shields (like the motor controller shield) and work through some of the basic programming stuff for it. Much less steep of a learning curve as one can start with really simple stuff like turning an LED on and off, then working up through controlling stepper motors and reading a quadrature encoder, etc... The IDE is really simple and minimal, so there is less to cause errors. It is a different language (a C++ variant, rather than MicroBasic) but IMHO its a not a big deal to learn a new language if you understand the basic concepts of programming (and looking at the posted scripts there doesn't seem to be all that much difference)

My Arduino experience has been very basic, as this is my first real venture into a genuine programming language, and I've been picking it up pretty fast just by adding one little chunk of code at a time. Often I will even write a minimal sketch (aka program) that has just enough in it to make the feature I'm trying to add work - usually made by stripping down my main program, and then writing in the added feature. Once I get it working, I then copy the new bits over into the main program, and repeat...

ex-Gooserider

[malamar]

always thought of arduino as a new fancy ice cream brand, but mistaken i was, indeed.

[Burgerman]

I am confused. Why would an extra board help me/ When the roboteq does all this stuff on board?

and...

There are several different LCD shields

Whats a Shield?

[LROBBINS]

Hi All,

Rachi had surgery this morning so I've had only a few minutes to look at the forums. The surgery (removal of the C6-7 disc, placing of a spacer, a reinforcing plate and a cage) went well, Rachi was still pretty dopey when I left at 6PM, but Ellen said that she was more responsive toward 9PM. It will be a day or two before we know whether this, following replacement of her baclofen pump and catheter 3 weeks ago, will resolve the horrid problems she's had the last several months.

Just a few comments on the latest batch of postings.

John,

The reason to bring up Arduino is that it can add some useful functions that the Roboteq doesn't have - such as the ability to display information and to log operating/service/fault information to display or later download. For example, I've now written a very little subroutine that can track cumulative current draw for as long as the chair is on - actual Amp-Hrs used, but with just the Roboteq there's no way to either store or display that information; storage so that one can accumulate Amp-hours even if the chair has been turned off for some time between charges, display or it's useless information. An Arduino could retrieve the info, store it continuously in its memory even when the controller is turned off, retrieve it from memory and keep adding when the chair is again on, and display Amp-Hrs used on a small lcd screen. Same for any of the other Roboteq-generated information that you can see on your PC, a device impractical to use while driving.

Timing. So, taking out the PRINT statements removes a lot of delay (probably mostly from the Roboteq added wait after every 32 characters). I hope you commented out the PRINTs rather than physically deleting them. Comments cost nothing, they're not even in the compiled code downloaded into the controller. They can, however, be very useful later on if you want to modify or debug something.

You may also find that the program runs faster when the PC is not connected, and that the actual chair will respond smoothly with a longer wait than will the PC. Indeed, as that wait time give more processor resources to chair control rather than the script, there's probably some optimum length that balances chair-control and script needs. It may be something you want to fiddle with when you have it on the chair.

While Rachi was in the OR, I did works some more on the script. I have a SpeedPot subroutine and the one mentioned above for integrating current flow (though that was more for curiosity than for usefulness without some way to display it). I also cleaned up some of the code so it runs more smoothly (though the small difference probably will be unnoticeable), made the comments and some variable names more meaningful etc. After things calm down here, I send it along so everyone can take a look at it and tell me what more is wanted.

I also have a couple very small scripts for testing a couple things that can only be tested with a controller connected; to check out my use of the Get Input _TM (time) instruction (the table in the manual has an error, so it must be field tested), and another to help me find out how long different kinds of instructions take to execute; in particular a simple IF versus a series of multiplications. Again, optimizing code in this way probably won't make a real-world difference, but it's really no harder to write efficient code than to write bloat and this has to run well on a really micro, microprocessor. Again, I'll send them along when I find time to describe what needs to be tested.

Next, perhaps now that you know that the apparent "serial takeover" happens whenever a script is running, you may find that you actually can use a serial input device without a real conflict. It might be possible to put back Mode 2 and configure the driving inputs for serial as well.

Finally, a little dictionary of Arduino speak. Arduino was invented by a small group of (typically crazy) Italians who wanted to show graphic and performing artists, and even designers of alta moda, that it's really not hard to add computer-based automation to their art. One of the ways chosen to break through the culture barrier was to call Arduino programs not "scripts" but "sketches". Shield is another one, though it doesn't seem to me to have an art connection. These are circuit boards for add-on functions, there are now hundreds if not thousands of these, that directly plug in on top of an Arduino board; many can even stack one on top of the other. So you can add a board with multiple relays, or a board with MOSFETS to use the Arduino PCM ouputs for motor control, or to add screen output for text or graphics, or with a CAN interface. The way I built the accelerometer stability enhancer for Rachi's chair is as an Arduino screen. It has the accelerometer, a 4046 and some connections to mini phone plugs, and just stacks with matching headers on top of the Arduino. The Arduino programming language is a subset of C++ unlike Roboteq's subset of Basic, but it is a lot more complete. For example, it does have real number arithmetic, many different variable types - not just integer and TRUE FALSE, but things like character strings, and lot's of people have posted pieces of code on the Arduino forums for doing lots of things. Another is that you can send and receive serial data of any form and control serial flow, not just "characters" and variables. The software also arrives with numerous examples, many with good explanatory comments, to help one learn. I actually don't particularly like writing in C++, it has lots of abbreviated ways of saying things that professional programmers for some reason like, perhaps only because they have to type less, but that I find makes the programs hard to read. For example, instead of writing a = a + 1, in C++ one writes just a++, but you have to remember that ++a and a++ mean different things. The basics of programming are exactly the same, however: get data, store data, do arithmetic, branch and loop.

I wouldn't use an Arduino for primary chair control, nor would I want the Roboteq to be dependent on a properly functioning Arduino; it just doesn't have the safety engineering of a Roboteq. But for ancillary functions, such as a battery meter based on AmpHrs used, lighting, actuators etc., it could be handy. I'll try to describe one concrete example of useful data logging. The Roboteq can stop the chair (in a few different ways) if there's a brake fault, an output stage fault, a joystick fault and so on. If you look at its few lights when that happens, you might get some idea what faulted. If you logged the fault flags and the named variables of interest, and translated fault flags to human-readable text, you could hook up your PC or use your Arduino with a screen and know a lot more about what's broken. There are also faults that the Roboteq itself doesn't detect that could be monitored from a script: excess current in an current sensor chip with respect to drive commands -- maybe there's a short in the motor, no current even when the motor is told to go - it's probably an open, not a broken gear case, and so on.

Lastly, because the MotorCompensation is set as milliohms, your starting value should be something less than the actual milliohms of your motor+wiring and then make little adjustments from there just as on any other controller. The only thing that's on the latest Dynamic or P&G that you won't have is a way of measuring motor resistance using the controller, but if your cautious and start low, that's not a big deal. Keep your emergency cut off lanyard in hand in case the script, or your guess of milliohms, is screwed up and the chair takes off on its own.

Ex-Gooserider,
It will be interesting to see what your fellow hackers have to say. One thing somewhat off-putting about Arduino, for example for a display, is that the versions that mate with standard shields are rather large, about 2" x 3". That's small if it's tucked away inside the chair, so could be used that way as a data logger and extra auxilliary output device, but large if you want it in pod or small stand-alone information display. The brains could be in the chair, and the screen remote, but that means a multi-wire Arduino-to-screen cable instead of just a 2 wire serial connection. There are a number of smaller Arduino boards, but you'd probably have to design your own shields to use them.

OK, I've got to get some sleep. No energy left to preview and edit, so what I wrote is what you'll get.

Ciao,
Lenny

[Burgerman]

Thanks for the detailed explanation.

This may be of interest. About motor compensation and how its done. Just in case there are issues!

http://documentation.renesas.com/doc/pr ... 100_rx.pdf

[LROBBINS]

John, I realized when I awoke this AM that you said something about connecting your brakes to 1A 5V outputs. The Roboteq digital outputs are 1A each, but they are not 5V. They are MOSFETS that connect to 0V when on, you can whatever voltage you want to the other side of the attached device. Just be sure of two things: continuous current drain is <= 1A and that inductive devices have a transient protection diode across them. You need the diode even if you use an external relay. If the device draws more than 1A, you can use two digital outputs in parallel. Ciao, Lenny

Off to the hospital now.

[Burgerman]

I read all the roboteq manual, so understand this. Getting the diode the right way around is my biggest worry! Those things confuse me. And what size/type is best? Preferably small sinse I want them inside the connectors. How big will the pulse load be? .7 cont amps each @ 12v but maybe lots more initially?

I was going to use an ssr because it seemed kinder to roboteq. And didnt think that would need a diode?

Hadnt thought about using 2 outputs in parallel, (4 altogether maybe for 2 brakes?) but this may be easier still. Would that be reliable? Dont want to kill the roboteq.

I will use another ssr and another digital out, for starting up the small inverter (45 to 12v 10Amp) So two used at least, maybe another for lights. They are small/cheap and reliable.

[LROBBINS]

SSRs are cheap and reliable, but for inductive loads they still need transient protection. If you're nervous about hooking up a diode backwards (for this purpose you want cathode to + and anode to - so no current flows except for the "kickback") there are lots of bi-directional transient protection devices now available. Just look for them, for example, at RS. For actuators, you would need those anyway as they get connected both ways. Here's what Dynamic says to use to protect an external brake switch (the Dynamic PM already has enough transient protection if there's no external brake switch).
Manually operated Park Brake release switches can be fitted as shown below,
if appropriate to the application. A suitable suppression device must be fitted
across each magnetic Park Brake to prevent generation of high voltage
transients and possible damage to the PM or the Park Brake Release Switch.
Some suitable suppression devices are :
Manufacturer Motorola Philips
3EZ39D5 BZX70C36
3EZ36D5 BZX70C39
1N5365A BZT03C36
1N5366A BZT03C39
These are 39V 2W zeners with a 2ms 50W surge rating that they wire back to back (cathode to cathode in their diagram, but I don't think that this actually matters) so that together they make a bi-direction TPD and can't be put in backwards. That's from an old DX-PM manual. These days you can get cheap, already made up, bidirectional TPD so that's the route I'd go.

I think I'd also mount them at the brakes. Why have transient spikes traveling about if you don't need to - get rid of them as near the source as possible.
Ciao,
Lenny

[Burgerman]

So, you think the relay needs the protection. I thought you meant the roboteq needs a diode when conneted to the ssr? Does it?
Fair enough. I will do that. I expected that a ssr would have a diode built in!

So a couple of 15v zenners back to back will work in my case (12v not 24v pulse width feeds brakes)?

And I may just use the roboteq outputs directly for brakes. Since each is .7 amp, so 1.4 amp total load, so 4 parallel connected digital out will be adequate (4a max)???

[LROBBINS]

If the brakes are 12V, I'd wire them in series and power from 24V. The current draw will then be just 0.7V and you should be able to safely power them from just 1 Roboteq digital output (the manual says they are good for more than 1A, just how much more it doesn't say). If you want to wire each as 12V you will need a fairly hefty 12V source for them, and you can use 1 Roboteq pin for each.

You don't need transient protection on the input of an SSR - that's an extremely low-current, non-inductive load. You do need transient protection on the output side whether it be the Roboteq itself directly connected to an inductive load or an SSR connected to an inductive load. In AC applications, that isn't necessary with good SSRs as they are "zero crossing switches", they actually make/brake contact as the AC crosses 0. With DC there's no way around it - with inductive loads there will be a kickback and it can reach voltages higher than your battery voltage as well. Do take a look at RS and perhaps google for Transient Protection Device, or Transient Voltage Suppression to help you make a good choice: like using ICs instead of discrete components, by going with these you're letting someone in the know chose the right pieces, and one of these will cost just pennies more than a single diode and perhaps less than 2. There are a couple basically different designs, with different timing and transient dumping characteristics, but any with the right voltage/current ratings should do for us (STM has many models of both kinds).

Ciao,
Lenny

[Burgerman]

I have a choice. 12v (small inverter (10 amp max) for lights, and brakes, or battery voltage (47v charged, 45v in use) available. So will use 12v for brakes. No 24v battery you see...

But the roboteq cant switch (sink) 24v plus anyway. So will use the 5v, and sink that to operate ssr. Or use 12v directly switched via roboteq for brakes. Not decided which yet. Is it safe to switch brakes at 12v (1.4 amp) directly via roboteq? I think it is if 2 or more (4?) are used in parallel digital outputs on motor off configuration.

Anyway we will soon find out!

[LROBBINS]

No 24v battery you see...

Ah, duh, of course not. Spec. on the Roboteq digital outputs is 30V, but you're over that as well. I do think that 1 output per brake, at 0.7 Amps is OK, as long as Roboteq's rating is for continuous use, but you are right an SSR would certainly protect the expensive controller. Ciao, Lenny

[malamar]

Good work so far, Lenny, codicilli domine...ciao

[ex-Gooserider]

The way I remember diode connections is that if you look at a schematic symbol for a diode, you have an arrow with a line across the tip. If you think of the traditional direction of current flow (plus to minus) if the arrow is pointing With the flow, it goes through the diode. If the arrow is pointing against the flow, it is stopped by the bar (the old plumbing analogy has the diode as a one-way valve) When you go to translate the schematic to hardware, the line on one end of the physical diode corresponds to the bar on the schematic...

For reverse surge protection in our stuff, you don't need much in the way of current capacity, nor huge voltages, so you can use pretty much any kind of "signal diode" with probably the most common ones being the 1N4148 or 1N914 (If I recall the numbers correctly) - these are little small "glass bead" packages that you shouldn't have any problem adding in just about anywhere.

On the Arduino, a bit of explanation - The Arduino is technically what is known as a "development" or "prototype" board, based on certain Atmel micro-controller chips. It is a chip, with a bunch of additional "support electronics" to give it a convenient hardware interface, and an optional (relatively) easy to use software development environment. Part of the hardware interface is a bunch of header pins that are set up for analog and digital I/O ports, power, and a few other functions. These are designed with a standardized pinout and dimensioning. The original designers, and huge numbers of other people have designed accessory boards that plug into the headers, and give different functions depending on the design of the board. These addon boards are called shields, in part because they fit over and cover up the chips on the actual Arduino. This is a great system for "one-off" building, proto-typing stuff and the like, but if you want to make a "real" product, you probably will be better off to spin a custom PC board with just the parts that you actually NEED for your product on it....

As to why you might want to play with one - in addition to the stuff that Lenny mentioned about giving you added functions for monitoring, logging, and so on, I think there is a more basic reason... You have said that you don't understand programming, the program environments and such. Unlike the relatively complex and sophisticated Roboteq unit, that essentially assumes that you know what you are doing when trying to program it, the Arduino is also intended for use as a learning tool.

I'm willing to bet that you didn't start out from scratch building race engines and high performance equipment - you probably got to rebuild a few lawnmowers and mini-bike engines first, and worked your way up. The Arduino is sort of the programming equivalent of that old lawnmower, while the Robotech is more of a race engine... Getting an Arduino and learning some "lawnmower code" starting with really simple stuff like making an LED blink and working your way up would probably be easier than trying to figure out the Robotech all at once...

ex-Gooserider

[Burgerman]

The lawnmower analogy was correct! I built and tuned (!) a few. I even fitted a nitrous system to one 20 years later to find out for real what happens if its lean... You dont want to know the result!

But theory is one thing, actually doing it and looking at the results and finding out why is entirely another.

Yes I see the possibility. But not sure if time is on my side!

[LROBBINS]

We are home from the hospital, Rachi is doing well and I am fairly optimistic that this second surgery has actually resolved what has caused her increasing problems over the last 2+ years to the point that in the last few months she's been unable to do anything but twist and scream. We're already thinking about how to help her recoup from months and months of continuously contracted muscles, and, once the incisions are completely healed, I'll probably be going quite often with her to the terme (volcanic hot baths).

I partly agree, and partly disagree with Gooserider about the differences between Arduino and Roboteq programming. To my mind, programming the Roboteq is actually simpler because many functions are already in the Roboteq firmware that you'd have to write from scratch for the Arduino. You basically need only two Roboteq functions for most everything that's Roboteq specific -- GetValue and SetCommand. The thing that makes the Arduino easier for the novice is the large amount of learning materials compared to the unintelligible-to-the-non-programmer stuff in the Roboteq manual, a more flexible language that doesn't force you to futz with integer arithmetic (though doing as much as possible with integers rather than real numbers will make the program run faster and use less memory), and a far better program editor. Lack of line numbers, and compiler error messages that tell you that there's some character missing, but give you a list of 20 or 30 possibilities, just is NOT helpful.

Especially valuable with the Arduino is the large collection of examples, many with good explanations and ranging from very simple to fairly complex. These sample programs actually do something, rather than just being examples of the syntax of a particular structure (such as IF ... End IF) that give a newcomer no idea whatsoever of what you'd use it for. The simplest example, if I recall, just repeatedly turns an LED on and off, and there are many others that go progressively from there. Were it not the case that C++ and MicroBasic have such different syntax, the Arduino materials would be great for someone learning to program the Roboteq as well.

John, Yes, you want to get the new chair running. After all the gorgeous house fixing, I'm sure it seems to be taking too long to get it on the road. In the end, however, it will cost you much more time to get it running the way YOU want it to run if you don't spend a few hours learning a bit of programming. That is, hours just spent studying and writing little tiny scripts, not a minute here and a minute there trying to learn a piece here and a piece there. I really suspect that it would take you no more than 10 hours of concentrated attention to feel quite comfortable. Yes, you will make mistakes, we all do, but programming mistakes are easier to fix than mechanical/electrical ones and with the Roboteq I don't think they can cause any damage either. One of the nice things about a program is that a "fatal flaw" is only fatal to the program.

Ciao,
Lenny (who's off to take a nap)

[LROBBINS]

Here is yet another script "development 2012_09_12.mbs" re-labeled as *.zip.

There are two added subroutines:

SpeedPot which reads a potentiometer connected at Analog Input 5

and

IUsed which keeps track of the cumulative tenths of AmpHours used from when the script starts

There are also some other changes made to implement these, to speed calculations a bit and to make variable names clearer (I hope). The settings at the top of the script are:

Code: Select all

vSpeedPot = 90 'default if GoSub SpeedPot not used
vPotMin = 20 'speed at lowest pot setting
vSpeedPotLowFault = 10 'chair speed in % if pot fails giving too low voltage
vSpeedPotHighFault = 70 'chair speed in % if pot fails giving too high voltage
vReverseScaling = 60
vForwardTurnScaling = 80
vReverseTurnScaling = 40
vMotorResistance = 100


vSpeedPot takes the place of forward scaling, and each of the other scaling factors are now percentages of the speed pot value. Setting vSpeedPot to 90 before MainLoop gives a value to use in case you don't want to use a speed pot and comment out GoSub SpeedPot. Because there's a minimum power below which the chair won't move, and a speed below which you wouldn't want to move, there's vPotMin to set how a pot turned all the way down will be interpreted. I've made that 20% of maximum speed, but it could be any value you want.

The pot should be wired with a pair of resistors as shown on p. 45 of the Roboteq manual, BUT DO NOT SET ANY MIN/MAX ACTIONS. A SpeedPot is not a critical device and if it gets disconnected I don't think we want the chair to be un-driveable. We do, however, want to know that it's not working, and to put the chair speed in some safe range. The Roboteq doesn't have that option, so I've put it in the script. When configuring this input, set the minimum to 0 and the maximum to 5000 mV. The actual voltage swing will be from 0.2V to 4.8V. A disconnected wire or pot failure will give 0 volts or 5 volts and the script declares an input <21 (=0.1 V) as a Speed Pot Low fault and sets the speed to vSpeedPotLowFault, and any input >980 (= 4.9 V) sets speed to vSpeedPotHighFault. Anything from 21 to 50 will give vPotMin, and anything from 950 to 979 will give 100% to take care of aging or temperature shifting of the resistors & pot.

There's no need to read a speed pot every time the joystick is read. The lines:

Code: Select all

   IF vCycles MOD 10 = 0 THEN
      GoSub SpeedPot
   END IF

cause the pot to be read once every 10 times through MainLoop (about a bit more than once every 200 msec with Wait (20). If you end up with a substantially shorter Wait, increase the number after MOD.

You can test this, and tell me what you don't like, by either connecting a physical pot to analog input 5, or by entering values for AI 5 on the Roborun run page.

The AmpHour logging is something I can't test without a Roboteq, and I'm not even sure that you can test it with one. Testing it will depend on being able to see the result of the PRINT lines in the IUsed subroutine while running the controller. I don't know how one does this, or if it's possible -- would that be in the Console page? This is not really an adequate AmpHr meter, even if it works as intended. First, because the Roboteq doesn't give us any way to see the value without a PC. Second, it has no way to store the value; every time the Roboteq is shut off, it will start again at 0 AmpHrs. Sent by serial to an Arduino (or other micro computer) though, we could both save and see cumulative current draw, which we would reset to 0 whenever the chair is re-charged (the reset could also be automated in the second computer). The Roboteq manual is not clear about it's timing functions: it speaks of having several count-down timers, but I couldn't find the commands for these in the MicroBasic reference, and there's no description of the _TM command (except for an error in a table that shows it as having one parameter, when it actually has none). I just assumed that _TM returns the number of milliseconds from when the controller is turned on (because other micro processors have that kind of clock), but you'd have to see the PRINT line while using the Roboteq controller to see if I guessed right. So, if you can figure out how to see the PRINT output while running the controller, let me know if it works. I don't see any reason to update AmpHrs more frequently than about once a second, so that subroutine is called only once every 50 cycles of MainLoop. (Again, increase the 50 if you reduce Wait.) Once you've figured out how to test this, or figured out that you can't, feel free to comment out the GoSub IUsed line.

In case you're wondering what MOD means, this means divide x by y, discard the integer result, and tell us what the remainder is. So, 0 MOD 3 is 0 (because 0 is exactly divisible by any number), 1 MOD 3 is 1 (1/3 = 0.333 = 0 in integer arithmetic, and there's 1 left over), 2 MOD 3 is 2 and 3 MOD 3 is 0 (because 3 is exactly divisible by 3 with nothing left over) and so on.

If this explanation of the script is clear as mud, ask away and I'll try to extricate us.

Ciao,
Lenny

[Burgerman]

Thanks. I saved the post, and the script for future use. I read that about 5 times and some smoke actually came out.

Will concentrate on this when I have everything physical built and tested. Need to make sure compensation works properly first. As it is, I dont ever use slow speeds. My chair is set to MAX all day long. You get used to it...

But that may be too much with 45v and 15mph...

You need to get yourself a roboteq!

[LROBBINS]

I'm hoping that by the time I actually have a real use for one, they will have replaced its processor with something more capable, such as giving us a way to output and save values without a PC. Ciao, Lenny

[LROBBINS]

A question about motor compensation in the script was posted in another thread, but I'm copying it here to keep scripting stuff together a bit:

The question was:

The default 100 is motor impedance rather than a percentage or other arbitrary figure? So setting it to 0 or 1 is off?

It is milliohms, so 0 is indeed OFF. So, if your motors+wiring are 60 milliohm, a setting of 50 to 55 should be about right, but I'd start a bit lower. If you end up wanting very small values, it would be better to change the script to tenths of milliohms so that you could get a finer division.

As written, however, this requires external current sensors hooked to analog inputs 3 and 4. If you want to try it using the internal motor current estimates, I could add that option, probably putting a bUseCurrentSensors (TRUE or FALSE) at the top. TRUE would be "use physical current sensors hooked to analog inputs", FALSE would be "use motor current estimates". I'd have to check the manual to see how motor current is scaled to do the arithmetic right. For external sensors, I have it as 1000 on the inputs = 100 amps.

Ciao,
Lenny

[Burgerman]

I need external sensors? I thought it WAS using internal info. Can we rewrite it so it does so I can test it?

What external sensors would I use? Loop of wire? Hall effect?

[woodygb]

http://www.devicecraft.com/haefcuseam.html

[Burgerman]

Fast!

I would prefer though to keep all external wires and sensors to a minimum. So the roboteqs own figures may be better?