Control with Arduino

[ouaburst]

I have two electrical wheels to a wheel chair with a joystick, connection box and a 24V battery.

I have bought the kit on this site: https://www.alibaba.com/product-detail/The-best-and-cheapest-bldc-motor_60743183272.html?spm=a2700.details.0.0.1b1f76bfL2hXsK

I also bought the following driver from Amazon: https://www.amazon.com/RioRand-6-60V-Brushless-Electric-Controller/dp/B087M2378D

My goal is to control the motors with an Arduino.

Did I bought the correct driver?
Do you have any suggestions on how to proceed?

The only documentation I have access to is this PDF:

motor_socket_connection.pdf

(16.64 KiB) Downloaded 40 times

Thanks!

[daveonwheels]

i suspect you are not going to have desirable results from those motors

[ouaburst]

Can you please explain why?

[slomobile]

You provide no information about the joystick or "connection box" or the Arduino code. So it is hard to know if you have all that you will need.
That motor driver should get the motor spinning no load. Whether the motor and controller are up to the task of pushing around a person are a different matter.
Its anyone's guess which will catch fire first. I suggest you start with 5 amp fuses on each side. If the fuse blows before anything overheats, move up to 10A and check again for overheating. Maybe you can get to 25A fuses without burning or blowing if you are lucky. That would be a good result.

The motor cable looks awful small for carrying 10 conductors and the heat sink looks marginal for 6 mosfets carrying 400W. If you know which mosfets it uses you can learn lots more. 250W motor/24V = about 10A nominal motor current. Measuring the DC resistance per motor phase will give a clue to copper losses, but 85% motor efficiency seems about right. It looks small for even 10A let alone the aspirational 25A in the name MT25. If you find it overheats in your application, you could try bumping up the voltage.

The 21Nm torque rating is after a 23:1 gearbox. I've seen plenty of manufacturers quote the torque rating as the torque which can be applied to the output shaft before the gearbox explodes, not necessarily what the motor can provide. Either way, 21Nm is about 15.5 foot pounds. So if you hang a 15.5lb weight on the end of a 1 foot wrench, its that much torque. Like tightening a bolt till its snug but not tight. Doesn't seem like a lot.

[daveonwheels]

it isnt a lot. you are correct. the motors are too small to be used in a wheelchair. the controller board will melt or burn with the current draw. i suggest starting over when you know more about what you are doing.also,avoid buying electronic controller boards from amazon,they are crap

[Burgerman]

It depends on what your intended use is.
The majority of tHe cost of a powerchair control system is in the complex control systems development which isnt just a simple tank steer mix algorythm. So whilst those motors are used on cheap chinese lightweight folding chairs, the expense is in man hours and computer code.

I have been through all this before. Using a robotics 150A 50V controller which was hopeless without lennys script that is still being developed and updated a decade later. Heres an old example.

https://www.wheelchairdriver.com/BM3-co ... Script.txt

And this allows the thing to be sensibly controlled and steered as well as to have all the essential current sensing and positive feedback loop to give adequate torque at small stick movements. Dont underestimate the complexity if its used for a wheelchair. Or it will always be pretty unusable compared to fully developed commercial systems. Or the currents required to turn in place etc.

[slomobile]

I'm less inclined to credit the complex programming options in wheelchair controllers unless your condition requires filtering the joystick input due to poor hand function.

If your needs are simply scooterlike transport in a wheelchair shaped package, you might get by with simple tank drive mixing. For me, elevon mix with expo was all I needed for responsive confident control.
My first chair was a junkyard truck seat on plywood base, 2 motor/wheel combos from an ebay chair breaker, toolbox casters, https://www.dimensionengineering.com/pr ... rtooth2x25, a single 12v car battery, and RC joystick, later an arduino and thumbstick salvaged from a game controller. It wasn't fancy or fast, but it was quick to build, cheap, worked a couple years till I figured out what features I really needed. I still have it but the 3/4" plywood started to bend under my weight resulting in extra camber. It isn't for everyone, but I wish my current chair started and stopped as instantly as that old bodge.

I didnt have trouble turning in place even on grass with 12v battery. Not sure what lucky magic that was. Maybe it was just super lightweight.

[Burgerman]

I'm less inclined to credit the complex programming options in wheelchair controllers unless your condition requires filtering the joystick input due to poor hand function.

I tried that as I build all sorts of RC stuff. Its dismal and results in terrible control accuracy for a bunch of reasons. The thing ends up mostly going where it wants. Which is why on my BM3 chair an roboteq controller we ended up with around a decade of modding and tuning a control algo script. Thanks to lennys scripting skills. Read the massive roboteq thread pinned at the top of the forum to understand why without writing a book. All you can say about a raw mix is tat "it can be moved". I have great heli flying 50 years worth of RC stuff skills inc heli and very fast turbojets/pulse jet skills. So I dont have poor hand coordination skills. Just the opposite. And I find what you describe as unusable as a daily wheelchair. It would be ok to move a toolbox about or something.

[ouaburst]

OK, this seems to be overwhelming project.
My goal is to built a cart with powerful wheel.
My inspiration comes from this Youtube page: https://www.youtube.com/channel/UCbazCk7W64I_IwAJG1XL7Pg/videos
Can anyone guess what type of wheel motor does they use?

[Burgerman]

Yes.
Proper full sized non brushless DC 24V 4 pole wheelchair motors x4 with a 100A per channel or 120A per channel controller. At a rough guess with RC.

Similar to, but more powerful than mine below...

I built this to see if tank steer 4x4 was possible with 100A X2 control system with everything programmed to the max including motor load compensation. It isnt. You need more power (torque) than it can provide once you add some weight on top or it cant steer.

[daveonwheels]

please note BM said 24v non brushless wheelchair motors. not weak chinese brushless motors of unknown properties

[slomobile]

BM, That 2nd set of non steerable wheels in front is likely what was preventing it from turning. Turning center firmly between 2 axles instead of on one differential axle. Are the fronts chain driven off the rear motors or freewheeling? Either way, if you swapped the front wheels with a set of those omni wheels from a Whill, your cart might drive like a little mountain goat.

[Burgerman]

All four chain driven. Even worse with 4 motors as the moment one slips all the current drops, which means all the motor compensation vanishes too!

Those wheels are crap. They have a large rolling radius going forwards and a minute one turning. They last about 5 mins in the real world, rattle your fillings out on concrete as you turn, jam up with everything they can and when turning on anything soft they push a wall of mud/sand/snow up and jam against it.

The whill chair is aqually useless. Which is why you never see one turn in place on anything other than smooth surfaces.

[Burgerman]

The reason this works is that it doesent have a human sat on top., and has proportionally a huge lithium battery, and a powerful roboteq controller with current sensors and lennys script with a lot of carefully configured motor load compensation, turn rates, reverse stick braking, fast turn acceleration rates and slow forward and reverse acceleration rates. etc.

Download to desktop first as its high bandwidth.

https://www.wheelchairdriver.com/gopro/bot2.mp4 video

The reason its so controllable, and can turn in place accurately and smoothly and proportionally as well as do arks of any radius under total accurate control is the load compensation, and the very complex script.

With a basic controller, elevon mixing and transmitter settings inc turn (servo) speeds and throw limiting etc it was just crap! It was at best 10% of the control it has done properly. Now with 3mm of right stick it always turns at the same rate. In a shallow turn. Or on concrete in place, on carpet, while climbing a curb etc. The motor compensation means the turn doesent need a big handful to break free and then overshoot. Its control is perfect. Regardless of grip, load etc.

[slomobile]

OK, this seems to be overwhelming project.
My goal is to built a cart with powerful wheel.
My inspiration comes from this Youtube page: https://www.youtube.com/channel/UCbazCk7W64I_IwAJG1XL7Pg/videos
Can anyone guess what type of wheel motor does they use?

https://burro.ai/robots/ motors are listed as 5 horsepower. That is equivalent to about 3,600Watts. That might be the total for all 4 wheels 3600/4 = 900W per wheel.

There are a number of ways to get powerful motor/gearbox combos.

Here is one source http://www.teamwhyachi.com/rightanglegearboxes.html these are gearboxes.
The motors they use are here https://www.ampflow.com/motors/highPerformance/
A very reliable controller is https://ampflow.com/controllers/vex/

You might be able to get by just fine with the motors and controllers you already purchased, just with smaller loads. Be sure to keep the wheels as close as you can front to back to minimize turning losses. Building that bot will get you experience and help you decide if you really want to spend more for a more powerful one. The software and high level control costs the same regardless of how powerful the motors are. So use your little motors since you have them.

Looking at Lenny's script which BM posted, it looks a lot like Visual Basic but can probably be translated and adapted to C++ for Arduino. Lots of the algorithms in it are similar to what I used on Arduino robots. I never bothered with IR compensation because I just added an encoder if I needed to control velocity precisely. You can choose what works best for you.

[LROBBINS]

Roboteq scripts are MicroBasic which is even more limited than VisualBasic. How easy or hard it will be to do in C depends on how the controller exposes its parameters. IR compensation is approximate, an encoder (or gyro) can give tight control - but, many people find that implies a loss of feel. Programming neither is particularly difficult: you need to know motor current for IR compensation and you need to fiddle with PID for encoder or gyro. It may also have to be a "tuned" PID because a chair starting a turn in place has very different dynamics from a chair turning once moving. More critical to the script, and what caused a lot of head scratching before I found a simple algorithm, was getting mixing of acceleration as well as mixing of motor speed. I really didn't understand that problem until Burgerman carefully illustrated what happens if both motors accelerate at the same rate but to different final RPMs.

[ouaburst]

OK, this seems to be overwhelming project.
My goal is to built a cart with powerful wheel.
My inspiration comes from this Youtube page: https://www.youtube.com/channel/UCbazCk7W64I_IwAJG1XL7Pg/videos
Can anyone guess what type of wheel motor does they use?

https://burro.ai/robots/ motors are listed as 5 horsepower. That is equivalent to about 3,600Watts. That might be the total for all 4 wheels 3600/4 = 900W per wheel.

There are a number of ways to get powerful motor/gearbox combos.

Here is one source http://www.teamwhyachi.com/rightanglegearboxes.html these are gearboxes.
The motors they use are here https://www.ampflow.com/motors/highPerformance/
A very reliable controller is https://ampflow.com/controllers/vex/

You might be able to get by just fine with the motors and controllers you already purchased, just with smaller loads. Be sure to keep the wheels as close as you can front to back to minimize turning losses. Building that bot will get you experience and help you decide if you really want to spend more for a more powerful one. The software and high level control costs the same regardless of how powerful the motors are. So use your little motors since you have them.

Looking at Lenny's script which BM posted, it looks a lot like Visual Basic but can probably be translated and adapted to C++ for Arduino. Lots of the algorithms in it are similar to what I used on Arduino robots. I never bothered with IR compensation because I just added an encoder if I needed to control velocity precisely. You can choose what works best for you.

Tank you for your help!

[slomobile]

Since I had said Lenny's Roboteq script could be translated for Arduino and different motor controllers, today I got started changing microBASIC to Arduino C++ putting in all the semicolons before I remembered BM said that was old code. Before I go much further, have there been updates since the John_2016_11_24 version?

Here is what I have so far.

ControlScript_ino.txt

Roboteq script WIP convert to Arduino C++

(44.93 KiB) Downloaded 24 times

[LROBBINS]

Yes, there certainly have been changes to the script. A warning though. My attention (at least for programming) is now entirely devoted to the CAN version and I have not updated the analog-only version in a long time. Except for CAN communications, however, the script's control algorithms would be basically the same for both versions.

Here's a link to the last version I put on Drive:
https://drive.google.com/drive/folders/1ysOoYG8mwlvJy0023XwJUgclYXbO1ulS?usp=sharing
There have undoubtedly been some change since then, but I'm too busy right now to do another update of the files.

[slomobile]

Thanks Lenny. The old analog code is clearest to see what is happening and why. JoystickProcedures.ino and SwitchProcedures.ino are very instructive for their tasks.

I guess what I'm thinking of is a teaching demonstrator. A spartan drive only system that can be built with hobby RC components, yet still demonstrates the drive characteristics BM is after.

On your current chair, whatever it is, unplug the motors, brakes, and battery.
Plug this basic system into the motors, brakes, and battery.
Now plug in your preferred user interface.
2 axis proportional joystick, switch array, speed pot, foot pedals, arm levers like a zero turn mower, RC, CAN, Serial, Steering wheel peripheral. Doesn't matter. In the end it delivers 2 variables Throttle and Steering (I'll add Lateral as an option for a few odd drive platforms).

The idea is a reference system any of us could replicate with a little effort from available commodity parts. Not dependent on any specific manufacturer.
Something that lets a basic user play with user settings and ride aboard safely, learning what various changes do.
Something that lets an advanced user play with the code and test new concepts.
Something that lets us share code and settings between us so we can experience what someone tried, instead of relying on language descriptions.
It serves as a backup JSM and PM in case something on your main chair breaks and you need to limp home.
It serves to bring used, backup, or first chairs when medical systems are slow responding to need.
It serves as control system for RC robot built out of your old batteries and motors not good enough for your main chair, but still have some life.
It might serve as a technology demonstrator for your CAN board set. Using the same basic algorithms, but without the necessary safety checks, manufacturability, and additional features(like seating) required for a daily use chair.

Its all make believe at this point so I'm starting with code that has already been blessed.

Rather than use my own horrible code, I'll start with yours and make it horrible along the way toward the fantasy described above.
It fills the hours I guess.
I need to figure out a better way to write code outside in my chair. Its getting nice out and I cannot see the darn screen.

[slomobile]

It should be noted that Lenny had the foresight to include this into the CAN boards
Wheelchair CANbus controller-20220325T151521Z-001\Wheelchair CANbus controller\Roboteq CANbus 2021_10_20 Release 205\ReadMe.txt

Profile WC_CAN xxxx.xml includes settings for analog joystick
and speed pot connections (AIN1, AIN2 and AIN3) for testing
non-CANbus scripts.

An analog-only version of the script is NOT included in this release and
users are urged to move to the more robust CAN system.

So, in theory at least Lenny's own hardware and software can be used with a Roboteq to serve most of the purposes described above.

[Burgerman]

That was lennys plan.

[LROBBINS]

While what you want to do sounds like a worthwhile exercise, I think you should review the motor control subroutines in the CANbus script. You certainly can accept throttle and steering as analog inputs, or most anything else, but how those are massaged to get decent behavior is the same whether input is analog or from CAN messages. In particular, take a look at these subroutines:

MotorCompensation
MixAccel
SetMotors

and all routines called from them and make sure they have not changed from the last analog-only script, or understand the changes if they are not the same.

Both MotorCompensation and MixAccel are essential, and MotorCompensation in particular depends on being able to estimate motor current reasonably well. If whatever controller is used doesn't itself provide this, you must add current sensors or the chair will be essentially undrivable. MixAccel as currently done is both simple and works well, and it may already be in the analog version you have. My first attempts at that were really, really bad, however, and shouldn't be used.

Lastly, do keep safety issues front-and-center. Remember, this is a "human rated" device, and in this case the "human" is usually someone who can't just get up and run away if there's a problem. That doesn't mean you need all sorts of bells and whistles if things like seat actuators and lights aren't needed, and simpler is often intrinsically safer, but there are some things to definitely think about. For just a few examples, what will happen if a joystick pot fails or a joystick wire comes detached? How will you protect from runaway errors or MOSFET failures? How will the system respond to electromagnetic interference? How will it deal with a motor or brake disconnect?

[slomobile]

Got it. I've thought about each of those except for electromagnetic interference.
What kind of effects can be expected from that?
How to detect it programmatically, mitigate?

When you say "motor control subroutines in the CANbus script" are you talking about the XML or something else?

[slomobile]

Oh nevermind, the .mbs file. I got it.

[ouaburst]

I did some experimentation and it worked:

https://youtu.be/tDMBHPDubCM

[slomobile]

Good on ya!
Happy to see progress. Subscribed.