PINNED - Roboteq Controller - developing for powerchairs

Power wheelchair board for REAL info!

POWERCHAIR MENU! www.wheelchairdriver.com/powerchair-stuff.htm

PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 03 Sep 2012, 19:24

The conversation in the Emergency Shutdown thread http://www.wheelchairdriver.com/board/viewtopic.php?f=2&t=2432 set me to reading the Roboteq user manual and I noticed a few things that I'll have to somehow deal with if I should decide to build a chair for Rachele using this.

(1) I think that one can come up with a reasonable emergency cutout relay setup, but, as Roboteq points out, one should also monitor for fused contacts. I don't think that open contacts are a problem; the chair just won't go. Fused contacts, however, would mean driving with no protection. So, what we have to do is check this before allowing driving. A script could trip the cutoff and set the motors to stop at startup, then we could use a digital input to check for voltage on the output of the relay, and if there is none then allow the relay to close and take the motors out of stop mode. Some programming needed, but should be doable.

(2) The Roboteq has 8 digital outputs, but they are all unidirectonal (open collector) mosfets. The connected device has to be connected to 24V at one end and to a digital out pin at the other - that pin goes to 0V when active. Three are needed for brakes and the emergency relay, leaving 5. Because they are unidirectional, driving an actuator (for tilt or lift) means using two (one for linac in, and one for out) and some external relays to reverse direction. With both tilt and lift on Rachi's chair, that means only one pin is left for lights - not enough. For those who can use external switches for tilt and lift, that's not a problem. Rachi, however, has to be able to do this through her switch-operated joystick emulator: she has a mode switch to cycle among drive (3 profiles), lift, tilt and lights (several modes) and then controls them with her left and right head switches. At first blush, it looks like I'd have to add a separate microcontroller (perhaps another Arduino) for this. Getting a little complicated and perhaps not so safe, but I think safe enough if just the lights are on the separate controller. Use the last Roboteq out pin to enable the external board (and shut off every other Roboteq output) when mode reaches "lights", and use my extra multiplexed switch interface outputs to control the lighting board.

(3) Motor Compensation. John has pointed out that the Roboteq now has a Torque Mode that uses internal motor current sensing. Unfortunately, it works exactly opposite to motor compensation. In Torque Mode, the system will attempt to make motor current constant. Thus, if we come to an obstacle that loads the motor causing a current increase, the controller output will be REDUCED to keep current (and torque) constant. What we want to happen is that a current increase caused by an obstacle should INCREASE duty cycle (and current = torque) to keep speed constant; this is positive feedback. That positive feedback is why setting too much motor compensation can lead to a runaway condition. I think that one could get the Roboteq to mimic motor compensation by adding an external current sensor to each motor (with the polarity reversed so feedback is positive) and using one of the other closed-loop algorithms. The problem I see would be finding the right sensor scaling, and PID settings to get enough, but not too much compensation. A lot of parameters, rather than just one motor resistance, to fiddle with. I also wonder whether the weighting (i.e. P of PID) wouldn't have to be different for small and large stick displacements, but I think that this would take a lot of experimentation to find out. If needed, that too could be scripted: read joystick value (after interpretation by the mixer, response curve etc.) and change the PID values on the fly. Doable, but not a simple task. It would be better if Roboteq came up with a motor compensation algorithm!

Standard WC controllers are outrageously expensive and have limited current and voltage properties, but the safety engineering has already been done and there are modules available for most any user's control limitations. The Roboteq looks great, and John will probably get us a real-world proof-of-safety, but getting it to work for my user with a complex motor disorder will not be very easy at all.

Now that I've read the manual with some care, I'll leave these thoughts percolate in my mind, and in yours, and see if reasonable solutions eventually pop out.

Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 04 Sep 2012, 02:06

I think you need only 1 output for brake. Why 3?

Leaving more for other stuff.

Since it monitors motor current already, and loads of other stuff, the bit of code needed for compensation can run as a script?

Or use motor feedback encoder. (closed loop) / servo.

But from my limited testing in the street, at 45 volts, compensation isnt really required. Felt very torquey and responsive as it was. Compensation is only really needed where you want full torque, at small joystick values on high impedance motors, or at low voltages.

Wont go over a threshold? Use more stick. But remember that say the Groove motors take 240 amps at 45v stalled. (and likely melt!) So limeted to 120/150 in programming. So will take 120 amps at a 50 percent (just half stick). That means you get progressive torque up to 120 amps at half stick, and then up to 150 amps just past half stick. And the rest of the stick doesent help, as the roboteq will hold it to 150 max, or whatever you program in. So it has the same affect as compensation without the instability.

And.
(1) I think that one can come up with a reasonable emergency cutout relay setup, but, as Roboteq points out, one should also monitor for fused contacts. I don't think that open contacts are a problem; the chair just won't go. Fused contacts, however, would mean driving with no protection. So, what we have to do is check this before allowing driving. A script could trip the cutoff and set the motors to stop at startup, then we could use a digital input to check for voltage on the output of the relay, and if there is none then allow the relay to close and take the motors out of stop mode. Some programming needed, but should be doable.


Solid state relay?
Plus its unlikely that relay contacts fuse. I used many of them on industrial kilns years ago. They do everything but fuse. Usually ending in smoke or big bangs...
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 04 Sep 2012, 02:19

Why 2 outputs for brakes (default Roboteq setting)? Each digital output is 1A max. 2 brakes in parallel is pushing it.

Just move the stick a bit? No stick for Rachi - head switch array and very low throttle settings indoors.

Use the internal current measure? Internal measure is inaccurate at low throttle, and Rachi drives at very low throttle, e.g. indoors 7% of maximum speed.

Relay contacts don't fuse, SSRs don't fail closed? Then why does Roboteq recommend independent monitoring for this, and why does Dynamic provide it? A failure of the digital out pin to which the relay is wired would give a "stuck closed" state too - and that was the failure on the Dynamic PM that I just replaced - relay OK, but the computer was telling it to close.

I did, however, realize that two actuators can be controlled with 3, rather than 4, outputs - Actuator 1 enable, Actuator 2 enable, and Reverse to trigger DPDT relays for both.

Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 04 Sep 2012, 02:35

Why 2 outputs for brakes (default Roboteq setting)? Each digital output is 1A max. 2 brakes in parallel is pushing it.


I plan on using a small cheap solid state relay. So almost no load on roboteq, and all controlled via its built in 5v supply.

Just move the stick a bit? No stick for Rachi - head switch array and very low throttle settings indoors.


Then either a simple compensation script (runs automatically at switch on) and woody already wrote it! I think it was him... Or use a motor with encoder for closed loop super accuraccy. It does this easily, and the Groove motors can be ordered for EG with encoder built in ready to go.

Use the internal current measure? Internal measure is inaccurate at low throttle, and Rachi drives at very low throttle, e.g. indoors 7% of maximum speed.


Why do you think this? It seems super accurate on the graphs, 1 percent is easy to see. And even radio control input has greater than 2048 resolution. 7 percent is huge. And may result in 30 or so percent percent motor current depending on impedance, battery voltage, flyback effect..

Relay contacts don't fuse, SSRs don't fail closed? Then why does Roboteq recommend independent monitoring for this, and why does Dynamic provide it? A failure of the digital out pin to which the relay is wired would give a "stuck closed" state too - and that was the failure on the Dynamic PM that I just replaced - relay OK, but the computer was telling it to close.


They do but its statistically very unlikely for 2 seperate solid state systems to fail shorted. Normally they fail open. But its another safeguard, so the Roboteq would have to fail shorted as well as the safety device at the same time. Its possible I agree, but its not very likely.

I did, however, realize that two actuators can be controlled with 3, rather than 4, outputs - Actuator 1 enable, Actuator 2 enable, and Reverse to trigger DPDT relays for both.

Ciao,
Lenny
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby JoeC » 04 Sep 2012, 05:35

Burgerman wrote:
Use the internal current measure? Internal measure is inaccurate at low throttle, and Rachi drives at very low throttle, e.g. indoors 7% of maximum speed.


Why do you think this? It seems super accurate on the graphs, 1 percent is easy to see. And even radio control input has greater than 2048 resolution. 7 percent is huge. And may result in 30 or so percent percent motor current depending on impedance, battery voltage, flyback effect..



The way I read the manual I saw it the same way- without an external current sensor the accuracy of current estimation is poor for low throttle values. See page 106 here: http://www.roboteq.com/files_n_images/f ... serman.pdf

The torque mode uses the Motor Amps and not the Battery Amps. See “Battery Current
vs. Motor Current” on page 26. In all Roboteq controllers except the Separate Excitation
models, Battery Amps is measured and Motor Amps is estimated. The estimation is fairly
accurate at power level of 20% and higher. Its accuracy drops below 20% of PWM output
and no motor current is measured at all when the power output level is 0%, even though
current may be flowing in the motor, as it would be the case if the motor is pushed. The
torque mode will therefore not operate with good precision at low power output levels.
Furthermore the resolution of the amps capture is limited to around 0.5% of the full range.
On high current controller models, for example, amps are measured with 500mA increments.

If the amps limit is set to 100A, this means the torque will be adjustable with a
0.5% resolution. If on the same large controller the amps limit is changed to 10A, the
torque will be adjustable with the same 500mA granularity which will result in 5% resolution.
For best results use an amps limit that is at least 50% than the controller's max rating.


I'm not sure if the best way to achieve truly fine control will be through an external current sensor or use of an encoder, but I suspect that one of these will be required for any high performance brushed motor powerchair.
JoeC
 
Posts: 2359
Joined: 13 Jan 2010, 18:54

Re: Some thinking and questions about Roboteq

Postby Burgerman » 04 Sep 2012, 09:09

So the motor amps I see on the graphs seem very precise. But are calculated from battery amps/pulsewidth. I didnt realise that. Or read that paragraph.

But for the sake of motor compensation via an algorythm that may still work fine? And 500ma granularity shouldnt be a problem?

I dont really like closed loop systems. Having tried this on standard mobility equipment. SOME feedback, via having to use a bit more power via the stick, helps you control the chair and know how hard the motors are pushing. This doesent seem importand until you try it. It makes accurate control impossible and you can flip out on curbs etc way too easily.

With zero compensation, the roboteq doesent seem much different to say my pilot plus system. So not sure how important this will be. But maybe thats because I am using about double the volts. So get much torque at half stick.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby malamar » 04 Sep 2012, 10:35

This post has so far beaten my record mark: not understood one single word; must be the winter an the falling leaves approaching fast!! :shock: :)
malamar
 
Posts: 495
Joined: 31 Jul 2011, 10:24
Location: Madrid Spain

Re: Some thinking and questions about Roboteq

Postby Burgerman » 04 Sep 2012, 12:37

Malamar, especially for you.

A mobility controller is, just like the roboteq, completely propotional. That is (once all the delays and other crap has been programmed out) if you give it:

a. No stick (central, no throttle) you get 0v to the motor(s). So dont move.
b. Half stick, you get 12v to the motor and about half torque.
c. Full stick, you get 24v to the motor.

This means that if you want to move slowly over say a 1 inch high door threshold, and give it 1/4 stick, you only get 6v to the 24v motors. So dont have enough torque to actually move. Not enough power. Mobility controllers "fix" this, by sensing that you have high(ish) current, and are not accelerating. They use a bit of fancy programming called compensation, that helps you out. It adds more "stick" or power for you. Automatically. So you move even when you are only using 25 percent throttle. But dont go faster than 25 percent speed. It makes weak motors feel powerful.

Now because the roboteq has no compensation algo to help you, this is what will happen. You try 25 percent power and dont climb the door threshold. You dont move. So you add more power. Then obviously you will move! But you may have 75 percent power or nearly full stick by then, and so speed off into the house!

Now with sensible reactions, and no delays or other control "damping" (acc/dec settings) its no problem, you naturally compensate by yourself. And with very low impedance motors, or higher voltages, this isnt a problem anyway. Because really motor compensation is only compensating for weak motors.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 04 Sep 2012, 14:00

For those who haven't yet downloaded the Roboteq manual, here's the quote about internal current measurement:
The torque mode uses the Motor Amps and not the Battery Amps. See “Battery Current
vs. Motor Current” on page 26. In all Roboteq controllers except the Separate Excitation
models, Battery Amps is measured and Motor Amps is estimated. The estimation is fairly
accurate at power level of 20% and higher. Its accuracy drops below 20% of PWM output
and no motor current is measured at all when the power output level is 0%, even though
current may be flowing in the motor, as it would be the case if the motor is pushed. The
torque mode will therefore not operate with good precision at low power output levels.
Furthermore the resolution of the amps capture is limited to around 0.5% of the full range.
On high current controller models, for example, amps are measured with 500mA increments.
If the amps limit is set to 100A, this means the torque will be adjustable with a
0.5% resolution. If on the same large controller the amps limit is changed to 10A, the
torque will be adjustable with the same 500mA granularity which will result in 5% resolution.
For best results use an amps limit that is at least 50% than the controller's max rating(emphasis added)
Given that Rachi needs the motor comp at very low currents, e.g. 7% of 60 Amp, I think the external current sensors at ca. Euro4 each are reasonable, it also means one doesn't have to program a reverse response to the Roboteq's current measurement to get positive feedback, just have to turn the sensor around and then use the PID settings. It may be the case that, after the first time someone does this, only P would need to be changed for different motors - it's a proportionately factor that should be much like the one calculated from motor resistance on mobility controllers.

I don't myself like the feel of true closed-loop systems either and have been well-satisfied with how well motor compensation works (once I put in strong enough motors). For Rachi, driving with switches closed-loop might be OK, but I'd rather have a good motor comp algorithm.

They do but its statistically very unlikely for 2 separate solid state systems to fail shorted. Normally they fail open. But its another safeguard, so the Roboteq would have to fail shorted as well as the safety device at the same time. Its possible I agree, but its not very likely.

Agreed, one needs two failures - the Roboteq output has go on when joystick calls for 0 (not necessarily shorted; it's any output when demand is 0 that should trigger the cut-out relay), and the cut-out relay (which might be an electro-mechanical rather than SSR) would have to be fused (or the digital out mosfet itself leaky or shorted). I don't know how likely this is, but a self test on start up seems like a reasonable thing to do if it's as simple as I think it is.

Yes, a relay for the brakes would free up another digital out, so with 1 for brake, 3 for two actuators, and 1 for emergency cut-out, there are 3 left for lights which should be enough if a little downstream logic is applied if one wants lights on, four-way flashers (very useful driving in the street in Firenze traffic at night where the sidewalks are unusable), and perhaps (but I don't think really very useful, turn signals).

So, it looks like everything that I'd need for functionality and peace of mind should be possible at reasonable cost (especially if one can get a hold of an SSR that can break the 500A of a full run-away state).

Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 04 Sep 2012, 18:12

If not, I think those things work ok in parallel. In any case, the roboteq battery input is FOUR cables. One set for each motor. Although linked internally. And I doubt you will need 500 amps because at 24 volts you will only see around half that with a set of good 8mph motors both at max pulsewidth and peak speed/amp draw. So not really an issue. I am looking into it now for mine. But I have an additional complication, 47.6 volts fully charged. 45v most of the day.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 15:20

Having time on my hands, I've continued to read: some details of the Roboteq manual, some stuff about IR motor compensation, and posts here about scripting for different speeds in forward/reverse and for motor compensation. The more I read, the easier it seems to get a Roboteq set up for Rachi's control needs and for a very high level of safety. For example, Woody's suggestions for implementing Motor Compensation seem on the mark and that there is no need for PID fiddling of the current feedback. Moreover, if using external current sensors for this, they can also provide another level of protection. If current=0 when command <> 0, that says that there is a motor (or current sensor) fault. If abs(motor current) exceeds some programmed limit greater than maximum reasonable motor current, there's a runaway fault (there's already a configurable excess current trigger in the Roboteq, so this last adds suspenders to the belt). In either case, those faults, as well as the built in check for motor current present when command is 0, could trigger a shut down.

One thing that I think has to be figured out, either by getting an answer from Roboteq or by some experimenting, is where the mixer routine fits in the calculation flow between joystick input and motor command. Or to put it another way, is the mixer calculation before or after _CIA (internal analog command value) or _CIP (for pulse) or _CIS (for serial)? The description for these commands in the manual is:
CIA - Read Internal Analog Command
Returns the motor command value that is computed from the Analog inputs whether or
not the command is actually applied to the motor. This query can be used, for example, to
read the command joystick from within a MicroBasic script or from an external microcomputer,
even though the controller may be currently responding to RS232 or Pulse command
because of a higher priority setting. The returned value is the raw Analog input value with
all the adjustments performed to convert it to a command (Min/Max/Center/Deadband/Linearity).
Syntax: ?CIA
Reply: CIA=nn
Where: nn = command value in +/-1000 range
The first sentence implies that "mixer" is applied BEFORE setting CIA's value, but the last sentence doesn't include "mixer" in the list of "adjustments". If "mixer" is applied before getting CIA, then adjusting forward/reverse speeds and adding motor compensation is simple. If "mixer" is applied after CIA is calculated, we have a bit more of a problem because we will have to do our own mixing (instead of using Roboteq's) before modifying the result of that to get the values to be sent to the motors. John, with mixing specified is it possible to watch the two Analog Command (or pulse, or serial) values with the GUI Roboteq software as you move the joystick? Do they follow just one or the other joystick axis or do they follow what you expect the motor to be doing? In other words, if you push the stick forward, do both channel's CIA increase (mixing before calculation of CIA) or does only one (mixing after calculation of CIA)?
Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby woodygb » 05 Sep 2012, 16:18

User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 17:00

Woody,
Does this mean that great minds really do think alike? These were among this morning's reading matter.
Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby woodygb » 05 Sep 2012, 17:11

LOL ... :geek: :geek:
User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby Burgerman » 05 Sep 2012, 17:18

With RC input (not used analog yet) I think, err, I am not sure! Will test it leter today and find out.

I think you see a post tank mix, and a channel input value, and an output motor value, as well as output current... and battery current, and a mass of other stuff.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 17:44

John,
Great. It doesn't matter which input mode you're using; each has it's own variable name, but they are computed at the same point in the process so what you see with RC as far as where mixing gets calculated will be the same as what you'd get for analog or serial. Ciao, Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 05 Sep 2012, 17:58

From what I can remember it all gets done first. The throws and end points are set, and the neutral points, fail safe points, etc on the inputs. Then the other options, such as digital in/out and which input priority, RC/ANALOG/SERIAL/If the scripting runs automatically, type of mixing, Result of over/under volts/same with output amps etc.

Not sure how looking at graphs will tell us anything? What am I looking for?

I can see seperate input signals, and the effect of the control stick either directly, or mixed, or the ramp times etc on screen as an input or an output to motor.

Then if motors are connected also motor amps, and lots of other stuff...
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 20:30

John,

All you're looking for is to see whether, in mixing mode, when you push the stick straight forward CIP (pulse command, however that's shown in the GUI) goes up for both channels or only for one. Both motor signals will rise in mixing mode, but do both commands do so as well?

Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 05 Sep 2012, 21:08

It displays either.

It shows either each stick move independently, and the result after mixing and setting the end points ...
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby Burgerman » 05 Sep 2012, 21:52

After firmware update, refitting a RC RX, and configuring that, redoing every setting, end point and fail safe (firmware update wiped it all) I can tell you...

Drum roll__________________

It shown the MIXED inputs. So if you add say delay, or speed limits in reverse, or turn rate, it shows the stick movements in 100 percent real time, and full movement MIXED. And also the output power OUT so you can see what is happening, so you can see what its going to do...

Is this good or bad?
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 22:55

This is great. It means that you can script adjust turn rates or speed or apply motor compensation on the already mixed commands and don't have to write your own mixer routines. Now I have to think about how I would script joystick vs. switch input and an easy switchover between attendant joystick and Rachi's switch controls.

I'm thinking along these lines. Use a PWM joystick and do switch driving by selecting voltage dividers for left, right, forward and reverse. A simple spst switch connected to 1 digital input could switch between the joystick and analog inputs, or perhaps it could just disable joystick PWM output with Roboteq's input priority making the actual switch to analog input. (Careful here, this means that a joystick failure would automatically put the chair into switch-driving mode which might not be very safe.) The mode switch (and/or speed pot, but if not using CAM I'd rather avoid the speed pot and long analog leads) would be read by the script to scale the commands to different values before sending them to the motors. Some kind of display will be needed to see what mode it's in, including actuator and lighting modes - probably an Arduino and lcd screen for this.

I have to think about whether I want the PWM and voltage dividers connected to the same or different pins and have the script switch between input modes, but I'll probably use several analog inputs for the different dividers. That is, different analog input pins for six voltage dividers (forward 2.5V, forward 4V, reverse 1V, turn 2.5V, turn 4V, and turn 1V). Then four digital switch inputs could tell the script which of these analog inputs to use. I could use just one pair of analog input pins (instead of 6), but that would mean more external components to select the voltage dividers connected to them. I think that the Roboteq has enough pins to let me do a lot internally, but I'll have to think hard about configuring them as most can be set for different input/output functions and one has to avoid conflicts. If necessary, I'll go to my old standby 4066 switches and do some of the logic externally. An added though just popped in: default (no switch closed) would be 2.5V speed and 2.5V turn. These could share the same pins as the PWM joystick using the ACU/switch array selector to disable just joystick output and let Roboteq priority do the rest. Then only 4 analog inputs are needed for the voltages above and below this.

Obviously, getting the logic for all this is going to be an iterative process with a lot of thinking out loud. Hope you guys don't mind my doing at least some of that thinking out loud here so that you can sometimes say "Whoa, that's a BAD thought".

Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby JoeC » 05 Sep 2012, 23:16

Don't mind at all! I'll try to keep up.
JoeC
 
Posts: 2359
Joined: 13 Jan 2010, 18:54

Re: Some thinking and questions about Roboteq

Postby Burgerman » 05 Sep 2012, 23:25

Some time ago before we got mixed up doing my house up, we were disgusing roboteqs inputs and scripting.

I cannot do scripts! So am lost. Here is the problem. I want to use RC mode, use it daily on all chairs. So THAT input is already used. Or I would simply order a pulse width or frequency 2 axis joystick. Why? Because the Pulse Width / frequency or Duty Cycle input is configurable on its for "throw" or limits by choosing end points that are far beyond the RC systems (for eg) 1100 1500 1900 (reverse/centre/forwards) points. So for EG on throttle input, if you want 50 percent reverse, you would just choose 550 1500 1900. Thats great!

On Analog things are not so easy. You can choose say to automatically calibrate easily enough. Actual joystick swing may be 4.5v and if the system sees 5v it stops safely. And will not start up if no centre point is seen. So safe. But how do you set say a 50 percent reverse speed? You could do it with resistors, but this loses resolution. And the reduced swing is more prone to induced voltages, noise and movement. Better to script it.

Or since there are 4 pulse inputs could I use pulse joystick AND RC inputs both together? What will it do? May test this simply by adding 4 channels!

So we arrived at this: UNTESTED so far:


________________________________________________________

top:

throttle = getvalue(_CIA, 1) ' Read the Analog command before it it
applied to the motor
steering = getvalue(_CIA, 2) ' Same for second

if throttle < 0 then throttle = (throttle * 70) / 100 ' Make negative
power 70% of input. Use ((n * 100) / 70) instead of n * 0.7
steering = (steering * 65) / 100 ' make steering 65% of input

setcommand (_G, 1, throttle) ' apply new throttle value
setcommand (_G, 2, steering) ' apply new steering

wait (10)
goto top ' repeat every 10ms

______________________________________________________________

change the * 100)/70 to * 70)/100. Same for the 65%

NOW:

_______________________________________________________________

top:

throttle = getvalue(_CIA, 1) ' Read the Analog command before it is applied to the motor
steering = getvalue(_CIA, 2) ' Same for second

if throttle < 0 then throttle = (throttle * 70) / 100 ' Make negative power 70% of input. Use ((n * 70) / 100) instead of n * 0.7
if steering = (steering * 65) / 100 ' make steering 65% of input

setcommand (_G, 1, throttle) ' apply new throttle value
setcommand (_G, 2, steering) ' apply new steering

wait (10)
goto top ' repeat every 10ms

_________________________________________

Does anyone know if this is correct? Will it work, Do I add the "top:" part? No clue here!!!

Burgerman

Need black and white help.. Plus, can I test this on the RC inputs? If so can I use it on both? How would the script look. Of course the roboteq can run the script automatically, or via some switch point, or input, etc.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby LROBBINS » 05 Sep 2012, 23:59

John,
It's mostly correct. The only obvious thing I see, but I'd have to check their microBasic syntax, is that you probably need some ENDIF statements or you'll get "unexpected end of program" errors. You do indeed need to loop back to the top so that the direction will be checked and the scaling applied repeatedly. You also have to get the integer arithmetic correct: 0.7 is 70/100 not 100/70. Lastly, you may want each IF to also have an else that sends the unmodified command through to the motor - otherwise I think it will continue to just run at its last (scaled) command value. If the Roboteq doesn't know to send the unmodified commands to the motors when they don't get modified, once you start going backwards you may not ever again be able to go forwards. Whatever you do, don't run a script until you've tried it thoroughly in simulation mode, and don't set it to AUTORUN until you've thoroughly tested it - you could end up with a situation where the only way to backtrack is to shut off the chair and re-load the firmware (to get rid of the autorun).

This microBasic seems to me to be a lot simpler than a lot of the things you've taught yourself to do. I am pretty sure that if you spent a couple hours with that section of the manual, and looked through some of the examples that ship with the software, that you'll be able to figure it out. A few more hours and you'll be a pro. Why not first write something simple that doesn't have to do with the chair at all. Create a variable and set its value to 1. Write an IF structure that says "IF that variable = 1" do something (such as just printing "variable=1) ELSE do something else (such as printing "variable is NOT 1") ENDIF. Compile and run this. Because the IF statement is satisfied you should get the first action. Now just change the value of the variable to something else and run it again - you should get the other action. Or start even simpler, just a series of lines that print first one thing then another (with some wait in between each so that you have time to see the result on your PC).

Every programming language has its own rules of syntax, but they are really all very similar and combine the same kinds of elements. Several kinds of variables and arithmetic operations; in the case of microBasic just integer variables and integer arithmetic (which can be a pita because you have to do a lot of multiplying and dividing in the right order so that none of your results can be between 0 and 1). One or several kinds of LOOP logic that let you repeat an action. One or more kinds of conditional statements such as IF or SWITCH that let you ask whether something is true or not. One or more kinds of branching operations, such as GoTo or GoSub that let you use different pieces of the program in different situations. But really, John, that's almost all there is to it. (Believe me, it was a LOT harder when the only way to write a program was to specify every memory address, every bit of information to move in and out of registers, and every action to be taken on them. That's why programming languages like Fortran, Basic, Pascal, C and so on were invented. Everyone has his favorite, and can be vitriolic in extolling or damning one or another, but they're really all very much alike. Search the web or a bookstore for a xxx (any language) for Dummies book if you need more explanation than offered by the Roboteq manual, read the chapters on the essential elements and skip the fancy stuff as microBasic doesn't have that anyway.)
Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: Some thinking and questions about Roboteq

Postby Burgerman » 06 Sep 2012, 08:26

I read all that, and didnt understand any of it!

Me and programming dont go together at all. :oops:

Resistors it may have to be.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: Some thinking and questions about Roboteq

Postby woodygb » 06 Sep 2012, 08:48

Lenny ..I think that you should re evaluate the formula ((n * 70) / 100) which is a percentage of the input throttle value n ... throttle output n = (throttle input n * 70) / 100 ......or 70% /0.7 of the original value.
User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby woodygb » 06 Sep 2012, 09:04

Maybe I need to ...rethink /re-evaluate...back after a ponder... and a look at the Roboteq syntax!
User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby woodygb » 06 Sep 2012, 09:18

Throttle values are in the range 0 - 1000 ...and equal n in the formula.

IF the input value was 1000 ..or top speed ..and we only wanted 70% .... then the suggested Cosmo formula of.. ( n * required percentage output ) / 100 ..seems to be fine.

Required Throttle OUTPUT ( 70% OF INPUT VALUE ) = ( Throttle INPUT of 1000 * 70) /100 = 700

YES?
User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby woodygb » 06 Sep 2012, 09:40

I'm not 100% sure on the position of the Endif ...this is the command to stop the script from continually checking the previously called IF commands ..if it's not present the script will continue to loop thru IF..IF..IF..IF..etc.
The following seems correct.... you'll need to indent what I've posted.

throttle = getvalue(_CIA, 1) ' Read the Analog command before it is applied to the motor
steering = getvalue(_CIA, 2) ' Same for second

if throttle < 0 then throttle = (throttle * 70) / 100 ' Make negative power 70% of input. Use ((n * 70) / 100) instead of n * 0.7
if steering = (steering * 65) / 100 ' make steering 65% of input
Endif
setcommand (_G, 1, throttle) ' apply new throttle value
setcommand (_G, 2, steering) ' apply new steering

wait (10)
goto top ' repeat every 10ms
User avatar
woodygb
 
Posts: 7068
Joined: 12 Mar 2011, 18:45
Location: Bedford UK

Re: Some thinking and questions about Roboteq

Postby Burgerman » 06 Sep 2012, 09:54

So for a dummy.

1. What would be the full code - end to end - I would send to the roboteq to run? After / before a seperator ___________ (to make it totally clear for a simpleton).

2. And can I change it, so that it works on the pulse inputs? To test??? How?

3. What EXACT changes do I make to change turn rate, or reverse speed to fine tune?

I suspect on a 15mph chair I will want about 20/25 percent for turn, or my legs may fall off, and 25/30 percent on reverse to get in the ball park as this will be about 3mph... But I need to know the answer very clearly, to these three questions! If anyone can help! Code/scripts are way beyond me!

Thanks!
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Next

Return to Everything Powerchair

Who is online

Users browsing this forum: Gregg and 29 guests

 

  eXTReMe Tracker