PINNED - Roboteq Controller - developing for powerchairs

Power wheelchair board for REAL info!

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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 01 Sep 2018, 19:18

Hi Eugene,

Though I've been thinking on and off about the smoothing code you posted it took me a while to get my head around it and I've been very busy so this is the first chance I have to tell you my take.

I LIKE IT, though of course I have some changes to suggest. I haven't done any "real world" testing, so there may also be some unintended consequences yet to be discovered.

First, lets see graphically what it does. The following was generated by a spreadsheet, not a Roboteq, and just shows what happens when the stick is held full forward with SpeedPotMin = 20.
Eugenes smoothing.jpg

The green line shows what Throttle does if pushed forward moderately quickly without any smoothing - it would be quite a bit steeper if one slams the stick forward. The yellow line shows how your algorithm adjusts the Throttle value that actually goes to the motors. The blue line shows the effect of moving-average damping (and I'll get to that later).

At speed below SpeedPotMin (20% of 1000) the yellow line overlays the green, but after 200 it is much shallower, but always above the speed line. This has two effects, both beneficial. First, brief changes in stick position will have a much more damped response than without this routine. Suppose you had reached speed = 600 and the stick jiggled back to 550. Without the damping Throttle would go from 1000 to 550 very quickly. But, with the damping routine, at speed = 500, the adjusted throttle is 680 (rather than 1000), and the change toward 550 will not only start from a less extreme value, but will take more time because it's following a shallower slope. Second, although there is substantial damping with the adjusted throttle value always > speed, the chair's acceleration is determined by the accel/decel parameters and the smoothing doesn't introduce any sluggishness. We get tremor or bump damping without any loss of responsiveness.

The amount of damping is not user adjustable, however - it's determined by the PotMin and PotMax values and the division by 20 in the line
Code: Select all
TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

The values you've chosen seem good to you, but I don't know whether they'll work for all chairs and all users.

There's also no damping if you just release the stick to center. Then, Throttle = 0 and adjusted Throttle = 0 despite the other calculations. This probably isn't a serious limitation though because with hand off the stick you can't be jiggling it anyway.

Compare this to what happens with moving-average damping (blue line). With this, the slope of the Throttle line with the stick held steady at 1000 is just as steep as when there's no damping, except at the start and end of the acceleration. There, the slope is curved, but much shallower than the unmodified joystick value. Damping happens whenever the stick is moved, not when it's held steady, but the same S curve will be generated if the stick is moved at any speed - under 200, in the middle, at the top. It's easy to adjust the amount of damping - - average more cycles and you get more damping. But that's also exposes the worst "feature" of moving-average damping. If the number of cycles is too high, the damped change of throttle is slower than what accel/decel would do to speed and the chair gets sluggish. This was most obvious if I just released or centered the stick - deceleration got delayed, yuck.

So, I like what you've done so much that I'd like to put it in my system, test it out on the bench with dummy loads, and then in the chair. I have to solve a couple problems, one minor, one more interesting, in order to do this. The minor problem is that with a brushed controller and no encoders I do not have motor speed values. It's a minor problem because motor PWM is, for this purpose, an adequate stand-in for speed. The more difficult problem is that I don't do these calculations in the Roboteq but in the Joystick pod (MASTER module) and just send Throttle and Steering to the Roboteq over the CAN bus. The only connection to the Roboteq is the 2 wire CAN cable and there's a division of labor; MASTER handles all driving calculations and Roboteq handles all motor control calculations. To implement your code in my system exactly as you've written it would mean either moving the SpeedPot calculations to the Roboteq (and sending a Pot value message repeatedly from Master to Roboteq) or leaving the calculations in Master, but repeatedly send PWM1 and PWM2 values from Roboteq to Master. Neither solution is very elegant and the first is too much work, so I started thinking about whether the same kind of damping could be done in Roboteq after the final Throttle and Steering values have arrived, without involving the pot at all. The answer is yes; I can get exactly the same curve as generated by your routine, and get some advantages, by doing the following:
Code: Select all
DampingStrength = 5
ThrottleAdjust = abs(Throttle) - (abs(Speed1)+abs(Speed2))/2)
Min = abs(Throttle/DampingStrength)
ScaledThrottleAdjust = ((abs(Throttle)-Min)*ThrottleAdjust)/abs(Throttle)
IF (Throttle >= 0) THEN
   AdjustedThrottle = Throttle-ScaledThrottleAdjust
ELSE
   AdjustedThrottle = Throttle+ScaledThrottleAdjust
END IF

SteeringAdjust = abs(Steering) - (abs(Speed1)+abs(Speed2))/2)
Min = abs(Steering/DampingStrength)
ScaledSteeringAdjust = ((abs(Steering)-Min)*SteeringAdjust)/abs(Steering)
IF (Steering >= 0) THEN
   AdjustedSteering = Steering-ScaledSteeringAdjust
ELSE
   AdjustedSteering = Steering+ScaledSteeringAdjust
END IF

This makes incorporating the smoothing algorithm into my system simple. I can just add this at the start of the SetMotors: subroutine and send AdjustedThrottle and AdjustedSteering to the motors (instead of Throttle and Steering). But there's another advantage.

Because pot values are neither used nor modified, I can now have a parameter that sets the strength of the damping without having to change pot min and max (which I might not want to do for other reasons). If DampingStrength = 1, there's no damping. If DampingStrength = 5, it duplicates what you get. If DampingStrength > 5 the damping gets stronger, with the AdjustedThrottle line getting asymptotically closer to the speed line as DampingStrength is increased. With DampingStrength = 10, it's twice as strong as with your routine (and damping starts at speed = 100 instead of speed = 200). With DampingStrength = 200, the AdjustedThrottle differs from Speed by no more than 5 (out of 1000) units, and movement is so damped that the chair may not move at all. HOWEVER, even at ridiculously strong damping the AdjustedThrottle curve is always above the Speed line so there's no change in acceleration/deceleration if the stick is deliberately moved. A "do what I say when I say it".responsiveness is not compromised.

I am going to be pretty involved with other things until mid September (and will be in Seattle for a couple weeks of October), but I will try to test this out before posting revised analog and CANbus scripts.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 01 Sep 2018, 20:07

If DampingStrength = 1, there's no damping.


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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 02 Sep 2018, 09:15

Yes John, I too like being able to adjust damping strength, including turning it off, but the beauty of this algorithm is that it should just damp very brief jiggles that might result from a tremor or driving over gravel - it should have no effect whatsoever on how the chair responds to deliberate stick movements. No delays, no reduced acceleration, no attempt to hide the effects of poor joystick position and control. Pudding stirrers will still get into trouble.

Everyone,
Someone may eventually notice that there's a bug in the code I posted yesterday. With Throttle (or Steering) = 0 there's a divide by 0 in the line
Code: Select all
ScaledThrottleAdjust = ((abs(Throttle)-Min)*ThrottleAdjust)/abs(Throttle)
Easy to solve. We can either not damp when Throttle = 0, just like Eugene's original, or we can assume that Throttle = 1 rather than 0 until speed has largely decayed, then skip the damping.

Years ago, a technician who had worked in my lab for many years told a newcomer "When Lenny tells you the next experiment to do, wait a day before starting. By then he'll have thought of most of the mistakes he's made in the design." I guess I have the same habit doing programming as I did doing fruit fly genetics. Instead of divide by 0, I may have drawn a mating scheme where two females had to mate.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 02 Sep 2018, 10:11

it should just damp very brief jiggles
Those jiggles may be my intended input to steer correct as I wheelie through a doorway! :fencing
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 02 Sep 2018, 13:22

Point well taken - you may want to the damping down low or even off.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 02 Sep 2018, 13:42

I will do. I also always want more turn response. And stop turning response.

I want it to turn and stop turning as fast as I move the stick, so it follows exactly. As such you would be surprised at quite how instant I want that! I dont mean turn speed which can be set low, just low latency. So the stick is directly connected like mechanical connection. If I choose 30% of left stick, it should hit that point as soon as the stick does. And back to zero just as fast.

Hobby some people who fly very fast planes or 3d helis swear and bitch and crash because 6 to 10ms latency is too slow for them and causes over corrections and overshoots in manoevers... They spend a fortune on super low latency rc links, ultra fast servos, etc. The average cheap RC is about 25ms which is very noticible even by me. It makes flying fast stuff harder and less accurate. My system does 6ms, and I cant feel that.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby eugenech » 02 Sep 2018, 14:49

Thank you Lenny. I am happy to be able to contribute to your work.

What I did when you release stick to 0 was intentional. I was trying to keep stoping distance to minimum. Decaying maybe too slow when you are going top speed.
Great suggestion to make DampingStrength as a variable.
eugenech
 
Posts: 25
Joined: 20 Feb 2017, 19:26
Location: Richmond Hill, Ontario

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 03 Sep 2018, 08:57

IMPORTANT

Eugene, please do the following test as soon as possible.

Change the line:
Code: Select all
CyclesPerSpeedPotRead = 10/(MainLoopWaitTime+1)
(you may have a set number different from 10 in your script) to
Code: Select all
CyclesPerSpeedPotRead = 1/(MainLoopWaitTime+1)


Do not make any other changes, but test the chair for "smoothing". My best guess is that there will be NONE even though your algorithm is still working.

Now, increase CyclesPerSpeedPotRead to 2, 3, 4 --- till you get back to the number you originally had and check again at each step for smoothing. I suspect that There will be NONE until you get back to the original number, or very close to it.

ONLY DO THE FOLLOWING WITH GREAT CAUTION, or skip this if the results above are already clear. Increase CyclesPerSpeedPotRead above what you had originally. You may get a bit more smoothing if very close to the original number, BUT beyond that the motor will not just stop accelerating but will try to reverse direction every CyclesPerSpeedPotRead'th cycle. As John can tell you, this can soon break a motor. Make the changes in CyclesPerSpeedPotRead in very small increments, and don't move the stick very far so that everything stops quickly if you take your hand off.

I was up much of the night worrying over this because of the clue in your comment
What I did when you release stick to 0 was intentional. I was trying to keep stoping distance to minimum. Decaying maybe too slow when you are going top speed.

The beauty I thought I saw in your algorithm is that those curves simply cannot produce any delay. If you are getting slow decay, then those curves are not the full picture. I eventually realized why. I had neglected to take account of this conditional in your implementation within the SpeedPot routine:
Code: Select all
IF (LoopCycles MOD CyclesPerSpeedPotRead) = 0 THEN

Both my simulation of your code, and the code I wrote, adjust Throttle and Steering by the Speed at every moment. With this conditional, you are using the current Speed only when (LoopCycles MOD CyclesPerSpeedPotRead) = 0. On every other cycle, you are using the adjusted pot value from 1 to 9 cycles back in time (assuming CyclesPerSpeedPotRead is 10). If you could magnify the command curve enough, what you'd see is not a smooth curve, but a sawtooth, which is actually touching the speed curve once every 10 cycles - and with command = speed (or power) there's no acceleration. There's smoothing AND DELAY.

Using an "aging" adjustment will cause exactly the kind of driving unpredictability that John worries over. On top of that, unlike the running-average damping produced by "Damping" in my script, there's no simple way it can be adjusted. There's only 1 (or a very narrow range because of rounding errors) of CyclesPerSpeedPotRead that can give any smoothing - below that, there's no smoothing, above that there's repeated motor reversal.

The plot I showed, re-doing the adjustment with current Speed at every cycle, will not cause any delay. I've also just about convinced myself that it won't give any damping either. I hope I'm wrong on that, but I won't know until I physically test it - I'm not enough of a mathematician/logician to really figure it all out from the numbers, but I fear that this is just another example of "There's no free lunch".

Please, please do that test - I can't - and tell us the results before anyone invests time in reproducing this, or any motors get damaged.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby eugenech » 04 Sep 2018, 04:37

Hi Lenny,

In my script I use CyclesPerSpeedPotRead = 20/(MainLoopWaitTime+1) and MainLoopWaitTime = 0.

In real world you have to deal with inertia. Chair is heavy and motor power is not infinite. Motor needs time to change speed. Adjusting it too fast and often is not necessary and sometimes can be harmful.

I think key is this line of code:

TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

Pot defines relative top speed. If set Pot to a 100, motors will reach speed of 1000, if 50 motors will reach 500. Changing Pot changes range of the joystick command.
Idea of this algorithm is to dynamically change value of TempPot (causing change in SpeedPot and TurnPot) based on motor speed until you reach Pot value (speed limit).

To find out speed you add relative speed of both wheels and divide by 2. Given that relative speed is from 0 to 1000 and Pot is 0 to 100, you divide speed by 10. So, number 20 is explained.

I will try to produce graphs from real chair Tuesday or Wednesday and will post them.
eugenech
 
Posts: 25
Joined: 20 Feb 2017, 19:26
Location: Richmond Hill, Ontario

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Williamclark77 » 04 Sep 2018, 16:55

eugenech wrote:I think key is this line of code:

TempPot = Pot - abs((Pot - (abs(SpeedLeft) + abs(SpeedRight))/20))

Pot defines relative top speed. If set Pot to a 100, motors will reach speed of 1000, if 50 motors will reach 500. Changing Pot changes range of the joystick command.
Idea of this algorithm is to dynamically change value of TempPot (causing change in SpeedPot and TurnPot) based on motor speed until you reach Pot value (speed limit).


I had set my speedpot up this way, making the joystick input proportional to the top speed. It worked fine. PERSONALLY though, I did not like it. It made the acceleration rate altered as well. Maybe "acceleration rate" isn't the best term for what I'm describing.

For example: I want to do a slight 1" or so high wheelie to hop over a board. With the speedpot maxed out I blip the joystick quickly 1/4 of the way forward. I get a 1 inch high wheelie with the chair barely moving forward. With the speedpot at 50% I now need to move the joystick exactly the same but twice as far forward to get the same result. I later forget that I maxed out the speedpot, do the same quick movement of the joystick expecting the same slight wheelie, and almost flip over backwards.

Clear as mud? It's probably much less noticeable on a chair that's less "tippy" as mine. I just want the joystick to always feel the same regardless of the top speed.

Don't modify on my account. I'm just bringing up something that may be an issue.
WcMade.com - Get nearly anything you need made
Williamclark77
 
Posts: 1059
Joined: 21 Mar 2013, 01:18
Location: South Mississippi, United States

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 04 Sep 2018, 17:07

Clear as mud? It's probably much less noticeable on a chair that's less "tippy" as mine. I just want the joystick to always feel the same regardless of the top speed.


Me too. You want the acceleration rate (and deceleration rate) to be both linear, and regardless of the amount of stick input. Thats exactly what we get now with the version I used last on the small bot, and the BM3. Same with turn acceleration. VERY high, but low turn speed. So it absolutely follows the stick. If you cough the chair does the same.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby eugenech » 05 Sep 2018, 15:58

Williamclark77 wrote:
eugenech wrote:
I had set my speedpot up this way, making the joystick input proportional to the top speed. It worked fine. PERSONALLY though, I did not like it. It made the acceleration rate altered as well. Maybe "acceleration rate" isn't the best term for what I'm describing.

For example: I want to do a slight 1" or so high wheelie to hop over a board. With the speedpot maxed out I blip the joystick quickly 1/4 of the way forward. I get a 1 inch high wheelie with the chair barely moving forward. With the speedpot at 50% I now need to move the joystick exactly the same but twice as far forward to get the same result. I later forget that I maxed out the speedpot, do the same quick movement of the joystick expecting the same slight wheelie, and almost flip over backwards.

Clear as mud? It's probably much less noticeable on a chair that's less "tippy" as mine. I just want the joystick to always feel the same regardless of the top speed.



The change I am suggesting will bring exactly what you are looking for. Same feeling regardless of Potentiometer setting.
eugenech
 
Posts: 25
Joined: 20 Feb 2017, 19:26
Location: Richmond Hill, Ontario

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby robert97 » 25 Sep 2018, 22:33

I am trying to figure out how to get the roboteq to smoothly
stop. My wheelchair in the event of joystick wire disconnect.

I've connected two 220 ohm resistors to the x-axis and
y-axis leads from the joystick and hence restrict normal voltages
to the range of .2volts-4.8volts. If i set "Safety Stop" for
minimum x, maximum x, minimum y, maximum y, the motors instantly
stop turning when an out of range value is detected. But,
that abruptness throws me out of the wheelchair. I need a smoother
decelerration. Instead of "Safety Stop" it seems that "Run
script" would allow me to select a deceleration rate.

My question is, Given that I am running Lenny's november 2018
mbs script, How do I tell the roboteq to run some other script
for stopping? The roborunplus gui gives no way to select a
script by name, nor does it give away to select a function
within the existing script.
robert97
 
Posts: 66
Joined: 03 Jun 2017, 15:34
Location: Boulder, Colorado

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby robert97 » 26 Sep 2018, 00:21

sorry. script version
print ("John_2016_12_21



Connecting Potentiometers for Commands with Safety band guards

When a potentiometer is used for sensing a critical command (Speed or Brake, for exam-
ple) it is critically important that the controller reverts to a safe condition in case wiring is
sectioned. This can be done by adding resistors at each end of the potentiometer so that
the full 0V or the full 5V will never be present, during normal operation, when the potenti-
ometer is moved end to end.

Using this circuit shown below, the Analog input will be pulled to 0V if the two top wires
of the pot are cut, and pulled to 5V if the bottom wire is cut. In normal operation, using
the shown resistor values, the analog voltage at the input will vary from 0.2V to 4.8V.


FIGURE 3-10. Potentiometer wiring in Position mode

Advanced Digital Motor Controller User Manual page 49
robert97
 
Posts: 66
Joined: 03 Jun 2017, 15:34
Location: Boulder, Colorado

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 26 Sep 2018, 01:55

You cant easily. But stop it will if configured correctly. Thats not in the script, its in the roboteqs firmware programming.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 26 Sep 2018, 08:02

Yes, Safety Stop is for EMERGENCIES only. If you absolutely can't have an abrupt stop even in the case of a joystick failure, you can do it without having a separate script, but by modifying the existing script. Take a look at how the SpeedPot routine is done; you would do something similar for the joystick but having it set Throttle = 0 and Steering = 0 if the voltage is out of bounds.

There is no way to have the Robogteq computer swap between different independent scripts - but you can have a very large number of different subroutines called via conditional statements such as an IF.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 11 Nov 2018, 12:10

NEW RELEASE OF ROBOTEQ CANbus AND ANALOG SYSTEM DESIGN AND PROGRAMS

I have just posted a new release of the software and hardware designs. You can download it at https://drive.google.com/open?id=0B3svXvyPGRgral9FU2lJZlpHdFU. I will start a separate thread with a bit more information so that it doesn't get buried in this ever-growing thread that has become almost a stream-of-consciousness novel.

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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 11 Nov 2018, 12:15

The manual alone is a work of art.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby shirley_hkg » 24 Nov 2018, 14:48

Will these new controllers work on the Sin / Cos encoder INVACARE GB motors ? :clap:
Attachments
Screen 00030.jpg
shirley_hkg
 
Posts: 3918
Joined: 31 Dec 2010, 13:42

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 24 Nov 2018, 15:16

Shirley,

I think that's a question you're going to have to ask Roboteq - either on the Forum or by email to tech support.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby robert97 » 13 Feb 2019, 17:06

have others been asked to pay $500 to use roboteq scripts?

from roboteq...
As I'm sure you're well aware, a tremendous amount of resources
and effort goes into continuously maintaining and improving
our controller firmware and accompanying software. Roborun+
is still free, but for advanced scripting and features we have
started charging. This is a one time purchase for an unlimited
and perpetual license. It can be used on any number of devices.
robert97
 
Posts: 66
Joined: 03 Jun 2017, 15:34
Location: Boulder, Colorado

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 13 Feb 2019, 17:43

With Roborun V 1.8 they introduced this (expensive) license requirement. Roboteq has given me permission to share the older V 1.7 which does not require a license. You can download it at: https://drive.google.com/open?id=0B3svXvyPGRgrQmZiMW54aGRwYjQ. V 1.7 lacks some (potentially) useful bells and whistles and there may be some newer controllers that are not included in V 1.7, but it does include the HDC2460 (the newer version of the HDC2450) and the brushless controller that Will is using.

If you feel that you do need V 1.8, write to Roboteq tech support and tell them you are using a large script for a wheelchair project (if it's my script or a modification thereof, do tell them that as well) - they will probably give you a license code for free. They did give me and at least one other wheelchair user a license code for 1.8 without charging. However, if you are using a laptop or convertible tablet with a very wide screen you will probably find that V 1.8 is harder to use than 1.7 because the bottom of the page (where the new goodies are) is clipped off in both normal window and full screen modes and can not be panned up to be visible. This is a bug that Roboteq was told about, but they do not seem interested in fixing it.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 13 Feb 2019, 18:16

Carefully with new versions of Roborun.
2.0 above ...

Image
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 13 Feb 2019, 20:19

High Vitolds,

This is not the first time something like this has happened and it's an easy mistake for a programmer (in this case someone at Roboteq) to make - leave out the "#define _G 0 " in the Constants.h file of the firmware generating program or the script interpreter (or the equivalent if it's not written in C, but I suspect it is). But _G, as all of the Roboteq variables, has an alias - it's _GO. Try that, and I'll bet it works. If neither _G nor _GO works, you can use the numerical value - it happens to be 0. So you'd write lines like SetCommand (0, 1, LeftMotor). Names like _G, or even better _GO, are easier to remember for a human than the enumerations, but the computer machine code will have that 0 in it anyway.

Check out _GO, but then do send a note to the Roboteq forum so they get it fixed in the next update. (Someone reported a similar problem with a command recently, maybe it was even the same _G command, I don't remember. The solution was indeed to use the alias.)
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 13 Feb 2019, 20:26

My general rule: when installing something new or doing an update, be sure first that you can roll back to the previous version. When I got Roborun+ 1.8 I didn't throw away 1.7, before I do a Windows update I make an image of my disc and so on. My wife doesn't do this, so I had to waste a couple hours today tracking down how a Windows update turned off almost all folder sharing attributes AND set her machine to require a password for access from networked computers. Solved the first part and I could see her folders from my computer, but couldn't get into them. Solved the second part, and I'm again able to keep some files, like a spreadsheet of our joint bank account balance, synchronized on both machines.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 13 Feb 2019, 21:42

GO - doesn't work the same way.
This is not one problem.
Robotek promised to help me.
I wrote to you, GBL once repaired. A new product, it happens ...
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 13 Feb 2019, 21:54

GO - doesn't work the same way.
This is not one problem.
Roboteq promised to help me.
I wrote to you, GBL once repaired.
1. analog channel 4 does not work
2. lost connection 232
3. G- GO does not work, not always
4. from the script does not work 2 motor channel. from RUN works.
5. internal battery = problem
BMS Roboteq - while a big problem. 3 times and included BMS broke.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 13 Feb 2019, 22:00

It sure sounds as though that GBL has some serious problems. Did you check whether SetCommand (0, 1, LeftMotor) works? Whom have you been in contact with at Roboteq?
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 13 Feb 2019, 22:19

I have 4 GBL firmware
Roborun 1.8 - 1.7 - 2.0 (3 different)
Now I took out the battery, 232 works, G works
(on which firmware I don’t remember, I can say tomorrow)
Channel 4 is down.
I'm waiting for a response from Roboteq
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 14 Feb 2019, 11:43

I don't understand.
Roborun 1.8 - 1.7 - 2.0 (3 different)
What is Roborun 2.0? The latest Roborun+ software released by Roboteq is V 1.8 placed on the download page on June 28, 2018.
Now I took out the battery, 232 works, G works
Glad RS232 and _G are working, but what battery did you take out? How are you powering the controller?
Channel 4 is down.
What is "Channel 4"? This is a 2 channel controller.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

PreviousNext

Return to Everything Powerchair

Who is online

Users browsing this forum: No registered users and 3 guests

cron

 

  eXTReMe Tracker