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: 5543
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: 5543
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: 1059
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: 531
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: 664
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: 5543
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: 664
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: 5543
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: 664
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: 5543
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: 5543
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: 5543
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: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 19 Mar 2020, 12:31

Assembly of the CAN system circuit boards is now complete and they should arrive here fairly soon. Only then will I find out whether the courier shows customs the reduced-VAT paperwork (4%) or standard (22%).
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 19 Mar 2020, 15:51

Good luck with Vat! :lol:
Let me know when I can buy a set off you.
I'm thinking I'll have a lot of spare time not going out to fill due to this bloody virus.
stevelawiw
 
Posts: 664
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 19 Mar 2020, 17:17

Or almost none. Depending how it all works out! hanged
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 19 Mar 2020, 17:19

:lol: butred
stevelawiw
 
Posts: 664
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby davidpaul » 18 Jul 2021, 12:39

I started to read through this but started to loose track of the information needed, am I right in saying some members are trying to improve the operating system with the Roboteq controller ?
davidpaul
 
Posts: 281
Joined: 17 Jun 2013, 21:21
Location: Camborne, Cornwall

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 18 Jul 2021, 14:01

The original purpose of going to the Roboteq controller was to allow higher voltage input and higher current output than one can get with commercial WC controllers. The purpose of the CANbus system is twofold: first, to provide a safer (interference-resistant) interface to the Roboteq and second, to provide flexible programming to let one experiment as new needs/possibilities arise.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby davidpaul » 18 Jul 2021, 14:08

At this time would you say the Roboteq controller is a safe upgrade ? I'm assuming some chair manufactures(Quadrix) that use 36v are using a similar system ?
davidpaul
 
Posts: 281
Joined: 17 Jun 2013, 21:21
Location: Camborne, Cornwall

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 18 Jul 2021, 14:32

I suggest you read the roboteq thread. If you understand most of it, and read and understand the roboteq manual you are in with a chance. Its not easy. Nor plug and play. Will require a lot of thinking, making parts and looms and joysticks, and a lot of time.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby davidpaul » 18 Jul 2021, 14:42

Ok thanks, although it seems doable I need short answers (I can't read through 100 posts and come away with the correct info, I have difficulties with short term memory so reading many posts just turns into bla bla bla, if you know what I mean)
davidpaul
 
Posts: 281
Joined: 17 Jun 2013, 21:21
Location: Camborne, Cornwall

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 18 Jul 2021, 17:36

You mean 3470 posts! And you will at least need to read through all the ones that are on topic. And the full user manual from roboteq, and understand the scripting and settings and how to edit it and upload to the roboteq, and build a DIY joystick.

http://www.wheelchairdriver.com/BM3-con ... ronics.jpg

Heres a pic under the seat.

http://www.wheelchairdriver.com/BM3-construction/ click through these to get some idea.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 18 Jul 2021, 17:38

Well that your problem. Its a complex thing that isnt possible to do with short answers. You will need to do a lot more than just reading that thread. You need to understand it all.

There are simple answers that will garantee failure or there are very involved answers that will need you to understand what you are doing. I am sorry but thats just how it is. It SEEMS simple at first. But when you get involved you then see why its really not! Thats why its important that you read that thread. Then ask logical questions where you dont understand. Thats really the fastest way to start this if you are serious.

You want speed?
Thats the only way.
Here http://www.wheelchairdriver.com/BM3-con ... RC-BM3.mp4 turn up sound. Testing a deceleration setting in the script.


But its not simple or plug and play.
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 » 18 Jul 2021, 18:42

Much of this thread details the attempts, often miserable failures at first and only resolved later on, to make the Roboteq work for wheelchair use. Reading the whole thread would be a terrible slog and very confusing. There is an easier way to get a handle on this, even though as Burgerman has said it's not simple. I have prepared an illustrated user/builder's manual for the CANbus + Roboteq system Rachi is using. It is a long read, but at least it progresses linearly without all the back and forth and side to side meandering that's in this thread. If you PM me your e-mail address I will get you a copy.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby fishinjunky » 08 Aug 2021, 20:25

Just out of curiosity theoretically could a person take a bounder 300m and completely remove all wiring and electronics and batteries. And motor and actuator cables. And replace with 200mah lithium battery pack and 48v wiring and 48v roboteq electronics and controls.
Invacare tdx sp
Bounder 300M 200ah lifepo4
fishinjunky
 
Posts: 1041
Joined: 11 May 2021, 02:28
Location: West Virginia United States

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 08 Aug 2021, 21:44

I could. Can you? I have no idea.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby fishinjunky » 09 Aug 2021, 12:20

Burgerman wrote:I could. Can you? I have no idea.


could I. Maybe with the right amount of research learning and time but thats a big maybe. Not something I plan on taking on just curious if it would even be possible.
Invacare tdx sp
Bounder 300M 200ah lifepo4
fishinjunky
 
Posts: 1041
Joined: 11 May 2021, 02:28
Location: West Virginia United States

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 09 Aug 2021, 12:43

A wheelchair is just a frame with 2 dc motors. They are all the same. Any controller, any joystick, all work on any chair.
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby snaker » 04 Jan 2023, 09:56

@Lenny: could you send me your user/builder's manual for the CANbus + Roboteq system?

LROBBINS wrote:Much of this thread details the attempts, often miserable failures at first and only resolved later on, to make the Roboteq work for wheelchair use. Reading the whole thread would be a terrible slog and very confusing. There is an easier way to get a handle on this, even though as Burgerman has said it's not simple. I have prepared an illustrated user/builder's manual for the CANbus + Roboteq system Rachi is using. It is a long read, but at least it progresses linearly without all the back and forth and side to side meandering that's in this thread. If you PM me your e-mail address I will get you a copy.
User avatar
snaker
 
Posts: 1193
Joined: 23 May 2015, 10:45
Location: Vietnam

PreviousNext

Return to Everything Powerchair

Who is online

Users browsing this forum: LROBBINS, woodygb and 99 guests

cron

 

  eXTReMe Tracker