Gyro for controlled Wheelies

The maths sounds complicated. How about just fiddling with the PID factors until it works correctly? ;)
 
Punx0r said:
The maths sounds complicated. How about just fiddling with the PID factors until it works correctly? ;)

the maths for a pid is complicated but if you can tune it in then it will work... but it will only be as good as the sensors allow and how fast the controller will respond ,

the hardware that im thinking about ( once you have your basic feedback loop to the throttle ) can be very easily adjusted for correct operation just by moving the sensor
 
Megabyke said:
My plan:

1. Get an arduino with an ATmega328P and $6 gyro: http://www.amazon.com/Kootek-Arduino-MPU-6050-gyroscope-accelerometer/dp/B008BOPN40
2. Wire it to override the throttle and activate regen for HT3540 DD motor via a push button switch (my commuter has quite a large battery on the rear rack which will make it much easier to find the balance point)
3. Find someone talented/crazy enough to be the test pilot and gear up for the crashes
4. Pop a wheelie close to the balance point and hit the button
5. See what happens
...
N. Extend the code to make it automagically lift the front to the balance point and maintain a preprogrammed speed when the button is pushed

It is a lot easier said than done, but I am crazy enough to consider giving it a shot after the holidays if no one else wants to be the guinea pig. I have the riding and technical skills/experience to attempt it, just not the time!

I think I could type out how to do this project, but at that point I might as well just do it since I've put the thought into it... need more time!


You can skip steps 3 to 5 above if you model the physics, you'll already know what will happen, the math will tell you. The hardest part of this project is understanding the math. I'm not going to lie, it's hard, but it's worth it to learn. I'm just starting to understand it and connect the dots. When I first started I felt like I was looking into an abyss.

Good news for anyone who really wants to do this is that there is lots of examples out there of for inverted pendulum control. You most likely won't have to do the hard maths involved. Lots of previous work to pull from.

An arduino is a good choice for this, so is a PIC or just about any micro. Personaly I'd either use an Arduino mega or stick with the new found love of TI C2000 DSPs.

Get a copy of Matlab/Simulink and learn how to use it. It helps you learn how math is connected to the real world and why things aren't always as easy as they may seem.

I think what we have going on here with this idea is that people don't quite understand the difficulty in coming up with the solution. It's important to remember that once you have an auto wheelie setup, that's just going to be for your own bike. If you want to produce and sell them, it must be able to account for all the variances in other bikes. I'm not sure if there is a way around this or not, but there are different ways to tackle an issue they can by hybrid (just like the problem).

Ok, the short short version is in order to solve this problem, one must understand exactly how complex this problem really is. If you have the dedication and love learning, this can be done. I encourage anyone who wants to create something awesome they have thought of or just want to play around with to start researching it, then try to do it, or at simpler version. Arduino is such a great way to get started in micro controller programming and they have lots of libraries (I know thehy have a PID one) that hide lots of the complexity.

I think I'm going to go type up a how to on learning micro controller or anything else that can seem daunting or nigh impossible.
 
I was thinking some thing like this would be so much better than a gyro module http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718

as it will not depend on interrupts and so much less burden on a processor ..

I may get one of these sensors after the holidays to have a play as it will plug straight into my existing hardware/software http://endless-sphere.com/forums/viewtopic.php?f=2&t=61004

and see how it behaves :)

Edit: and if dont work to well at least i can have a angle of climb /descent record for it :mrgreen:
 
...excellent G.

I can't see why this wouldn't do the trick..
 
My "old" BMW S1000RR had a 3 axis gyro which was used to allow full throttle application in a turn without lowsiding.

Here's a picture of what it looks like:

Eeki-action.jpg


While the theoretical math can get complex, it's more about getting the basic logic down and tweaking the throttle control. When first released, the S1000RR would "pogo" (front tire bouncing up and down), driving the rider nuts. What's interesting is the "anti-wheelie" control worked VERY well at the AMA level of racing (or weekend warriors like myself) but did not have as much of an impact at the factory team level such as World Superbike or MotoGP.

Not having to worry about traction control greatly simplifies the exercise. The BMW used a combination of delta between the front and rear tire rotation, coupled with a pitch axis rotation to limit front wheel lift.

Good luck with it. The arduino approach should work.

Here's a paper on modeling a Segway. Since you're only looking for any wheelie capability, you can simplify and assume the rear wheel of the bicycle is the wheel axis of the segway. The bicycle is effectively a unicycle which you don't want to have tip backwards.
 
zombiess said:
I think I could type out how to do this project, but at that point I might as well just do it since I've put the thought into it... need more time!

You can skip steps 3 to 5 above if you model the physics, you'll already know what will happen, the math will tell you. The hardest part of this project is understanding the math. I'm not going to lie, it's hard, but it's worth it to learn. I'm just starting to understand it and connect the dots. When I first started I felt like I was looking into an abyss.

Good news for anyone who really wants to do this is that there is lots of examples out there of for inverted pendulum control. You most likely won't have to do the hard maths involved. Lots of previous work to pull from.

An arduino is a good choice for this, so is a PIC or just about any micro. Personaly I'd either use an Arduino mega or stick with the new found love of TI C2000 DSPs.

Get a copy of Matlab/Simulink and learn how to use it. It helps you learn how math is connected to the real world and why things aren't always as easy as they may seem.

I think what we have going on here with this idea is that people don't quite understand the difficulty in coming up with the solution. It's important to remember that once you have an auto wheelie setup, that's just going to be for your own bike. If you want to produce and sell them, it must be able to account for all the variances in other bikes. I'm not sure if there is a way around this or not, but there are different ways to tackle an issue they can by hybrid (just like the problem).

Ok, the short short version is in order to solve this problem, one must understand exactly how complex this problem really is. If you have the dedication and love learning, this can be done. I encourage anyone who wants to create something awesome they have thought of or just want to play around with to start researching it, then try to do it, or at simpler version. Arduino is such a great way to get started in micro controller programming and they have lots of libraries (I know thehy have a PID one) that hide lots of the complexity.

I think I'm going to go type up a how to on learning micro controller or anything else that can seem daunting or nigh impossible.

You are making an incorrect assumption that because I am new to this forum that I am new in these fields. I am an engineer and have taken graduate level math courses such as Linear Algebra with Differential Equations, Discrete math, numerical analysis, etc. I am fully capable of 'understanding the math.' I appreciate the Matlab tip, but if I chose to create a programmatic simulation of this I would use Mathematica since that is my preference.

My entire point is that we don't need to waste any time modeling this because there are already great open source hardware/code solutions to start from which are very close to the answer needed here.

gwhy! said:
I was thinking some thing like this would be so much better than a gyro module http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718
as it will not depend on interrupts and so much less burden on a processor ..
I may get one of these sensors after the holidays to have a play as it will plug straight into my existing hardware/software http://endless-sphere.com/forums/viewtopic.php?f=2&t=61004
and see how it behaves :)
Edit: and if dont work to well at least i can have a angle of climb /descent record for it :mrgreen:

That's not quite going to provide enough data to tackle this problem especially considering the +/- 1 degree accuracy in the specs... at a minimum the velocity of the wheel has to be measured and incorporated into the algorithm, otherwise at best you are going to have a tremendous amount of oscillation whenever your velocity changes due to the lack of the system's capability to perfectly control the angular acceleration of the wheel (read: lack of throttle response, the precision of your tilt sensor, etc.) Even trying to hack it by using a speedo and some funky routines is highly unlikely since a wheel speed sensor is not going to have nearly enough accuracy or speed in the delivery of the data for this case.

To make this work well you are going to need to incorporate accelerometer readings on the y and z planes, as just the angular acceleration from a gyro or tilt position sensor will not be enough for the necessary trig functions.
 
Just an idea : why not use two sensors. One next to the rear wheel one next to the front one. If you then compare level and acceleration readings you should get reasonable knowing if the bike moves uphill (acc of both wheels is the same) or if the bike wants to wheelie (front acc upwards higher than that of the rear, and level is changing on both sensors differently).
 
Megabyke said:
zombiess said:
I think I could type out how to do this project, but at that point I might as well just do it since I've put the thought into it... need more time!

You can skip steps 3 to 5 above if you model the physics, you'll already know what will happen, the math will tell you. The hardest part of this project is understanding the math. I'm not going to lie, it's hard, but it's worth it to learn. I'm just starting to understand it and connect the dots. When I first started I felt like I was looking into an abyss.

Good news for anyone who really wants to do this is that there is lots of examples out there of for inverted pendulum control. You most likely won't have to do the hard maths involved. Lots of previous work to pull from.

An arduino is a good choice for this, so is a PIC or just about any micro. Personaly I'd either use an Arduino mega or stick with the new found love of TI C2000 DSPs.

Get a copy of Matlab/Simulink and learn how to use it. It helps you learn how math is connected to the real world and why things aren't always as easy as they may seem.

I think what we have going on here with this idea is that people don't quite understand the difficulty in coming up with the solution. It's important to remember that once you have an auto wheelie setup, that's just going to be for your own bike. If you want to produce and sell them, it must be able to account for all the variances in other bikes. I'm not sure if there is a way around this or not, but there are different ways to tackle an issue they can by hybrid (just like the problem).

Ok, the short short version is in order to solve this problem, one must understand exactly how complex this problem really is. If you have the dedication and love learning, this can be done. I encourage anyone who wants to create something awesome they have thought of or just want to play around with to start researching it, then try to do it, or at simpler version. Arduino is such a great way to get started in micro controller programming and they have lots of libraries (I know thehy have a PID one) that hide lots of the complexity.

I think I'm going to go type up a how to on learning micro controller or anything else that can seem daunting or nigh impossible.

You are making an incorrect assumption that because I am new to this forum that I am new in these fields. I am an engineer and have taken graduate level math courses such as Linear Algebra with Differential Equations, Discrete math, numerical analysis, etc. I am fully capable of 'understanding the math.' I appreciate the Matlab tip, but if I chose to create a programmatic simulation of this I would use Mathematica since that is my preference.

My entire point is that we don't need to waste any time modeling this because there are already great open source hardware/code solutions to start from which are very close to the answer needed here.

gwhy! said:
I was thinking some thing like this would be so much better than a gyro module http://www.ebay.co.uk/itm/LM393-Single-Axis-Tilt-Sensor-SCA60C-Tilt-Detection-Sensor-Module-For-Arduino-/400749837718
as it will not depend on interrupts and so much less burden on a processor ..
I may get one of these sensors after the holidays to have a play as it will plug straight into my existing hardware/software http://endless-sphere.com/forums/viewtopic.php?f=2&t=61004
and see how it behaves :)
Edit: and if dont work to well at least i can have a angle of climb /descent record for it :mrgreen:

That's not quite going to provide enough data to tackle this problem especially considering the +/- 1 degree accuracy in the specs... at a minimum the velocity of the wheel has to be measured and incorporated into the algorithm, otherwise at best you are going to have a tremendous amount of oscillation whenever your velocity changes due to the lack of the system's capability to perfectly control the angular acceleration of the wheel (read: lack of throttle response, the precision of your tilt sensor, etc.) Even trying to hack it by using a speedo and some funky routines is highly unlikely since a wheel speed sensor is not going to have nearly enough accuracy or speed in the delivery of the data for this case.

To make this work well you are going to need to incorporate accelerometer readings on the y and z planes, as just the angular acceleration from a gyro or tilt position sensor will not be enough for the necessary trig functions.

I appreciate what you are say but its not strictly true and very much depends on type of wheelie that you require.. e.g look at a manual on a bicycle there is no drive to the wheel and its all done with balance point/body position, why would you need the velocity of the wheel for this type of wheelie ? as it can be performed stationary :| , if you want to use the throttle only to power wheelie then the velocity may come into play , but at the moment i still cant see what advantage it will be as the balance point is what it is if you are below the balance point then you will be accelerating and if above you will be rolling off ( or you loop out ) and balance point is very dependent on body position e.g the throttle could be in a fixed position and a rider could still maintain a wheelie by using body position only . The +-1% may be a problem but as long as the loop is fast enough I think it will be workable. Wheelies are not that difficult to learn but its over coming the natural instinct to lean forward ( or reduce the throttle to early ) as the wheel comes up .. wheeling down hill is very hard to do and requires active breaking but it is very easy to wheelie up hill ( without even realizing that you are in a wheelie )
 
Megabyke said:
You are making an incorrect assumption that because I am new to this forum that I am new in these fields. I am an engineer and have taken graduate level math courses such as Linear Algebra with Differential Equations, Discrete math, numerical analysis, etc. I am fully capable of 'understanding the math.' I appreciate the Matlab tip, but if I chose to create a programmatic simulation of this I would use Mathematica since that is my preference.

My entire point is that we don't need to waste any time modeling this because there are already great open source hardware/code solutions to start from which are very close to the answer needed here.

I was just commenting that your empirical approach you listed step by step could be avoided by using first principle modeling.

What are the open source hardware/code solutions you are looking at (lots of info out there on inverted pendulums)?
Are you going to try building this?
 
gwhy! said:
I appreciate what you are say but its not strictly true and very much depends on type of wheelie that you require.. e.g look at a manual on a bicycle there is no drive to the wheel and its all done with balance point/body position, why would you need the velocity of the wheel for this type of wheelie ? as it can be performed stationary :| , if you want to use the throttle only to power wheelie then the velocity may come into play , but at the moment i still cant see what advantage it will be as the balance point is what it is if you are below the balance point then you will be accelerating and if above you will be rolling off ( or you loop out ) and balance point is very dependent on body position e.g the throttle could be in a fixed position and a rider could still maintain a wheelie by using body position only . The +-1% may be a problem but as long as the loop is fast enough I think it will be workable. Wheelies are not that difficult to learn but its over coming the natural instinct to lean forward ( or reduce the throttle to early ) as the wheel comes up .. wheeling down hill is very hard to do and requires active breaking but it is very easy to wheelie up hill ( without even realizing that you are in a wheelie )

One of the issues plaguing this discussion is that we do not have a proper set of requirements defined to wrap our heads around the same project. Since it is just stated as 'controlled wheelies' there is a lot of room for debate. You do not need the velocity of the wheel for a manual because the rider is adjusting the center of mass and its distance to the center of gravity to stay balanced.

Without rider skill, and utilizing just the information from a single tilt position sensor you must adjust the torque produced at the rear wheel against the gravitational torques trying to pull you and the bike in either direction of the balance point. As you approach the balance point, sin(θ) becomes smaller which makes the accuracy from your tilt sensor all that much more important - since that is the only variable you are using to adjust your torque. In order to reduce oscillating around the balance point, you will have to continuously measure/calculate the angular acceleration and variably adjust the motor output accordingly to eventually dial it in. When you achieve the balance point in a stationary position you will want to produce 0 torque. Things drastically change when you want to accelerate forward AND the forces acting upon your system change like wind resistance or the angle of the normal force due to a hill.

If you aren't worried about burning up your DD motor, it is definitely possible to make this work in a stationary position and maybe low speeds, but at that point as we know you have no gyroscopic help from the wheels and it is all rider skill/balance on both the X and Z anyways. How do you keep the wheelie controlled and the bike moving forward when you can not accurately account for angular momentum and rolling resistance of the tire, wind resistance, hill grades, etc. and your system is just designed to keep the bike at the balance point?
 
I am curious as to how a tilt sensor it will behave , and yes there will still need to be some input from the rider but I don't agree that it will just put you at the balance point and thats the end of the story because by lowering the front of the bike via body position then this will make the bike go faster as long as the throttle is still above the set point , or by shifting body position backwards will reduce speed to a stop if balance point is passed, rolling resistance and wind resistance will still be both accounted for .. so basically as i see it you are suggesting a complete automated wheelie control that is done still on the manually adjusting the throttle for controlling forward momentum whilst still keeping the bike at the balance point and i'm thinking of it from the other angle of using body position to control forward momentum. I have ordered one of those sensors so when it arrives I can answer my own questions as I already have the control code and hardware to try it with minimal software adjustments.
 
gwhy! said:
I am curious as to how a tilt sensor it will behave

Have you ever seen a tilt sensor in a 4x4 off roading? The reading only has any meaningful value when the vehicle is stationary.
 
liveforphysics said:
gwhy! said:
I am curious as to how a tilt sensor it will behave

Have you ever seen a tilt sensor in a 4x4 off roading? The reading only has any meaningful value when the vehicle is stationary.

No Never seen one or played with one.. if the output is that bad then agreed it will not be much use , but until i have one in hand and see the actual output of the device I will remain open minded :mrgreen:
 
Just thinking over my earlier suggestion of a two-axis accelerometer system, to negate the forward acceleration of the bike and realised it will still be affected by vertical acceleration caused by bumps/jumps. Frequency filtering may help only a little if the system is to retain a fast enough response time.

It's going to be a pain to get any system working that isn't randomly triggering due to normal offroad riding.
 
Punx0r said:
Just thinking over my earlier suggestion of a two-axis accelerometer system, to negate the forward acceleration of the bike and realised it will still be affected by vertical acceleration caused by bumps/jumps. Frequency filtering may help only a little if the system is to retain a fast enough response time.

It's going to be a pain to get any system working that isn't randomly triggering due to normal offroad riding.

yes the whole filtering thing maybe a problem no matter what system you use especially offroad ... segways are not all that off road either and they only are traveling up to 10mph and the riders mass is on the axle line
 
Hi folks,

Not on the board for long but I'm interested in this too! Maybe I have a way for you to counter hills and velocity.

I can be wrong but to limit error of calibration when straining the sensor with velocity or terrain variations, why not try a double tri axis liquid based sensor setup? Let me explain :

1)Both sensors are floating in a air tight liquid capsule under sufficient pressure as to refrain air and liquid from mixing as much as possible

2)Liquid level will move accordingly to the bikes movements and suffer from velocity's effect (falsed angle of ground position from movement for example)

3)The floating sensors will follow forcefully the liquid's pattern.

4)First sensor is assigned the task of measuring its position over the liquid. It then serves as a artificial ground position provider.

5)Second sensor then works upon the task of correcting the bike's position based on the artificial ground position provided by first sensor.

The good part in this theory :
:arrow: -gravity and density are natural calibrators for a moving liquid/gaz device;
:arrow: -liquid's position will always adjust accordingly to the bike's position, be it in uphill, downhill, acceleration, braking or cornering application;
:arrow: -always updating ground position;
:arrow: -ability to provide smoother and cleaned measures for the bike when doing a wheelie

The bad part in this theory :
:arrow: -ground position is, as I said, artificial. It can be accurate until some point, it won't be as much accurate as a real ground position but well, that's where the initial problem in this thread came from. "Good is sometimes better than best".
:arrow: -second sensor could still overreact unless it is isolated from any G force. Thus a compensation in the limit settings can be needed.
:arrow: -delay! To act properly the second sensor must wait for inputs from the first sensor. Obviously this doubles the controller's reaction time. But again if a controller can act in few ms we riders won't see the difference -or else we would not need this gyro controller.

Prove me wrong if I am, if I'm not please take time to consider it :D
 
Vanarian said:
Hi folks,

Not on the board for long but I'm interested in this too! Maybe I have a way for you to counter hills and velocity.

I can be wrong but to limit error of calibration when straining the sensor with velocity or terrain variations, why not try a double tri axis liquid based sensor setup? Let me explain :

1)Both sensors are floating in a air tight liquid capsule under sufficient pressure as to refrain air and liquid from mixing as much as possible

2)Liquid level will move accordingly to the bikes movements and suffer from velocity's effect (falsed angle of ground position from movement for example)

3)The floating sensors will follow forcefully the liquid's pattern.

4)First sensor is assigned the task of measuring its position over the liquid. It then serves as a artificial ground position provider.

5)Second sensor then works upon the task of correcting the bike's position based on the artificial ground position provided by first sensor.

The good part in this theory :
:arrow: -gravity and density are natural calibrators for a moving liquid/gaz device;
:arrow: -liquid's position will always adjust accordingly to the bike's position, be it in uphill, downhill, acceleration, braking or cornering application;
:arrow: -always updating ground position;
:arrow: -ability to provide smoother and cleaned measures for the bike when doing a wheelie

The bad part in this theory :
:arrow: -ground position is, as I said, artificial. It can be accurate until some point, it won't be as much accurate as a real ground position but well, that's where the initial problem in this thread came from. "Good is sometimes better than best".
:arrow: -second sensor could still overreact unless it is isolated from any G force. Thus a compensation in the limit settings can be needed.
:arrow: -delay! To act properly the second sensor must wait for inputs from the first sensor. Obviously this doubles the controller's reaction time. But again if a controller can act in few ms we riders won't see the difference -or else we would not need this gyro controller.

Prove me wrong if I am, if I'm not please take time to consider it :D


I think that could work.

But not as well as the tiny $5 dead-reckoning chips that do all this hard stuff for you auto-magically and weigh <1g and are robust to vibration and shock and temperatures and all that.
 
gwhy! said:
I am curious as to how a tilt sensor it will behave , and yes there will still need to be some input from the rider but I don't agree that it will just put you at the balance point and thats the end of the story because by lowering the front of the bike via body position then this will make the bike go faster as long as the throttle is still above the set point , or by shifting body position backwards will reduce speed to a stop if balance point is passed, rolling resistance and wind resistance will still be both accounted for .. so basically as i see it you are suggesting a complete automated wheelie control that is done still on the manually adjusting the throttle for controlling forward momentum whilst still keeping the bike at the balance point and i'm thinking of it from the other angle of using body position to control forward momentum. I have ordered one of those sensors so when it arrives I can answer my own questions as I already have the control code and hardware to try it with minimal software adjustments.

It seems like every person in this thread has a different view on what kind of system we want to make :)

Correct me if I'm wrong, but I think you and I have the same approach; something like a progressive 'tilt cut-off'. The sensor doesn't increase the throttle signal when the front wheel is going down, you want to be able to stop wheelying somehow, right? And if you want to stay up there, you just keep the throttle fully open, the sensor will decrease the signal it if you're going to high. The simplest solutions are often the best!

Maybe it should be mounted with some kind of anti-vibration solution? Offroad driving might still be a issue, but there's only one way to find out!
 
Some more thoughts, sorry for the wall of text :)

Maybe a progressive 'throttle decreaser' is overkill for a first test? If the alarm signal is connected to a relay that shut the throttle signal off, it should do the job. Maybe not that smooth though...

I've seen opinions on how acceleration, wind, incline, decline etc. will have an impact. I'm not sure I follow these arguments. Let's say the bike flip over when the angle increase with 50 deg (horizontal=0 deg). That means this will be the critical value, no matter what the slope is or which way the wind is blowing. In my opinion, there are three things that have a major impact; angle/tilt (obviously), your body positioning and angular acceleration.

As mentioned earlier the first is controlled by the throttle and the cut-off.

The second is controlled by your ridning style and adjustments to the sensor. I'm sure two different drivers on identical bikes have their bikes in different angles when they do wheelies since they position their bodies differently. As an example, one rider that leans forward when wheelying therefore wants his cut-off at 52 deg.

The last one is also controlled by the rider, if you raise your front wheel too quickly you will flip over due to the moment of inertia. It should be possible to add another sensor that activate the regen at an 'emergency' angle (eg 55 deg).
 
yes this is how I imagine a tilt sensor working, and should be very easy to prove or disprove if the system is going to work this way.
 
liveforphysics said:
I think that could work.

But not as well as the tiny $5 dead-reckoning chips that do all this hard stuff for you auto-magically and weigh <1g and are robust to vibration and shock and temperatures and all that.

True, but this could have a nasty functional steampunk/aeronautical look 8)

I need to look how this dead reckoning works, if it provides so much data maybe it can simulate near perfection.

Let me finish my custom first and you'll have a guinea pig here.
 
This is all good, but you need to make sure you have a direct drive system or you still will end up on your ass when playing near the balance point regardless of throttle/power control. In a mid drive or hub that freewheels, unless you can get to the rear brake in time, at some point, all is lost. Been there, more than once. :oops:
 
speedmd said:
This is all good, but you need to make sure you have a direct drive system or you still will end up on your ass when playing near the balance point regardless of throttle/power control. In a mid drive or hub that freewheels, unless you can get to the rear brake in time, at some point, all is lost. Been there, more than once. :oops:

:D

think we all have at some point..
 
gwhy! said:
speedmd said:
This is all good, but you need to make sure you have a direct drive system or you still will end up on your ass when playing near the balance point regardless of throttle/power control. In a mid drive or hub that freewheels, unless you can get to the rear brake in time, at some point, all is lost. Been there, more than once. :oops:

:D

think we all have at some point..

That's part of the fun :lol:

I just ordered this 2 channel tilt sensor: http://www.ebay.com/itm/331399882278?_trksid=p2060778.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I like that it has integrated relays (normally open and normally closed), which makes it easy to set up for a test. The sensors are ball types, called SW-520D:

651556100_529.jpg


I have no idea how well a ball tilt sensor deals with vibrations but at least the sensitivity is adjustable.

My initial plan was to use one of the sensors for throttle cut-off and one for regen. However, I just found out that my controller (Sabvoton) has a coasting regen function (no throttle=modest regen) so I might just use one channel.
 
Back
Top