WillChair Three - Let's Build it!

[Williamclark77]

Also, on the newer "A" versions of the HBL23xx controllers I'm using, direct from the datasheet:

HBL23xx models include Amps sensor in line with the battery ground wires. Battery Amps are therefore measured with precision. Motor Amps are estimated using the formula Motor Amps = Battery Amps / PWM. This formula produces accurate results from 20% PWM and above. No Motor Amps are reported at 0% PWM.

HBL23xxA models include Amps sensors in line with the motor terminals and on the battery ground terminals.
On these models, both Motor Amps and Battery Amps are therefore measured with precision.

[LROBBINS]

The script you were testing then is still current - I may have uploaded some very minor, essentially trivial, changes, but nothing of any substance. However, you never did tell me whether the last one you were testing back then was working as it should.

[Williamclark77]

I thought I did. My apologies. Yell at me! I'll try it as soon as the opportunity presents itself, maybe this weekend.

I was under the (limited research) impression an RS232-TTL like this one from Roboteq would work

https://www.roboteq.com/index.php/accessories/372/rs232-ttl-adapter-detail

and I would use the serial print command in the script instead of an analog pin command to output to the Arduino. I would need a Mega instead of Uno since the Uno only has one set of Tx/Rx pins and the touchscreen needs them. Is there much more to it than that? (the newer Roboteqs don't require an adapted but I'd rather use an adapter than diodes and resistors on wires for durability). That wouldn't add any more wiring, only more connections since I'm using twisted/shielded network cables for communication and few aren't used anyway.

[LROBBINS]

I'll try it as soon as the opportunity presents itself, maybe this weekend.

Thanks. I look forward to seeing your results. With John out of action so much and involved with so many other projects, the BM3 has been sitting a long while with no script testing. I've also had little feedback from other users.

I hadn't seen that Roboteq is now selling a TTL - serial adapter. That should work. Be cautious about sending frequent serial messages - enough of them and it can interfere with the script, even to the point of causing Roborun to disconnect from the controller. That may or may not happen if not using Roborun, but you do need Roborun for diagnosis and testing at least.

[snaker]

The main mechanical build portion is pretty much done. I'm trying to work on the hard (hard for me anyway) part of figuring out how to make the Roboteq output integer values for speed, odometer, and battery info to send to an Arduino Uno to show up on the touchscreen. I can figure out the math. The actual syntax to get it to work though, not easy for me. I'll have to dig through Lenny's script for inspiration. He's a genius at this stuff. I'm more the longer I stare at it.

Does the roboteq already output those values (speed, odometer, battery) to outside (i.e through a serial port) and do you actually want to show them on a screen?

[Williamclark77]

Does the roboteq already output those values (speed, odometer, battery) to outside (i.e through a serial port) and do you actually want to show them on a screen?

These values are always available inside the Roboteq. I THINK you can query the data through serial from the Roboteq as well as output the data over serial from the script. I have not decided which will be best yet. I am not a programming expert.

And yes, I want to display these values on a touchscreen and use it to control functions like accel rate, top speed, headlights, and horn by touchscreen instead of hardware buttons and potentiometers. That will reduce wiring and failure points by a significant amount. I know how to do everything except getting information from the Roboteq.

This is how it looks as of now. Non functional, just drawn. I'll make it pretty later.

[Vitolds]

I use Roboteq and RS 232 ttl.
I read the speed, voltage, errors.
On Arduino I record the odometer, the daily odometer.
Display on the screen Nextion. I use arduino mega.
On new controllers, you can without a convector, but you need to invert the signal, on older ones with a convector (you do not need to invert the signal).
https://ru.aliexpress.com/item/RS232-tt ... 3c00V4sw3s
it works great.

[Williamclark77]

I use Roboteq and RS 232 ttl.
I read the speed, voltage, errors… ..

Thank you very much for posting. That is very encouraging! You should share pictures of your builds.

[Vitolds]

I will try to show you soon.
While there are problems with the GBL controller and BMS roboteq.

[rustyjames]

Just checked out your website, Will, and have to say those knives are handsome. You need to manufacture a knife for us with feeble hands to use for cutting a steak . I've tried those rocker type knives but with less than stellar results.

[Vitolds]

very short
use mini mega
https://ru.aliexpress.com/item/Mega-256 ... 926b184f-2
I also use non-volatile memory, like this.
https://ru.aliexpress.com/item/MB85RC25 ... 0000000000
touch screen
https://ru.aliexpress.com/item/Nextion- ... df3b386d-0

[Williamclark77]

How do you communicate with the Roboteq and Nextion? The Mini Mega shows to only have one serial channel. I have already designed and built a joystick housing around the Uno before I realized I had to use serial on the Roboteq.

Rusty, everybody's function and needs are too different. I've yet to see anything that would be easier than a plain straight handle for me to use. Draw something up that'll work for you and send it to me. No need for a professional drawing. A hand sketch will do.

[Vitolds]

https://robotdyn.ru/upload/PHOTO/0G-000 ... ga2560.pdf

[Williamclark77]

https://robotdyn.ru/upload/PHOTO/0G-00005642==MEGA-PROMINI-ATmega2560/DOCS/PINOUT==0G-00005642==MEGA-PROMINI-ATmega2560.pdf

I see the others now

Thank you.

[Williamclark77]

Lenny, I downloaded "analog 2018_12_06 AccelPot added" from your Google Drive link you sent me and tested today while on the jack. There are still accel issues that are unpredictable. One time it may slowly accel then oscillate while wide open; the next it may only accel to a random amount, say 30%, and hold that steady even with the joystick full forward; the next it may accel for a moment, drop to almost zero, then fully accel. It does not follow the joystick. Turning seems to work correctly now.

I also tried setting accelpot and speedpot to false to rule them out. No change.

See screenshot. It is random.



It looks like a janky wiring connection but it is not hardware. The input voltages are steady nor does it behave erratically with the script disabled or the one I use. If you do updates in the future and I test I will send them by email or reply in your thread to keep the relevant information organized.

[Williamclark77]

These are the pins for the docking mechanisms I designed and built in my car. They go in the sideplates and do not affect ground clearance. They press into that hole then were welded hot from both sides. They were done last so that I could put the chair in my car and confirm the locations would work before welding.





Much of it got coated with pretty today. Crap Iphone picture (not mine. I can't stand Apple stuff but I busted the lens on my phone and not worth digging out the dSLR gear).

[Vitolds]

I use a brushless controller, 48 volts, the right gearbox.
If I completely turn off the compensation, I still turn around on the spot.
I had such fluctuations! When moving forward. From 40 to 140 motor commands.
Acceleration and deceleration should be set below. It helped me.

[Vitolds]

Why do you have such a big difference in speed between the motors? Motor commands 240-238, speed 4065 and 3333

[rollingcowboy]

docking mechanisms I designed and built in my car.

would like to know more about that - is it already in a thread somewhere?

nice color blue!

[rollingcowboy]

docking mechanisms I designed and built in my car.

would like to know more about that - is it already in a thread somewhere?

nice color blue!

[LROBBINS]

Will,

I compared my copy of "analog 2018_12_06 AccelPot added" with my latest plain analog script. I also compared my current analog script with archived versions, and the same for the last "AccePot added" script with archives of those. There are some differences between the "AccelPot added" script and the plain analog script. Most are just user settings such as pin assignments that are clearly irrelevant to this instability, but there were three differences that might be contributing.

You have MotorResistance = 75 while I have MotorResistance = 50 -- you may have too much compensation.

You have LowIBoost = 50 while I have LowIBoost = 0 -- this may cause overcompensation at very small stick especially in combination with MotorResistance = 75. I'd start with it set to 0 and only add some (with caution) if you need more compensation at low stick.

BUT, most importantly your StickSensitivity: subroutine has quite a few differences from mine, and that different StickSensitivity coding matches with archived versions of the "AccelPot added" script. Thus, I think that when I edited the "AccelPot added" script several versions back to include the analog updates I missed making the changes to StickSensitivity: and that lack carried over through all newer versions. I have not tried to figure out whether these differences could make things unstable, but that subroutine has enough differences that I think you should replace it with mine. I've attached a StickSensitivity.txt.zip file with the proper version of just that subroutine. Take off the zip suffix, open it in a text editor and copy/paste it into your script in place of the existing subroutine.

There is also one thing that is not different between our scripts, but that might be contributing. Accel = 9000 in both, but the Roboteq's meaning of acceleration is different for brushed and brushless motors. For brushed, it is change of PWM over time, for brushless it is change of RPM over time. 9000 may be much too high.

Vitold may be pointing to some of the same compensation and acceleration problems, but I've not seen his script nor a detailed description of the problems he found, so it's hard to know.

I think that this script testing should be continued on the board rather than moved to e-mail: what you find may be important for other users as well. It may be best to start a separate thread, however, for script testing rather than confusing the Willchair Three thread.

What would be worth doing via e-mail is to send me copies of the script you just tested (so that I can compare it with the one I have) and of your configuration profile file (so I can see if I might spot some brushless specific settings that might be causing a problem).

Ciao,
Lenny

[Vitolds]

hi Lenny
I can send you a profile and a script that I use. GBL 2660 controller. Roborun 2.0
9000 acceleration is not just fast, it's an airplane ...
I have a controller for a brush motor, for it I accelerate more.
Will installed powerful motors and gearbox, he needs to reduce MotorResistance .
I always wrote that the gearbox is an important part, yesterday I installed a weaker gearbox.
I could not make a turn on the spot with any compensation setting.
Another important point is the Sinusoidal or Trapezoidal mode.

[Williamclark77]

Vitolds, This was testing Lenny's latest script in it. I do not use it daily.

Lenny, I did not modify any of the settings from how it was downloaded except disabling speedpot and accelpot (I did confirm pin settings). I will try it again at some point over the next week and reply in the Roboteq thread. It will get lost if posted here.

Why do you have such a big difference in speed between the motors? Motor commands 240-238, speed 4065 and 3333

I should have reset the values to 0 before doing the graph and screen capture.

docking mechanisms I designed and built in my car.

would like to know more about that - is it already in a thread somewhere?

nice color blue!

Thanks. It'll all be beat up within a month of use and camouflage looking anyway. This chair is destined for a very hard life.

I THINK I posted pics of the docking mechanism as well as a way to make the EZ Lock bolt retractable quite a while back. I don't believe there was any interest so I never followed further.

[LROBBINS]

Vitolds,

All of the things you mentioned are important:

gearcase - the higher the gear reduction, the lower the top speed, and the greater the torque. The higher the torque, the less need for motor compensation for turn-in-place, though it may still be useful for maintaining near constant speed and direction on varying terrain.

Accel = 9000 is very high even for brushed motors. It's what Burgerman wanted, but he's a master of fine joystick control. Brushless may be very, very different because the Roboteq calculates acceleration so differently for the two kinds of motors.

Sinusoidal vs. trapezoidal may make a big difference at low speeds. It also depends on how sinusoidal is done. If you have an encoder (or resolver etc.) as well as Hall sensors, it can be smooth even at the lowest speeds. If you have just the Hall sensors, it really will be like trapezoidal at low speeds. With sinusoidal you can also implement field oriented control which can increase effective power and efficiency at all speeds.

Please do send me your files by e-mail. Even though I don't know when I'll have time to look at them the better the record of user experience, the better able we'll be to get things tuned right.

Will,

Please don't do any testing until you put in the correct StickSenstivity: sub-routine.

The user settings in that script came from your old scripts plus some suggestions for parameters that are new (do read the comments for each user setting). They almost surely will need to be tuned. The CANbus user's manual at Google Drive has a section with a suggested tuning procedure (at page 26), and almost all of it is applicable to the non-CAN setup even though the user settings are in the Roboteq script instead of in the Master module's program. Tuning parameters out of order can make it very difficult to find the right balance.

[Burgerman]

It's what Burgerman wanted, but he's a master of fine joystick control.

Not just for me. Its perfectly controllable for all. My carers can easily drive.

[LROBBINS]

If I set accel anywhere near 9000 on Rachi's chair that I drive with an attendant stick while walking alongside it would be absolutely uncontrollable. I have it set at 2000 (decel = 3000).

[Burgerman]

Maybe different motors respond differently. But set that slow, I cant hit a doorway. Unless I slow down to try and get it to point where I tell it to.

[LROBBINS]

It may also be because the current version of the program does approximately linearize physical acceleration (rather than Roboteq's change in PWM per unit time) and you never got to testing that. Last working version you had gave sluggish starting acceleration unless mid-run acceleration was set high. That's also not a problem with brushless because Roboteq does have accel = change of speed per unit time for brushless (it increases commutation frequency instead of PWM).

[Williamclark77]

Bearing caps for the caster barrels. I didn't take any pictures machining.





A few minutes in the lathe with some steel wool and Scotch Brite pads later



A video making the ones for W2. Theses were made pretty much the same way.

https://youtu.be/dUPs1kCrN9E

[Williamclark77]

On Arduino I record the odometer, the daily odometer.

Do you mind me asking what value and formula you use for odometer?