Automatic turnoff fix

[Tatertot]

Howdy! I've been a lurker on these forums for awhile and I recently came to be an owner of a Huanxi h3. One, actually, the only issue I have with this wonderful transportation device  is that it accelerates, then shuts itself down once it is lifted off the ground. The issue with this is that when I skip from sidewalk to grass or vice versa, my wheel will over accelerate since I'm already going max speed so the tiniest of air that I get will cause it to over accelerate, shut down and send me flying while putting everyone around me in harms way, or, the way of a 25 pound m&m. 

How can I mod this thing so it doesn't accelerate when lifted off the ground? Or, even better, so it doesn't shut off when over accelerating?

Thanks in advance   

Tate

[Gimlet]

I think that behaviour is written into the software programing which isn't really accessible by the end user.

Does it cut if you kerb drop at lower speed or does it make contact with the ground before it's had time to spin up to the overspeed cut off stage?

[Tatertot]

I haven't tested this out yet, but I'll go try to ride it down a flight of subtle stairs in a moment and report back

[esaj]

I haven't tested this out yet, but I'll go try to ride it down a flight of subtle stairs in a moment and report back

Flight of stairs? And then we never heard of him again...

But in all seriousness, I don't think you can do anything about the overspeed shutdown, unless you have the ability to rewrite the firmware on the chip... Sounds like you're either riding too fast, or the wheel is simply too slow for you (already).

[KaleOsaurusRex]

@Tatertot

Please be careful

[Tatertot]

Oopsies, thought I posted yesterday, didn't mean to worry anyone!

I was successful in the flight of stairs on my first attempt. This thing is too fun! I wish it went like 20mph instead of a measly 9mph. Looks like it's time to invest in a faster one already haha. Thanks for your input, fellow cyclists. 

 

Actually, what would I need to overwrite the firmware on this thing? I understand it's not easy, but I have many tools at my disposal for these kinds of things.

[esaj]

Actually, what would I need to overwrite the firmware on this thing? I understand it's not easy, but I have many tools at my disposal for these kinds of things.

@jayjay23 is working on extracting the firmware from a wheel (which might not be possible, unless he can find a wheel where the image isn't read-locked). After that, it still needs to be disassembled, the correct parts need to be identified and then maybe it's possible to alter & rewrite it. Not an easy feat, and probably going to take a good while.

[robca]

@jayjay23 is working on extracting the firmware from a wheel (which might not be possible, unless he can find a wheel where the image isn't read-locked). After that, it still needs to be disassembled, the correct parts need to be identified and then maybe it's possible to alter & rewrite it. Not an easy feat, and probably going to take a good while.

 

Reverse engineering firmware from an ARM binary is truly hard and usually unsuccessful. Most of the open source firmware available for various consumer electronics usually is a from-scratch effort. Properly mapping the circuit is one of the most challenging parts, but once that's done, with modern development tools and the many resources available, it's usually faster to start from scratch

[PedalFaster]

@jayjay23 is working on extracting the firmware from a wheel (which might not be possible, unless he can find a wheel where the image isn't read-locked). After that, it still needs to be disassembled, the correct parts need to be identified and then maybe it's possible to alter & rewrite it. Not an easy feat, and probably going to take a good while.

It would probably be better to focus efforts on developing an open-source firmware from scratch, that could be well organized with a series of swappable and/or parametrizable modules adaptable to different hardware details such as MCU pin assignment, number of motor poles, MEMS sensor type, etc.

Essentially this is what is done when RC/drone people reflash their sensorless brushless motor controllers - they aren't using ripoffs of the factory firmware, they are using a better generic firmware tuned to reverse engineered details of a particular inexpensive factory board. 

 

[esaj]

It would probably be better to focus efforts on developing an open-source firmware from scratch, that could be well organized with a series of swappable and/or parametrizable modules adaptable to different hardware details such as MCU pin assignment, number of motor poles, MEMS sensor type, etc.

Essentially this is what is done when RC/drone people reflash their sensorless brushless motor controllers - they aren't using ripoffs of the factory firmware, they are using a better generic firmware tuned to reverse engineered details of a particular inexpensive factory board. 

So far the only open source self-balancing code I've found (not that I've been looking for that much really) has been this:  https://github.com/ovaltineo/SegwayClone  I believe with little work it could be tuned to work with single wheel also (as a matter of a fact, someone already did it once, with saddled & chain-driven unicycle: http://www.instructables.com/id/Electric-unicycle-Arduino-DIY/ ).

It's still the early days with EUCs, and there doesn't seem to be yet that many people with deeper know-how in electronics, dc motors and embedded programming (at least here in the forums), but hopefully the situation will change in the times to come   I myself have very little experience with those, but try to understand things better little by little.

[PedalFaster]

the only issue I have with this wonderful transportation device  is that it accelerates, then shuts itself down once it is lifted off the ground. The issue with this is that when I skip from sidewalk to grass or vice versa, my wheel will over accelerate since I'm already going max speed so the tiniest of air that I get will cause it to over accelerate, shut down and send me flying while putting everyone around me in harms way, or, the way of a 25 pound m&m. 

If a wheel is lifted off the ground, actuation of its motor will no longer have much effect on the tilt angle, so the control loop will be broken open, error will accumulate to a limit, and it is basically unavoidable that it shut down.

The only question is how quickly this occurs

If you lift a typical wheel up gently while keeping it level, error builds slowly and it will probably have time to warning beep before shutting down.

Similarly if you do a brief jump, while the control loop will be interrupted it normally wouldn't be for long enough to hit an error shutdown.

That yours seems to be shutting down immediately suggests either that there's something very disruptive about these jumps or the mass balance of the wheel such that it is actually getting into an erroneous pitch angle which control loop is trying very hard to fix.

Or else, the sensor fusion and filtering implementation is poor.   

Most wheels seem to be using an MPU6050 chip, which is both a three axis accelerometer and a three axis gyro.  Likely the program normally does something like this:

1) Use a smoothed-in-time inverse tangent of the ratio of the up-down and front-rear accelerometer readings to calculate the pitch angle of the wheel, and accelerate or decelerate the rotation rate to drive this towards the desired angle (either neutral or warning tilt-back)

2) Use the pitch gyro reading to validate or detect rapid changes in pitch angle, for example to differentiate between tipping forward/back vs the vertical displacement of riding over bumps which can likely be confused in the short term if only the accelerometers are considered.

3) Use the sideways accelerometer axis to shut down if the wheel has fallen over on its side

It sounds like the firmware of your wheel might not be using the gyro reading or might not be doing a very good job of filtering out bumps.

If the wheel were using a brushed rather than brushless motor, another possibility would be that the drop in load when the wheel comes off the ground causes overspead before the control loop can scale back the power input to the motor; but a brushless motor shouldn't exceed the speed at which the firmware is electronically cycling through the windings, so that seems unlikely.

There's also often a variation in the responsiveness of the control loop in different wheels.   Some are very "hard" in that you barely feel the pedal angle shift at all as you ride them forwards or backwards, while others are soft in that you can feel the wheel tilt a few degrees in response to your weight commands.  A very "hard" control loop would run into shutdown error much faster when the wheel comes off the ground than a slow one would. 

 

[Gimlet]

I found that the Solowheel xtreme I rode had the opposite problem in that the ride is so soft that when you do a simple kerb drop the wheel doesn't shut down but doesn't catch you either so you still end up running it off.

[PedalFaster]

I found that the Solowheel xtreme I rode had the opposite problem in that the ride is so soft that when you do a simple kerb drop the wheel doesn't shut down but doesn't catch you either so you still end up running it off.

Which seems to suggest that everything has tradeoffs.

Though it is conceivable you might be able to find a way to manipulate your weight such that you land with your center of mass more aligned over the axle so that the wheel doesn't have to do as much.

[Daan]

I found that the Solowheel xtreme I rode had the opposite problem in that the ride is so soft that when you do a simple kerb drop the wheel doesn't shut down but doesn't catch you either so you still end up running it off.

 .. but I don't have this problem with a curb drop with my Xtreme -- perhaps it is also getting used to the response of a particular wheel; having said that -- I tried a Firewheel which is super-stiff and I liked it a lot and felt it was easier than the Xtreme to navigate rough terrain. However, I also tried the Ninebot on the 1 setting (very stiff) and I found it much harder to ride well on it -- looks like there is more to it than just the stiffness setting but also the whole balancing algorithm may differ between wheels.

[Gimlet]

On a soft wheel that allows a lot of tilt before it catches up its almost impossible to keep your balance on landing a relatively small drop as you are already leaning forwards and off balance and the delay before it tries to catch up is just too great. At least it is for me.

[dmethvin]

I tried a Firewheel which is super-stiff and I liked it a lot and felt it was easier than the Xtreme to navigate rough terrain.

That's funny because I tried an IPS 121 and it was even stiffer than the Firewheel in Sport Mode, I kind of liked it! This is a good argument for having the stiffness be configurable. 

[Daan]

That's funny because I tried an IPS 121 and it was even stiffer than the Firewheel in Sport Mode, I kind of liked it! This is a good argument for having the stiffness be configurable. 

I think so too! I now have the Xtreme in 'sports' mode but it is still very soft   Now, I like that because it gives me a very smooth cruising ride and I think for small bumps in the road it is good as it smooths out the small motions. Now, when doing challenging terrain, I think that a stiffer setting is better as it helps you react faster -- the Xtreme reacts sometimes too slow to catch me and there the Firewheel did better.

Now, I must say that the Xtreme riding feel is very good; on the Ninebot the stiffness is configurable but I think it only adjusts the 'reaction time' of the wheel, i.e. the delay before it balances. But ideally, I think the algorithm should be more sophisticated, basically adjusting the algorithms to use smoother curves or something.