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 » 09 Aug 2019, 23:50

Thanks Will. I can't quite read which controller this is, but I do see that it's an A version and your video confirms that it has internal sensors. YOU DEFINITELY SHOULD NOT BE USING A SCRIPT THAT RUNS THE ENHANCED FindEstimatedCurrents subroutine except perhaps with motor resistance set to ZERO (no compensation). Your results at 5, 10, etc. parallel what Vitolds found.

What surprised me, and may be a problem, are the large motor current values during the startup search. I wonder if that would be the case if there were no internal sensors, but the motor currents were estimated from battery current. Can you re-run this showing battery current (instead of either % or RPM for the encoders)? The question is whether battery current stays at 0 during the search -- if it does, estimated motor current would also be 0. If it doesn't, I will have to figure out a way to not run the automation routine until after that search. (I also don't know whether script startup is automatically delayed until after the search - I wonder if the manual says. That would make my task easier.)

In any case, it's still going to be some time before I post revised scripts. On the bench, with resistive loads, everything was working fine. On the chair, with high currents through brushes and motor coils, there turn out to be problems with frequent transient (a few msec long) sensor errors (especially at high current, or going to 0 from high current). I now have that problem solved in software (at least I hope that's not famous last words).

I also found that I had sensor polarity reversed in one unit, so was getting anti-compensation in that one instead of compensation. The only reason that there was halfway decent driving with that controller was because it used sensorless estimation whenever there was a transient sensor error. I only discovered this after fixing the CAN sensor fault message to Display - and then had to track down why getting rid of the errors made driving worse.

I think I need to automate a "check and correct" for sensor polarity. I've hooked a couple small motors to my bench unit with vice-grips serving as pony brakes so that I can do at least some testing without needing to use Rachi's chair. However, I'm at the moment (nearing 1 AM) kind of tearing my hair out over automating this.

As to audible noise in the video, with my laptop and my ears I can't hear it at all (even with some cheap earbuds instead of lousy speakers). Yeah for having encoders!

Lastly, is this a replacement for the burned Roboteq or were you able to repair it or is this yet another controller you already had?
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 10 Aug 2019, 00:51

Lenny, I think there is a slight inaccuracy in the measurement.
Motors with gearbox installed. When calibrating the FOC mode, the gearbox must be removed. I put 10 motor commands, my motors rotate. They do not rotate in the video.
Perhaps I translated poorly and didn’t understand something, or vice versa.
Large currents were in the old firmware. In the new, everything is much better.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Williamclark77 » 10 Aug 2019, 01:14

HBL2360A. I bought another. No response from Roboteq about the issue. After another email I got an RMA for the cooked one at 50% off repair/replacement. I'll be sending it back and will have a spare and light wallet. There was no sound in the video. Screen capture only.

Without the gearboxes the motors turn at basically any input. With gearboxes they start around 16-18. They are new and quite tight with zero backlash (yes, I know zero is technically impossible). I've purchased six gearboxes from this place. They will loosen up with a little use.

I haven't set the controller over 15 amps yet. I will after (re)doing the permanent motor connections. The seek amps at startup seems to be whatever I set it to, not what's needed to turn the motors - hence why Roboteq recommends setting it high enough to be certain it can rotate the motor in use, even if loaded.
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 » 10 Aug 2019, 13:21

Will can you show reducer?
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Williamclark77 » 10 Aug 2019, 17:54

Vitolds wrote:Will can you show reducer?


Image
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 Williamclark77 » 25 Aug 2019, 19:39

Lenny, if you need script testing done I'll be able to over the next few days. I plan to have it on jackstands connected to the computer anyway.
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 LROBBINS » 25 Aug 2019, 23:08

I've got the new CANbus version of the script done with automated detection of internal motor current sensing, automatic correction of inverted sensor polarity, automatic sensor fault detection and bypass to internal sensors or enhanced estimates as needed and some bug fixes and minor improvements that make the script a little faster. Tomorrow I'll start on porting all this to the analog only version, but I don't know how long that will take, and, as usual with the analog version, I won't be able to do significant testing and, of course, I can't test how any of this will behave with brushless motors. I'll post here when I'm ready to upload new files.
Ciao,
Lenny
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 01 Sep 2019, 12:43

Finally, here's the link to the fresh upload: https://drive.google.com/open?id=1ysOoYG8mwlvJy0023XwJUgclYXbO1ulS

There were several causes for the delay - some bugs needing squashing and some improvements to be made, but Rachi's chair needed attention and that had priority over working on programming.

I had planned to take a day to replace all of the caster stem and wheel bearings and re-work the stem mounting to ensure that the bearings stay tightly aligned, but the day before that Rachi's aid had a cup of dirty water and blended food for Rachi's PEG knocked out of her hand and straight onto the electronics. Needless to say, 300 ml of dirty water + all the accumulated salt from many days at the sea, didn't do the chair any good at all - it stopped working & there was some magic smoke. So pull it all, rinse thoroughly with deionized water, dry and inspect. The magic smoke was a burnt PA45 connector on one of the brake lines, cleaning and drying everything external let it start up and all seemed well except that there was no Roboteq motor output. Expecting the worst, opened the HDC2450 and turned out to be very lucky. There was some water inside and a nice green deposit on the header connecting the MCU and power boards. The rest of th board had no corrosion as I'd given them a urethane conformal coating. Dried it, cleaned the header and sprayed with deox/lube and it was back in business.

But, before getting back to programming, I did spend another day taking care of those bearings. Made a huge difference! The chair originally had truly awful shopping-cart type casters and I'd long ago replaced them with stem casters with top and bottom bearings, drilling out the cross bar to 14mm (not enough room for a spacer, but the most I could do) and adding a stainless outer tube to hold the bearings. (I later added thrust bearings because it was eating the no-spacer deep-groove bearings.) However, the ID of the stainless tube is ca. 4mm larger than the OD of the bearings and I'd held them centered by filling with quick-set epoxy and micro balloons, which after several years had really degraded on one side. So, this time I trued up the seating surfaces, chamfered the inner bore to make sure there would be no interference with the inner races, filled around them with high strength epoxy and cotton flox, used 12 mm bolts without casters to clamp them centered and cured at 60o overnight. Put the casters (with new wheel bearings) back on and re-mounted the rear canted swing-arm axle to the chair. Not even a hint of hesitation now in turn-in-place.

After that long blather (and lots of work), back to the programming. FIRST, the usual warning. The CANbus version has been tested on the bench and on the chair. The analog version has had only minimal testing, so do be cautious.

At startup, the script now automatically checks for whether there are external motor current sensors and that they are working properly (the STARTUP_SENSOR_CHECK subroutine). Then, the AUTO_CURRENTSENSORS subroutine checks that the polarity of external sensors (if there are any) is right and corrects that if necessary, and checks for whether there are internal motor current sensors and chooses to use either those or my "enhanced" estimated motor current if there are not. The default user setting is CurrentSensors = external as all is handled automatically, and the only time you might want to set this to CurrentSensors = internal is if you have working external sensors but don't want to use them.

During the sensor checking, the motors are commanded to 10 (1% of max output) for about 50 milliseconds (shorter if accel is set higher than on Rachi's). On Rachi's chair, the script also disconnects the brakes during this, so it certainly can't move, but at motor power = 10 it probably won't move even without brakes in 50 milliseconds. Took me a while to figure out how to do it, but the script avoids any brake clicking during all this. I also cleaned up how the script removes any drift or offset of sensor zero point. I'd been doing it by reading the sensors once every ca. 5 seconds when the chair is not moving, calculating offsets, and subtracting them every time sensor current was read. The CheckSensorZero: subroutine now uses the Roboteq SetConfig (_ACTR ...) command to re-configure the zero point to actual reading, so no subtracting offsets is needed elsewhere. Uncertainty of the zero point between calls to CheckSensorZero is (2/1000)*100 = 0.2 Amps, but usually actually zero or sometimes 1 (0.1 Motor amps).

Now some special notes particularly for Will and Vitolds.

Will, rather than trying to modify your analog program to match the CANbus script, which I'd screwed up more than once, this analog script parallels the CANbus one. It does not have any of the things, such as AccelPot, that you'd added, so if you want them you will have to do some programming.

Will & Vitolds (and others using brushless motors). I want to emphasize once again that Accel means different things in Roboteqese for brushed and brushless controllers. For brushed motor controllers it is change of PWM per second rather than actual change of RPM per second. The chair's actual physical acceleration is greatly dependent on inertia. Hence a heavy bloke in a heavy chair who likes sharp accel and decel will need much higher Accel and Decel values than a pipsqueek like my daughter.

For brushless controllers, accel is change of RPM per second (commutation frequency) and the only time you won't get that much physical acceleration is if the current limit of the controller has been reached. Hence, inertia has much less effect. An acceleration value that John likes on a brushed-motor controller could well be a rubber-burning experience with brushless. Please be cautious.

I have to go make us some lunch now, so I'll post this without re-reading it till later. If I see something needing an edit, I'll post a separate message with that.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 13:47

Thank you so much Lenny.
I know about acceleration.
Now I am doing CAN. It is different from your program, I will be able to test your script later if you need it to be.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 13:55

I want to warn those who use such a fuse.
Yesterday I discovered that this fuse (and the like) do not pass current in the opposite direction. From the controller to the battery. This may damage the controller during recuperation.

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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 01 Sep 2019, 14:03

It does not pass current in reverse even when the contacts are closed or only when open? You might want to put a hefty reverse-polarity diode and a pre-charge resistor across it, just as Roboteq advises for a contactor.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 14:27

when contacts are closed
I put simple fuses.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 01 Sep 2019, 16:40

You must put a precharge resistor, and a heavy diode across both a contactor as shown, and a fuse, or across both if you have both. Or regen current can damage the controller as it has nowhere to go...
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 17:00

I know.
I checked this automatic fuse with a tester, everything is fine.
But when charging the battery through it, I noticed that there is no charging current. I checked a couple of these and another manufacturer, all the same.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Burgerman » 01 Sep 2019, 18:12

Cant see why that would be. Its just a bi-metalic strip that heats up and opens a contact.

Not only that you would have no braking when you decela\erate, and you actually do. So you must have measured it wrong!
User avatar
Burgerman
Site Admin
 
Posts: 65050
Joined: 27 May 2008, 21:24
Location: United Kingdom

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 18:21

turn it over and you will see BAT - AUX
Through it does not go CURRENT. Take your ampere meter and check it yourself!
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Irving » 01 Sep 2019, 19:22

Vitolds wrote:when contacts are closed
I put simple fuses.

That's odd, mine does, it's just a thermal cutout like BM says.
C5/6 A (complete)
Puma 40, 75Ah LiFePO4 (pic is on tour @ Whistler, BC)
Puma 40 backup, 73Ah MK (for now)
Spectra Plus (weedy 40Ah MK)
User avatar
Irving
 
Posts: 2114
Joined: 04 Dec 2012, 11:51
Location: NW London

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 19:23

A Chinese without a name, at the price of a dollar, works but every other time.

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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 01 Sep 2019, 19:29

Circuit Breakers - 285-Series
https://www.bluesea.com/products/catego ... anel_Mount
That these 3 pieces I do not work.
All new, bought from them.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Irving » 01 Sep 2019, 19:47

Vitolds wrote:A Chinese without a name, at the price of a dollar, works but every other time.


Mine is waterproof, comes with a rubber mounting gasket, and is sold as a marine battery isolator/100A cutout.

Works exactly as I expected.

PSX_20190901_194320.jpg
User avatar
Irving
 
Posts: 2114
Joined: 04 Dec 2012, 11:51
Location: NW London

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 06 Sep 2019, 18:02

Auto fuses were defective. They promised to replace me.
Once triggered, they can behave this way.
The fuse did not pass the charging current of 30 amperes, but it passed 10 amperes to the motor.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Williamclark77 » 22 Sep 2019, 05:15

Lenny,

Sorry I haven't been around lately. I took on a very demanding job. I didn't want to return working for someone else, but I like the refrigerator to be cold when I open it. An offer was made to me that I couldn't pass up. Unfortunately it's left me with little spare time.

I downloaded your script today and tested it on jackstands with my W3 for about an hour. I could not get the chair to stop. It constantly turned at roughly 5% speed with the joystick at neutral. After playing with the settings and looking over I figured out it was the "minimumstick" causing the issue. Any setting other than zero causes the motors to constantly turn. The higher the number the faster the tires spin at neutral stick. The only way to stop them was the E stop in Roborun or turning the Roboteq off.

Once I set minimumstick to zero it seemed to behave properly and work correctly. I did set motor compensation to 10, basically nothing. I'll attempt to actually test it in use tomorrow if more playing while on jackstands seems safe.

Unrelated to the script specifically, but my W3 required scary looking settings to feel right. I haven't gotten it completely fine tuned yet using the same basic script from W2. It is close. I ASSume it's because of the lower gearing. I'll post exactly what I have it on later.
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 LROBBINS » 22 Sep 2019, 07:55

Hi Will,

Yesterday Vitolds told me in a PM of the same problem, and today you confirm it, so it's definitely a problem in the script and not a configuration problem. That problem doesn't exist in the C-language programming of Master for the CAN system, just in the analog version (which I can't test). I've briefly looked at the script and think I've found the problem & an easy fix, but I'm shortly off to an all day meeting in Firenze (Florence for you anglo-saxons who insist on changing its name) so will get back here tonight or tomorrow.

A BIG THANK YOU TO BOTH WILL AND VITOLDS!

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

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 22 Sep 2019, 20:24

TO ALL THOSE USING THE ANALOG (non-CAN) ROBOTEQ SCRIPT.

Here's a new version of the file that should have the problem found by Will and Vitolds fixed.

The fault was my not keeping always in mind that MicroBasic has only global variables so if a value changes in one loop cycle, it stays that way the next time it calls GoSub StickSensitivity. The fix was simple (adding two IF conditions so StickSensitivity can't change Steering if Steering = 0 and can't change Throttle if Throttle = 0. You can see a note about it in the new version of StickSensitivity. (I also deleted a calculation at the top of StickSensitivity of something that was never used and hence was just wasting computer effort). In the CANbus system, this is done in Master rather than the Roboteq and uses local variables (dynamic memory) that are created only when the procedure is called and no longer exist when the procedure is finished.

Please do let me know if this hasn't fixed the movement-with-stick-centered problem.
Attachments
analog 2019_09_22.mbs
(64.86 KiB) Downloaded 694 times
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 23 Sep 2019, 11:18

Hi Lenny I've just loaded the script into my brushless bench setup with HBL2372 running two GB motors and the motors spin without a joystick connected. Let me know what assistance if any I can be if any.
stevelawiw
 
Posts: 664
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 23 Sep 2019, 11:31

Hello lenny
The StickSensitivity error was in the previous script, I thought it was my script problem and did not tell you.
Now the motors do not rotate with the joystick zero.
But StickSensitivity controls only one motor, (increases by minStick).
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 23 Sep 2019, 15:55

Stevelawiw:

I suspect that you have a configuration problem. With no joystick connected the analog input sees 0 mV which is FULL REVERSE (or FULL FORWARD if configured as conversion polarity = "inverted", not NO MOVEMENT. But if configured so that the controller is getting its information from the analog inputs and the analog inputs are configured correctly (for example, Analog Safety/Keep within guard bands should be set to "enabled") 0 mV from a disconnected input shouldn't do anything (script running or not).

Before doing anything else, do two things. Disconnect the motors - you don't want them moving during initial testing. And, in the configuration tab set Start-up\Script auto-start to "disable" so the script doesn't run as soon as the controller is powered up.

Now, if you've not already done so, with no script running - stop it if it's already running, load the attached configuration profile (the default HBL profile is NOT suitable) and change Start-up\Script auto-start to "disable", and download it to the controller. Attach your joystick to analog pins 1 and 2 (analog 1 = Throttle, analog 2 = Steering) and in the configuration tab use the calibration tool to set minimum, center and max values. Choose "direct" or "inverted" conversion polarity to match what your joystick does - for example, if left stick gives high mV and right stick gives low mV you have to use "inverted". Because this configuration file specifies "Action on min" as No Action and the same for "Action on max" and also has "Keep within guard bands " set to "enabled", disconnecting the joystick should no longer cause movement. Do remember that the logical pin numbers are not the same as the physical pin numbers in the connectors - you can refer to the manual, or use the View Pinout in Roborun to see which physical pin has what logical meaning. If you can't use ana1 or ana2 for some reason (like you're using them for something else such as a digital output) you can change which pins the script uses in the FindMode: subroutine. Now carefully go through all of the parameters in the configuration tab and set them to what they should be for your motors and physical/electrical setup, save that as a file, and download it to the controller.

Next, in the RUN tab, still with no script running, set it to graph MotorControl1 and 2 and MotorPower 1 and 2 and use the sliders to see that these are behaving correctly (for example, if mix mode is 1 or 2, slider 1 should move both motors in the same direction, and slider 2 should move one CW and the other CCW; if one slider moves one motor and the other slider moves the other motor you haven't configured mixing or if both sliders cause both motors to rotate in the same direction, a conversion polarity setting is wrong. If you are using Roborun v.2 you could then enable joystick input (without running the script) and see if the joystick is working as it should (I've never used that tool, however). Otherwise, double check that your joystick is connected correctly, click the "Mute" box in the run tab and run the script. Moving the joystick should now give more-or-less (you will have to tune the user settings eventually) proper behavior of MotorCommand and MotorPower in the run graph. Only once all of this is working correctly, attach the motors (with the chair up off the ground!) and start real testing.

If what I've written has left you confused, I think that the best thing to do is read (and re-read) the "Roborun+ Utility User Manual" now available as a separate download.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby stevelawiw » 23 Sep 2019, 16:12

Thanks Lenny I have to go out now but I'll go through this when I get back. After an initial read through one question, what do you mean by "load the attached configuration profile"?
stevelawiw
 
Posts: 664
Joined: 21 Jul 2012, 20:55
Location: Isle of Wight, UK

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby LROBBINS » 23 Sep 2019, 16:54

Vitolds:

This should not be and I suspect that you have either a configuration or a wiring problem. "Throttle" controls Motor Channel 1 and if mixing is set to mode 1 or mode 2, both motors should move in the same direction. "Steering" controls Motor Channel 2 and moving the stick straight left or straight right should make both motors move in opposite directions. No matter what the script does, the only time you should have only 1 motor moving is in a turn-while-moving (forward or back) that exactly balances out the Throttle and Steering for one of the motors. There is absolutely nothing I know of in the script that sends commands to one motor only, with or without StickSensitivity:.

So, let's try to find out where the problem lies. DISCONNECT THE MOTORS, stop any running script, and watch MotorCommand1 and MotorCommand2 in the Roborun run tab using the sliders. (At least with brushed motors the controller doesn't shut off if there are no motors, I don't really know if that's true with brushless, however). Slider 1 should make channel 1 and channel 2 move in the same direction, slider 2 should make them move in opposite directions. If they are doing what they should, you have it configured correctly for mixing.

Now, connect the motors, but still use the sliders. Are the motors turning the way the graph says they should? If not, you have a connection or motor or sensor problem and in your case with brushless motors it can be a little hard to find what's not connected or is connected wrong because it can be a motor coil or hall sensor connection - lots of wires there. The Roboteq controller user's manual should help you figure that out.

Once you've ruled out a connection problem, disconnect the motors again, set the run tab to "mute", run the script and watch the MotorCommand and MotorPower lines. Is only one channel showing movement and the other not? IF SO THERE'S A MAJOR BUG IN THE SCRIPT and it will be up to me to find it.

If all's now OK, re-connect the motors and (with the chair jacked up) start your "real world" testing.
LROBBINS
 
Posts: 5543
Joined: 27 Aug 2010, 09:36
Location: Siena, Italy

Re: PINNED - Roboteq Controller - developing for powerchairs

Postby Vitolds » 23 Sep 2019, 17:28

The problem of translation from Russian into English. I'll try ;)
-----------------------------------------
Code: Select all
  GoSub ScaleThrottle
  GoSub ScaleSteering
'  GoSub StickSensitivity

StickSensitivity - Not active. U-turn in place. Tnrottle - 0.
Motors spin at the same speed. In different directions. All perfectly.
-----------------------------------------
Code: Select all
  GoSub ScaleThrottle
  GoSub ScaleSteering
  GoSub StickSensitivity 

StickSensitivity - active. U-turn in place. Tnrottle - 0.
Motor 1 rotates slower than Motor 2. independently Steering <> 0.
Vitolds
 
Posts: 531
Joined: 26 Mar 2014, 22:12
Location: Moscow Russia

PreviousNext

Return to Everything Powerchair

Who is online

Users browsing this forum: No registered users and 241 guests

 

  eXTReMe Tracker