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 » 30 Sep 2019, 21:03

Hi Will,

I don't know why the motor command lines are showing those erratic dropouts. I have one possibility to check in mind, but I have to look at the script carefully to see if my notion might make sense. I am not seeing that at all with the brushed motor controller (HDC2460), but used to get something like that with an original version of the HDC2450 (a couple microcomputer boards back) if I sent Throttle and Steering commands too frequently. As the newer controllers I have (one HDC2450, but with a newer MCU board, one HDC2460 with a single board that has both the MCU and power stages) doesn't do this took some IFs out of my script and send motor commands more frequently. I don't know if I did the same on the analog script or not, so I'll have to look. It will probably be Wednesday before I can get to that. Tomorrow I'll be all day at a celebration of the 100th birthday of a former colleague.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 30 Sep 2019, 21:34

Hi again,

Despite being exhausted at the moment, I found your results disturbing enough that I took a look at the SetMotors: subroutine in the current and an older script. Indeed, I had changed it. So, before doing anything else, I'd like you to try changing it back.

The current subroutine is:
Code: Select all
SetMotors:
  SetCommand (_G, 1, Throttle)
  SetCommand (_G, 2, Steering)
RETURN 'SetMotors:

Change it back to this one:
Code: Select all
SetMotors:
DIM lastThrottle AS Integer
DIM lastSteering AS Integer
  IF Throttle <> lastThrottle THEN
    SetCommand (_G, 1, Throttle)
    lastThrottle = Throttle
  END IF
  IF Steering <> lastSteering THEN
    SetCommand (_G, 2, Steering)
    lastSteering = Steering
  END IF
RETURN 'SetMotors:


The reason I changed this was to ensure that the serial watchdog doesn't trigger if Throttle and Steering don't change for a long time, but if this is causing problems I'll have to come up with another way (such as sending one of these every nnn loop cycles even if it hasn't changed) to ensure that. Let me know whether this helps.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Williamclark77 » 30 Sep 2019, 21:56

I'll attempt to try it tonight. No guarantees. Don't hustle on this for me. It's not a necessity for me. I'm merely the test guinea pig for you guys.
WcMade.com - Get nearly anything you need made
Williamclark77
 
Posts: 1012
Joined: 21 Mar 2013, 01:18
Location: South Mississippi, United States

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 02 Oct 2019, 18:20

I could not see the problems like Will.
But I do not have a check of current sensors, it immediately reads.
I tried the old version, and the new version.
Code: Select all
[code]SetMotors:
   SetCommand (_G, 1, Throttle)
   SetCommand (_G, 2, Steering) 
'  PRINT (" MOTOR L =  ", Throttle,"\t", "  MOTOR R = ", Steering, "\n")
RETURN 'SetMotors:[/code]


Code: Select all
'SetMotors:
'  DIM lastThrottle AS Integer
'  DIM lastSteering AS Integer
'  IF (Throttle <> lastThrottle) THEN
'    SetCommand (_G, 1, Throttle)
'   lastThrottle = Throttle
'  END IF
'  IF (Steering <> lastSteering) THEN
'    SetCommand (_G, 2, Steering)
'   lastSteering = Steering
'  END IF
'RETURN 'SetMotors:


But here is what could be
I do not have gearboxes installed. The motors are mounted on a stand and rotate easily.
Vitolds
 
Posts: 469
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 06 Dec 2019, 23:07

Code: Select all
AUTO_CURRENTSENSORS:
  IF CurrentCheckRun AND NOT AutoSensorRun THEN 'this procedure runs until motor current source and sensor polarity are set
    DIM BkDelay AS Integer
    BkDelay = GetConfig (_BKD)
       PRINT ("SENSOR FAILED DURING POLARITY TEST - FaultL: ",FaultL,"  FaultR: ",FaultR,"\n")

'configure brakes so never released
    SetConfig (_DOA, Brake1Pin, 0)
    SetConfig (_DOA, Brake2Pin, 0)
'set and later reset BKD to avoid clicking of brakes at end of subroutine
   SetConfig (_BKD, 0)
   wait (1)
' following two lines to be used if using a contactor that turns on and off with script
'    SetCommand (_DSET,ContactorPin) 'sets contactor pin
'    wait (1)
'use these two lines for normal motors and matching sensor range
    SetCommand (_G, 1, 11) 'throttle channel set to 1% PWM
    WHILE abs(GetValue(_MOTPWR,1))<10 OR abs(GetValue(_MOTPWR,2))<10 'wait until motor power has reached 1% for both motors
'use next two lines for testing with small motors and 100A sensors
'    SetCommand (_G, 1, 101) '
'    WHILE abs(GetValue(_MOTPWR,1))<100 OR abs(GetValue(_MOTPWR,2))<100 'use this for testing with small motors and 100A sensors
      wait (1)
   END WHILE
    IF CurrentSensors = external AND SensorsOK AND FaultL < 3 AND FaultR < 3 THEN
      WHILE (NOT LDone OR NOT RDone) AND FaultL < 3 AND FaultR < 3
        GoSub CHECK_SENSOR_POLARITY
      END WHILE
      IF FaultL < 3 AND FaultR < 3 THEN
        PRINT ("USING EXTERNAL SENSORS \n")
     ELSE
       PRINT ("SENSOR FAILED DURING POLARITY TEST - FaultL: ",FaultL,"  FaultR: ",FaultR,"\n")
      END IF
    ELSE 'CurrentSensors = internal OR NOT SensorOK OR FaultL >=3 OR FaultR >= 3
      IF GetValue (_A,1) <>0 OR GetValue (_A,2 )<> 0 THEN 'current reported for either motor implies
                                                         'internal sensors present even if one has failed
       CurrentSensors = internal 'use unmodified _A values for MotorCompensation
        PRINT ("USING INTERNAL MOTOR AMPS \n")
      ELSE 'no internal motor current sensors
       CurrentSensors = none 'use enhanced motor current estimates for MotorCompensation
        PRINT ("USING ENHANCED MOTOR AMPS \n")
      END IF
   END IF
   IF CurrentSensors = Internal OR CurrentSensors = none OR (LDone AND RDone)
      SetCommand (_G, 1, 0) 'throttle channel set to 0
      WHILE abs(GetValue(_MOTPWR,1))<>0 OR abs(GetValue(_MOTPWR,2))<>0
        wait (1)
     END WHILE
    'configure brakes to normal operation - released when motor is on
'Roboteq manual has misleading description of _DOA.
  'Just setting _DOA to 1 makes brakes operate when motor on, but doesn't specify which motor.
  'Correct value is 1 + 16 (=motor1) + 32 (=motor2) = 49
      SetConfig (_DOA, Brake1Pin, 49)
      SetConfig (_DOA, Brake2Pin, 49)
     Wait (1)
' following line to be used if using a contactor that turns on and off from script
'      SetCommand (_DRES,ContactorPin) 'resets contactor pin
      SetConfig (_BKD, BkDelay)
      AutoSensorRun = TRUE
   END IF
  END IF
RETURN 'AUTO_CURRENTSENSORS

I've got a problem with brake delay (BkDelay) being reset to zero whenever I run the script.
In the AUTO_CURRENTSENSORS: subroutine is the only place brake delay is mentioned.
BkDelay is set to zero at the start, I think the problem is because where it's supposed to reset to the original value at the end it's in an if statement "IF CurrentSensors = Internal OR CurrentSensors = none OR (LDone AND RDone)" and it shouldn't be.
The values for the variables I get for the if statement are CurrentSensors = 2 and both LDone and RDone = 0
Also I get 'SENSOR FAILED DURING POLARITY TEST - FaultL: 3 FaultR: 3
script version is analog 2019_09_25
stevelawiw
 
Posts: 443
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 08 Dec 2019, 11:03

Clearly there's a problem here, but I don't think the "if" is key - or at least not the major problem. I only got about 4 hr sleep last night and have a s---load of stuff to do this morning, but I hope to get to this later today. Expect me to be asking you to gather some diagnostics to figure out where things are going awry.
Ciao,
Lenny
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 08 Dec 2019, 12:55

Ok thanks Lenny don't worry about this now if you're not sleeping, it can wait it's not a problem for me, but I'll get you the diagnostics asap when you have the time to look at this.
stevelawiw
 
Posts: 443
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 08 Dec 2019, 22:34

Here's something very simple to check. One of the first things that AUTO_CURRENTSENSORS: does is read the brake delay value from the current controller configuration profile using BkDelay = GetConfig (_BKD). At the end of AUTO_CURRENTSENSORS: (if it's working correctly) it resets the delay to that value with SetConfig (_BKD, BkDelay). So I looked at the profile file you sent me dated 14 November and saw that it has Brake Delay set to ZERO. If that was never changed in the configuration, AUTO_CURRENTSENSORS will ALWAYS set brake delay to 0.

So the first thing to do is load your configuration file from the controller and take a look at how brake delay is set and put in whatever value you think is appropriate, e.g. 200 or 250 msec (it's under Power Output/General). If your terrain is pretty flat you can use a longish time to cut down on the clickety clack, but if it's hilly where you are you will probably want to keep it short.

That may solve the problem, but whether it does or doesn't I'd like you to do something else as well. In your post you gave the values of various variables, but without the whole log file one can't tell at what point in the script that value was being read. Even with the whole log file it can be nearly impossible to figure out at what point in the program a given value is being reported. For example, CurrentSensors starts out being "external" (= 2) but will be changed in AUTO_CURRENTSENSORS: to match your chair's setup. I suspect that the value of 2 you got was at the start of the program and not at the end of AUTO_CURRENTSENSORS: -- with brushless motors you don't have external sensors and CurrentSensors should have changed to "internal" (= 1) if you have one of the newer controllers with built in accurate motor current measurement, or "none" (= 0) if motor current is estimated from battery current.

Given that there's no proper debugger for Roboteq scripts, the best way to see what's happening is using PRINT statements and there are already some in AUTO_CURRENTSENSORS:. (I'm old-fashioned enough to usually find print statements more useful than even a real debugger, though it's sometimes useful to be able to step through a program line by line while watching selected variables.) To see these PRINT lines, set Roborun to the configuration tab, clear the display to get rid of all the "raw" values (button at bottom right), and then start the script (either by turning on the power or hitting the restart button at the top of the screen. You should now get a printout of what AUTO_CURRENT SENSORS is doing. You can then save the log to a file or to the clipboard (and from there to e.g. notepad). If you send me that I will probably be able to tell whether AUTO_CURRENTSENSORS: is working correctly and might be able to tell where a problem lies if there is one.

That IF condition at the end of AUTO_CURRENTSENSORS: may actually be completely unnecessary, but I'm going to need a clearer head before I can think that through well enough.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 09 Dec 2019, 17:38

Here's something very simple to check. One of the first things that AUTO_CURRENTSENSORS: does is read the brake delay value from the current controller configuration profile using BkDelay = GetConfig (_BKD). At the end of AUTO_CURRENTSENSORS: (if it's working correctly) it resets the delay to that value with SetConfig (_BKD, BkDelay). So I looked at the profile file you sent me dated 14 November and saw that it has Brake Delay set to ZERO. If that was never changed in the configuration, AUTO_CURRENTSENSORS will ALWAYS set brake delay to 0.

So the first thing to do is load your configuration file from the controller and take a look at how brake delay is set and put in whatever value you think is appropriate, e.g. 200 or 250 msec (it's under Power Output/General). If your terrain is pretty flat you can use a longish time to cut down on the clickety clack, but if it's hilly where you are you will probably want to keep it short.

Yes, the way I've been setting brake delay is using the configuration tab in Roborun V1.7. The problem became aparrent because everytime I restarted the script I would lose the value I had entered for brake delay.

That may solve the problem, but whether it does or doesn't I'd like you to do something else as well. In your post you gave the values of various variables, but without the whole log file one can't tell at what point in the script that value was being read. Even with the whole log file it can be nearly impossible to figure out at what point in the program a given value is being reported. For example, CurrentSensors starts out being "external" (= 2) but will be changed in AUTO_CURRENTSENSORS: to match your chair's setup. I suspect that the value of 2 you got was at the start of the program and not at the end of AUTO_CURRENTSENSORS: -- with brushless motors you don't have external sensors and CurrentSensors should have changed to "internal" (= 1) if you have one of the newer controllers with built in accurate motor current measurement, or "none" (= 0) if motor current is estimated from battery current.

Given that there's no proper debugger for Roboteq scripts, the best way to see what's happening is using PRINT statements and there are already some in AUTO_CURRENTSENSORS:. (I'm old-fashioned enough to usually find print statements more useful than even a real debugger, though it's sometimes useful to be able to step through a program line by line while watching selected variables.) To see these PRINT lines, set Roborun to the configuration tab, clear the display to get rid of all the "raw" values (button at bottom right), and then start the script (either by turning on the power or hitting the restart button at the top of the screen. You should now get a printout of what AUTO_CURRENT SENSORS is doing. You can then save the log to a file or to the clipboard (and from there to e.g. notepad). If you send me that I will probably be able to tell whether AUTO_CURRENTSENSORS: is working correctly and might be able to tell where a problem lies if there is one.

Ok, so what I think you want me to do is to turn on all the print statements for the whole script by setting SuppressPrinting = False in the User Settings section of the script and then send you the log from the Console tab. I'll do that and send it to your email addy you gave me unless to tell me otherwise.

That IF condition at the end of AUTO_CURRENTSENSORS: may actually be completely unnecessary, but I'm going to need a clearer head before I can think that through well enough.
stevelawiw
 
Posts: 443
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 09 Dec 2019, 21:07

Ok, so what I think you want me to do is to turn on all the print statements for the whole script by setting SuppressPrinting = False in the User Settings section of the script and then send you the log from the Console tab. I'll do that and send it to your email addy you gave me unless to tell me otherwise.


No. Follow the e-mail I just sent you so that ONLY the startup print lines will show.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 10 Dec 2019, 09:31

Just to let all know, there was indeed a logic flaw that will affect only some physical setups. It's been fixed, but before posting a new file I want to do some cleanup and bullet-proofing. You can expect that to take a few days.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 14 Jan 2020, 16:05

This will be a long note (split into several messages) so please bear with me as I have a couple important things to report.

First, yesterday I did something I may come to regret. As you may be aware the response to my offer to front the cost of having full sets of finished boards made for the CAN system was decidedly underwhelming. Yesterday, even with only one fairly firm commitment to buy one, I went ahead and placed an order for five sets with all of the surface-mount components. I received confirmation notice today so we can expect them to be available in about a month (Chinese New Year and component procurement will contribute to this).
Seed order 2020_01_13.jpg
To which one has to add 22% VAT. It should be 4%, but shippers almost never show the documents to customs, so I can expect the 22% and getting a refund of the overcharge from Italian customs is a hopeless task. So total cost for 5 sets will be about $(U.S.)1,715 for a per system cost of $343 + shipping from me to you.

There are at least a couple reasons I've gone ahead and done this. The most important is that I am very uneasy about the safety aspects of an analog system and I want to encourage you to move to CANbus. But there are other reasons as well.

I have become increasingly annoyed by trying to maintain and debug two different sets of programs. Although the analog script and CANbus script are quite similar and I can mostly just copy, paste and edit in coordinating the two, that last step "edit" has too often been "screwup" which then entails a new round of diagnosing and debugging, usually with lots of e-mailing back and forth to one or more of you for testing the analog version. I want to simplify my life by working on only one system.

The CAN system is not only safer, but it's more flexible and, with all but the Roboteq script written in a real programming language, it is easier to expand, modify and debug. It already includes seat lift and tilt and lighting controls, a display screen, and fault logging and its simple Programmer module lets one simply adjust user settings without digging into the actual code. Even if one wants to change the programming itself, that too is easier as everything is divided into tabbed, functional modules for each node. For example, Rachi's chair can be driven, and seat and lighting controlled, from either an attendant joystick or her head and foot operated switches. If, however, someone wanted to drive with the joystick, but work actuators or lights via switches, it would be but a few minutes work to add that as a user-selectable option. I'm not willing to try to do that in a MicroBasic script + Roboteq configuration profile.

As another example, I've recently added another Nano+CAN board (included in the board set, but entirely optional) that adds two new functions to the Power Distribution module. One is for a mechanically-simplified seat lift and tilt mechanism (more about that another time - hopefully soon), but that requires some "smarts" to keep tilt constant while going up and down. The other is to allow actuator limit switches that don't need diodes and don't have to carry full actuator current - they connect at digital input level to the added Nano which then sends CAN messages when limits are reached.

I do need to remind everyone that these boards don't make this "plug and play": you would still need to add a joystick pot, contactor, enclosures, 4-wire cables between modules, midi fuse, connectors, Roboteq wiring and so on. But that's about the same level of work as would be needed for any control system, except for the cabling which is much simpler than in the analog setup.

P.S. I have attached files with some of the details of the PCBA order.
Attachments
PCB Seeed order 2020_01_13.jpg
BOM Seeed order 2020_01_13a.jpg
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 14 Jan 2020, 18:23

Part 2: software updates

Thanks to Steve Lawrence's (stevelawiw) feedback and careful and patient testing some flaws in the script were uncovered. They were non-critical, but still more than minor annoyances (such as MotorCompensation not being called in some circumstances), but they have now been fixed and I hope to post updated files in a week or so. Of course, while getting rid of some of the minor bugs I introduced some real baddies along the way that took a while to figure out and get rid of. I want to update the manual and I have updated hardware and software files for the CANbus system as well. Before posting all the files, I have to go through them to make sure none of the parameters set for Rachi's chair (such as high motor resistance) are going to be dangerous for others. I think that I forgot to put the image files and fault message txt files for the Display module in the last download, so I have to add them too. So, do be patient.

Steve is working on an Invacare GB motor project, so we're getting to see what might be problems specific to brushless control, and those motors in particular. He currently has to deal with a bad joystick pot (salvaged from an old pod) or bad joystick wiring - with the analog system these cause the Roboteq controller to sort of throw up its hands in consternation. With the CAN script, a bad joystick will, of course, also not let you drive, but you won't risk going in circles and there'll be on-screen error messages and more detailed fault information in the SD-card log to help you figure out what's happened.

In addition, Robert Gray, who has a 48V pack in a BM3 lookalike, has run into an annoying "feature" that shows up only during the 2 seconds between turning on the Roboteq controller and when the script is actually running. It's a problem one can live with, it doesn't exist in the CAN system, and is only there if the contactor is already on when the Roboteq computer is started. Nevertheless, he and I are currently trying to figure out whether there's a way to get rid of it.

Lastly, the next download to Google Drive will include sample configuration profiles for both the analog and CANbus scripts. One of the things I found out working with a number of people is that the default Roboteq profiles are not a good starting point for these scripts unless you go through every last one of the settings, for all of the pins, even the ones you are not using, to make sure there are no conflicts. Hence, for the future I will suggest starting with a known workable profile and modifying it to suit your wiring.
LROBBINS
 
Posts: 4595
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Previous

Return to Everything Powerchair

Who is online

Users browsing this forum: Google [Bot], hank and 17 guests

 

  eXTReMe Tracker