Gyro for controlled Wheelies

ress said:
I have no idea how well a ball tilt sensor deals with vibrations but at least the sensitivity is adjustable.
The actual sensor itself doesn't deal with vibrations well, becuase it constnatly jiggles the ball around. It would require a very heavy ball nearly vertical to gravity / g-forces to damp the vibrations much in a situation like a road vehicle.

But you can build your sensor processing electronics or program to filter out the extraneous data from the vibrations, keeping in mind that it is also going to filter out some of the position data at the same time (because the vibrations themselves override it).


FWIW, there are little ball sensors like those inside some of the bicycle turn signals that clip under your seat, and they can cause the turn signals to activate randomly if there isn't sufficient filtering of the signal from them. (like an RC time delay)
 
ress said:
I just ordered this 2 channel tilt sensor: http://www.ebay.com/itm/331399882278?_trksid=p2060778.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

You're going to have a frustrating time :/ On the upside, you can always desolder the sensors and you have a nice set of SSRs to play with.

Amberwolf is correct - these are prone to vibration and will require filtering even for simple things like 'is my bike upside down?'.

I've used these sensors to monitor a liftgate in a parking garage for things like the state of the arm (up/down) and the number of up/down cycles....pretty much the most basic application of such a sensor. Even with a slow, fixed motion - vibration was a huge hassle that overwhelms basic filtering loops. Use a Kallman filter or don't even bother.

You can get a MEMs solid state accelerometer for under $2 if you can trace your own PCB and not much more for 'breakout boards' from the usual hobby electronics vendors. In my use case, the service visits far exceeded the price of the sensor. In this case, the medical bills will be far more expensive than the sensor(s) :) if something goes wrong at speed.

At the least, I think you'll need an accelerometer package with 'dead reckoning' built into the chip. To do it the 'right way' (launch control, infinite wheelies, etc) you'll likely need to read wheelspeed on both wheels and use two accelerometers (one on the main frame 'triangle' and one on the front fork hub.

:shrug:

Edit - I don't mean to poop on your idea or anything - but this subject seems to pop up often and the suggestions are usually oversimplified. I'd also recommend doing most of the computation in a higher level language on a real linux distro ; as apposed to XYZ microcontroller. The BeagleBone/RaspberryPi/etc boards are <$40 and can be run on a small lipo (or dc-dc convertor that you might already have). The processing power will allow you to perform more complicated filtering and use better libraries. The development time will be waaaay faster (ie just SSH in vs reflashing the MCU / using your phone as a display is easier when you're passing data objects to something like a webpage verus blindly filtering UART strings with regexs or whatever / you can use your phone's accelo as a sanity check via HTML5 api calls/ etc etc). And you can use it for a whole host of other bike related IO. Anyways, that's what I'm doing....in Clojure if anyone wants to help out.
 
I think there are defo 2 trains of thought on the "best" way to attempt this .. the easy way and the hard way .. the hard way, I cant really see how it can bring anything to be a advantage over a easy way except a lot more cost and work.. i don't think a rider will ever be in a position where they are just on the bike for the ride and not to have any input whilst riding a wheelie , so you just as well try it using the easy way and see how it goes.
 
amberwolf said:
The actual sensor itself doesn't deal with vibrations well, becuase it constnatly jiggles the ball around. It would require a very heavy ball nearly vertical to gravity / g-forces to damp the vibrations much in a situation like a road vehicle.

But you can build your sensor processing electronics or program to filter out the extraneous data from the vibrations, keeping in mind that it is also going to filter out some of the position data at the same time (because the vibrations themselves override it).

adriftatsea said:
You're going to have a frustrating time :/ On the upside, you can always desolder the sensors and you have a nice set of SSRs to play with.

Amberwolf is correct - these are prone to vibration and will require filtering even for simple things like 'is my bike upside down?'.

You can get a MEMs solid state accelerometer for under $2 if you can trace your own PCB and not much more for 'breakout boards' from the usual hobby electronics vendors. In my use case, the service visits far exceeded the price of the sensor. In this case, the medical bills will be far more expensive than the sensor(s) :) if something goes wrong at speed.

At the least, I think you'll need an accelerometer package with 'dead reckoning' built into the chip. To do it the 'right way' (launch control, infinite wheelies, etc) you'll likely need to read wheelspeed on both wheels and use two accelerometers (one on the main frame 'triangle' and one on the front fork hub.

It seems like my concerns about the ball switch tilt sensor are confirmed then... :? I don't know how the sensitivity potentiometer operates, but it will certainly not be as refined as a filtering software.

A raspberry pi/arduino etc.setup will obviously open up to a whole world of possibilities when it comes to adjustments, adding more sensors, logging and so on. What do you think of a ADXL335 along with a Arduino Uno R3? I have not worked with arduino boards before, but I guess it's time to learn.

As mentioned earlier it seems like we have different ambitions for a wheelie control. :) I still think a accurate tilt sensing setup that prevent flipping over backwards will be a good solution.
 
ress said:
What do you think of a ADXL335 along with a Arduino Uno R3?

The Arduino Uno is probably best described as 'one size fits all' and will work just fine. It's when you need a smaller form factor, more UARTs, or whatever that the other boards come into play.

As for the accelo, I'd suggest against that one as it outputs an analog signal - which means you need to do more work to make it useful and it will be limited in resolution by the 'analog to digital convertor' inside the Arduino. The 'better' chips will do the analog conversion internal (and at a higher 14bit precision) and spit out a more workable I2C or SPI stream.

Looking at Sparkfun's offerings (https://www.sparkfun.com/pages/accel_gyro_guide) , it looks like the discontinued Bosch BMA180 had something called slope detection :). If you scroll down to 'IMU' you'll find sensors with >'6 degrees of freedom' which combine an accelo and gyro that result in better orientation.

But looking at the Sparkfun store, the breakout boards are really expensive for what amounts to a $<10 chip + pcb. I bought two MPU-6050 (9 degrees of freedom) breakout boards on ebay last night for $9/ea - but I'm sure shipping will take forever. If you have access to a reflow oven (or hacked toaster oven) you can get the blank PCB breakout for $5 on ebay and pick up the chip from Digikey/Mouser/etc for $10.

Sorry if this just confuses you more. The best thing to do would browse all the Arduino + Accelo tutorials and see the capabilities of various chipsets.
 
adriftatsea, it sounds like we are thinking very much the same. I still think that an arduino and this accelerometer/gyro is the way to go: http://www.amazon.com/Kootek-Arduino-MPU-6050-gyroscope-accelerometer/dp/B008BOPN40 great specs/great price/great reviews on that little baby. I would really like to tackle this soon, but have several other projects I need to knock out before starting a new one and time is limited.
 
I wish this much effort went into getting variable regen for standard controllers. I consider that to be a far more needed feature. Sure I'd love to wheelie with automatic anti-flip, but I've patiently waited for you electronics guys to give us variable force regen for 6 years.
 
Got the ball till sensor today and played around with it a bit. As adriftatsea predicted it doesn't work when vibrating. The small vibrations from the relays actually trigger the sensors when the module is places on a hard surface :lol:

The relays seems really nice though.

Megabyke said:
I still think that an arduino and this accelerometer/gyro is the way to go: http://www.amazon.com/Kootek-Arduino-MPU-6050-gyroscope-accelerometer/dp/B008BOPN40

adriftatsea said:
The best thing to do would browse all the Arduino + Accelo tutorials and see the capabilities of various chipsets.

The MPU 6050 looks really promising. I really like the fact that it has an internal processing unit (DMP) which makes the arduino programming much easier.

Found this great tutorial made by a guy making a balancing robot: http://42bots.com/tutorials/arduino-uno-and-the-invensense-mpu-6050-6dof-imu/

With some basic arduino knowledge it shouldn't be too hard to get tilt data. It would be neat to use that data to control a variable resistor (pwm?) that increasingly dims the throttle input as tilt increases.

John in CR said:
I wish this much effort went into getting variable regen for standard controllers.

Nobody's stopping you :)
 
Was in RadioShack the other day and happened to see this.. $35.

cNHY4cvwNXs2_tXqHUsxq9pPGe4395fdi9QPjM__spAy=w629-h993-no
 
izeman said:
gogo said:
BMW does it on their 200 HP motorcycles. They also have sensors for braking, lean angle, and traction control that affect the suspension rates. Such sensors would be great for front wheel drive on ebikes.
such an anti skid implementation would be quite simple: a speed sensor on the front wheel, one on the rear wheel, and if the both differ too much you slow down the driven wheel. abs for a bike is not that simple at least not w/o adding additional hardware.


I used this type of Anti-slip on three builds from 2010 on.

Not only limited slip but in hub motors, yes ABS... you do the same in reverse as traction control so when a wheel stops spinning or slows over the opposite under throttle you interrupt or in my case, modulate the throttle down using the arduino until you reach both wheels are at same rotational speed (RPM). Basically when a wheel locks or slips (causes same readings but brakes are engaged too) and depending on if ebrake cutouts are engaged you either roll back throttle or cut the regen of eBrakes out.

Hope that makes sense to you!

Regards,
Mike
 
Does anyone have a thought out approach yet?

The further one gets into trying to solve a problem like this, the more they should be looking at similar solutions. Inverted pendulum + control theory = you can make it work. Trying to hack a solution by trial and error is difficult, but could have some use.

The first thing I think needs to be sorted out is how does one control the throttle? It took me a while to figure out the throttle tamer control which is just an S curve in open loop, but this is not exactly predictable. To try and hold a position, the throttle response will need to be predictable to avoid over/under correction. If the ebrake is to be used as an anti flip, there is a delay involved as well as variable force depending on speed.
 
Hello All,

Now this is only 1/2 of the equation when working with a eBike application because we are able to link input from hall throttle to arduino and then output proper voltages (ramped) to feed back into the controller hall inputs, RC type PPM is easier to output actually but only works in RC controller applications so that part is on a case by case basis and if you want to mechanically link your throttle and brakes then the following is all you would need I suppose:

http://diydrones.com/profiles/blogs/riding-wheelies-with-my

This covers a mod done to a quad to control wheelies using arduino and a black box accelerometer setup with a triple and one single axis accelerometer and gyro combination...

If this were run on a dd rear wheel drive eBike you could couple the eBrake line in and pull it to create drag.

-Mike
 
I already have a closed loop ( working ) arduino throttle interface, that works very very well . I did originally start with a PID controller but moved away from it and done my own thing in the end ( which is a much easier to understand form of PI controller ) .

Its not that much bother to output a nice voltage to drive a controller from a arduino. The tilt sensor i have outputs a linear voltage that can be directly inputted into my arduino so it can turn down/up the throttle voltage at a fixed angle and thats about it really.. just like doing a unassisted wheelie where the rider needs to do this manually tweek the throttle the arduino will be doing it for the rider.
 
*Subscribed*

Cool thread, I really hope someone will finalize a concept and take it to market.
I will be in line for sure.

Hook up a wheelie simulator to your e-bike and you can practice in your garage in any weather to get sensors etc dialed in correctly.

[youtube]V6IDFvXpfK8[/youtube]

[youtube]9_Ygz6WcAU0[/youtube]
 
Up here!

Since you guys made me learn bits of accelerometer and dead reckoning chip here, I have a question about these. Do this kind of sensor allow weight distribution variation detections?

I have a stupid idea which lays 50% over this weight sensor thing. :lol:
 
Bear in mind that normal riding (acceleration, braking, hitting bumps, going up/down slopes) will also create large changes in front/rear weight distribution...
 
Punx0r said:
Bear in mind that normal riding (acceleration, braking, hitting bumps, going up/down slopes) will also create large changes in front/rear weight distribution...

You are right, but it is to try and exploit this weight distribution variation under these many conditions. Actually for example degrading front weight to rear to apply some kind of "traction control" could lead to a successful use of these always changing parameters :p
 
gwhy! said:
:D my tilt sensors also came today but I have had no time to play with it yet, hopefully soon.

Update : my sensor arrived ( http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718 ) I have had a bit of time to have a quick play with it..

output stability is not to bad but will also need a bit of filtering.. the spec says that it will do 0-180 degrees ( 0.5v - 4.5v ) this appears to be a big error as the total span is 90 degrees .. ( -45 to 45 degrees ) this is still usable a wheelie sensor ..
 
Hello all,

I have a chicken scratch prototype as of now it only would work with DD rear hub drives as it uses eBraking to apply reverse torque or drag as needed to not flip a wheelie. This is only on the bench wired up to a 1/10th scale model for testing only.

The trick is two accellerometers and a gyro, just like a Segway or self balancing unicycle performs.

There is alot of skew and resolution on arduino isn't great in native 10 bit mode and oversampling I am afraid takes far too long.... The end result will be the need for a few dedicated DACs and ADC which create stable and much more finite output and input resolution. That will be my next step before I actually test it on a bike.

There are still lots of unanswered questions about operation, such as do you enable wheelie sustain so you wheelie and it takes over till you let go of throttle with a maximum wheelie height, etc.

Additionally I must develop some method of engaging the rear brakes for non direct drive hub motors using a solenoid or something similar with variable tension depending upon voltage or current, still looking for this piece of hardware and still other ideas (Some really torque enabled servo mounted just above the rear brake caliper which is inline with the brake cable and offers normal operation until needed, then varying degree of braking force can be applied to control back motion.

I found this thread and figured it would be an interesting project, heck Audi did it... why not us :)

Regards,
Mike
 
gwhy! said:
gwhy! said:
:D my tilt sensors also came today but I have had no time to play with it yet, hopefully soon.

Update : my sensor arrived ( http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718 ) I have had a bit of time to have a quick play with it..

output stability is not to bad but will also need a bit of filtering.. the spec says that it will do 0-180 degrees ( 0.5v - 4.5v ) this appears to be a big error as the total span is 90 degrees .. ( -45 to 45 degrees ) this is still usable a wheelie sensor ..


If you have a single axis, you are helpless to know horizon line in an accelerating vehicle. It's like trying to reference vehicle angle of an accelerating motorcycle by knowing the angle water is sitting in a cup on the motorcycle.

This is the most simple unit I would personally bother with for attempting to maintain a concept of horizon line for an accelerating motorcycle going over bumpy surfaces.

https://www.sparkfun.com/products/10736
 
liveforphysics said:
gwhy! said:
gwhy! said:
:D my tilt sensors also came today but I have had no time to play with it yet, hopefully soon.

Update : my sensor arrived ( http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718 ) I have had a bit of time to have a quick play with it..

output stability is not to bad but will also need a bit of filtering.. the spec says that it will do 0-180 degrees ( 0.5v - 4.5v ) this appears to be a big error as the total span is 90 degrees .. ( -45 to 45 degrees ) this is still usable a wheelie sensor ..


If you have a single axis, you are helpless to know horizon line in an accelerating vehicle. It's like trying to reference vehicle angle of an accelerating motorcycle by knowing the angle water is sitting in a cup on the motorcycle.

This is the most simple unit I would personally bother with for attempting to maintain a concept of horizon line for an accelerating motorcycle going over bumpy surfaces.

https://www.sparkfun.com/products/10736

Im not thinking a long the lines of "push the button and a wheel will happen" system ,

when the sensor is 0 degrees ( with reference to the horizon )it outputs 0v and the output increases in a linear fashion upto 90 degrees ( with reference to the horizon )

well it works from +-45 degrees so the sensor will have to be mounted at 45degrees of the bike to make use of the full 90degree reading. Acceleration don't need to come into it, as its all about maintaining a fixed angle
 
The sensor if equally sensitive to forward acceleration as it is to tilting (gravitational acceleration). There's still a mechanical arm in there that acts just like a pendulum or plumb-line.

Try sliding it back and forth quickly on a smooth flat table and observe the indicated angle on the output.
 
Punx0r said:
The sensor if equally sensitive to forward acceleration as it is to tilting (gravitational acceleration). There's still a mechanical arm in there that acts just like a pendulum or plumb-line.

Try sliding it back and forth quickly on a smooth flat table and observe the indicated angle on the output.

i will give it a go.. but I don't think it still will affect its operation for what I have planned.
 
Back
Top