Writing software and math

I have been fooling around with a Stamp microprocessor. I would like to write a program to keep me from crashing my motorcycle.
The idea is to use a position sensor as the input and a audio warning as an output.
I would like to know when a wheelie or stoppie is going bad. The sensor would measure the Z axis rotation of the bike. As the bike is going vertical the tone of the output would get higher/louder.
My problem is that just relating the pitch of the bike to the tone would not give timely feedback. I would need to have the rate of change conveyed.
How is this done?

Assuming you’ve got a discrete input (safe assumption), just subtract the previous sample from the current one. You probably want to average the rate of change over some amount of time to get a less wobbly signal.

Thanks for working with me on this.
If I understand programing I will be writing a value to a table. Your suggestion is to read that table and compare the new value ( another table?) and write that to a third table.
The question is how a derivitive is handled.

When you are using discrete sampled values, derivatives are fairly easy. The derivative of your signal is the difference in measured value from this sample and the last sample divided by the time difference between this sample and the last sample. If you are using a fixed and constant sample rate and you call that your “1” unit of time, then you end up dividing by 1 which means you can just skip that part (which is helpful because dividing is computationally expensive).

If you just want to know the derivative value in that instant, you don’t need a table. You just store the last sample value.

In psuedo code you would end up with something like this for your sample clock interrupt handler:

current_value = (read I/O port)

This will give you a derivative value of the signal which you can then act on.

In the real world it is very rarely done this way though because you end up with jitter and aliasing in your signal due to the fact that it is sampled. Solutions to this can be fairly simple, like the averaging method that Superfluous Parentheses mentioned, or they can be very complex, like the filtering algorithms the company I work for has for it’s PID loop filtering for which they have a patent. You need to dive into some signal processing books to get into that sort of stuff. For what you are doing the averaging algorithm will probably do the trick just fine.

If you are going to average things then you do of course have to store the values that you will average in an array of some sort. A simple array used as a circular queue would do the trick easily enough.

I’m not sure if that’s what you meant by using tables.

There’s probably going to be some noise in your position sensor. So if you use the raw data you might get glitches that make it seem like the position of the bike is jerking around, even though it’s rotating smoothly.

This is usually handled by averaging the raw data over multiple samples. That way any noise gets smoothed out. The trick is finding the right number of samples for your purposes. If you average over too many samples, the response of the system will be sluggish. If you average over too few it will be noisy and jerky. You’ll need to experiment to find a balance.

I would do it by creating a table with a pointer that points at the oldest entry. Each time you get a new piece of raw data, save it to the table overwriting the oldest entry. Then advance the pointer. When you get to the end of the table, wrap around to the beginning. That way the table will always contain the last 4 or 8 or 20 readings from the sensor – however many you need to smooth out the data.

After you update the table, sum all the entries to get your current average position. Save this data in a variable. The next time you’re ready to update the table, first copy the “current position” variable to an “old position” variable. When you get your new current position by averaging the table, you can subtract the old position from it. This will give you the rate of change.

One other thing you need to do to make this work: You must be taking your samples at regular time intervals. This will mean either monitoring the system clock to determine when you sample, or driving your routine off a hardware interrupt. If for some reason you can’t sample at regular intervals you’ll need a more complicated program that saves time stamps along with your raw data and factors that information into the rolling averages you’re calculating.

Another possibility is to use a second analog input, and drive that input from the tilt sensor coupled through a capacitor, and also short the input with a resistor. This forms a differential signal.

However, there is perhaps a bigger issue. I once worked a little with somebody on a microprocessor crane tipping prevention device. It is surprisingly hard to do this well, though. You can picture having the boom pointed almost straight up, and using the cable to lift a heavy load that is close to the base of the crane, and raising this load pretty high. Then, you start lowering the boom. This can create a completely unrecoverable situation in which everything still feels fine. The problem is that stopping the boom requires overcoming its angular momentum and that of the load, which may be more torque than it takes to topple the base. However, letting the boom continue moving will suspend the load further and further from the base, so that it will reach a distance at which it can’t be held, much less stopped. On a large crane you could have quite a few seconds during which disaster is inevitable but also during which all the loads are perfectly comfortable. Moreover, during the seconds before disaster is inevitable, the options for avoiding it are rapidly narrowing and increasing in their demand on the operator’s skill, so this whole deal has to be sensitive to that skill level. It seems to me your motorcycle problem may be similar. Which is certainly not to say that a computer can’t do it just fine, but rather to say that the math could be pretty complicated.

This is the help that I need to make progress.

Thanks for pointing this out. One would like to believe in easy answers ,but…

Since the motorcycle problem only needs one axis of conrtrol ,I hope that it is not as big of a project as crane control.
Thanks for the input.

If your sensors are perfect, there’s no need for a table. I’ll try to explain the method:

Your sensor will read the Z distance (how? I don’t know, this is how you posited the question). The results will come in every 100 milliseconds. Let’s say the results are in meters:


The rate of change is (and note the ROC is only dependent on the currently last value, not on a large table):

0.5 = ?
0.65 - 0.5 = 0.15
0.8 - 0.65 = 0.15
0.6 - 0.8 = -0.2

From the results you can see that for most of the time, you’re moving up, and only at the last sample, you’re moving down. The reason I suggested storing more than 1 sample at a time is that I think that just driving on an uneven road would bump your vehicle every which way, and averaging out would help prevent false positives.

Reading back over the OP, I find myself wondering about the phrase “position sensor”. How exactly are you planning on measuring the angle of the bike? Depending on the sort of sensor you use, you’ll need to massage the raw data in different ways.

You want to measure rotation, which means you need to sample both X and Y and do some trig to get the current angle (X being along the axis of the bike, and Y being straight up). I don’t know what you are going to program the stamp with, but you might want to use a lookup table to speed these calculations up.

What a great project idea. But why do you want the rate of change again? I don’t understand your timely feedback argument. What you need is just the tilt. You brain will process its derivative as feedback. The ideal signal would be a continuous measure of tilt that would switch into an intermittent warning when going over the balance point (with a small extra allowed so you can develop feel without developing tolerance for the warning), signaling you to correct with the back brake. The rate of change at the balance point on a perfect wheelie is zero.

Compute an estimate of the center of mass with your balance point riding position, compute balance point angle based on bike geometry, design/buy inclinometer, code, test, correct, profit. What a great project idea.

Continuing with my tangent to the topic*, this is a problem that is begging for an analog circuit solution. It will be simpler, cheaper, faster and use less power. The drawback is that your ability to tune the system on the field will be much more limited.

  • well, depending on whether you are more interested in wheelies or microprocessors, that is

Moved to GQ from MPSIMS.

I haven’t really considered the circuitry much, but my first thought is that I would disagree with that.

He wants to factor in not only the tilt, but the rate of change of the tilt so that if it starts to change faster he gets more of an alarm (keeping the bike steady at a 45 deg angle isn’t so much of a problem, rapidly going from 35 to 45 deg means the bike is starting to flip, I suppose). You are talking about a proportional signal and a differential signal, so some capacitors and an op-amp or two, with the potential for feedback oscillation and all other sorts of problems that you need to design around. It’s a lot of discrete parts and a lot of tweaking trimpots and such to get it to work.

You can do the differentiation, filtering, and mixing all in software, and those little stamp processors are dirt cheap.

Of course, you do have other things that you have to be careful of by doing it all in software, and actually I think it will be easier to modify the analog circuitry in the field since you’d just be adjusting trim pots and maybe a variable cap.

Personally I’d be more inclined to do it in the digital world, but then that’s what I do for a living so I might be a bit biased. One of the old analog engineers I used to work with used to make fun of me because I always wanted to stick a microprocessor into everything.

Maybe you’re right. I’m more of a digital guy myself. And I was thinking it’s easier to press buttons or at worst recompile some software vs fiddling with knobs or ordering the right parts.

I do think using differential feedback is wrong here. That would be more appropriate to design an automatic wheelie controller, that’s not what this is about.

I was considering a transducer and low-pass filter, with some added logic using a comparator for the flip-over warning. Very basic stuff, not worth doing A/D and D/A conversion for, plus amortizing the likely higher programming initial time cost.

Just to drive this point home, much of the challenge of wheelies is in the non-linearity, that is, it takes much more thrust to rotate through 5º from the ground than from a 45º angle. Also having good coordination and sensibility. That takes practice because it’s not a very natural feeling to be flipped back on a motorcycle. The way I see the OP’s excellent idea is that our ears are much more effective at measuring pitch than our eyes and hears at measuring tilt, and they become one and the same, with the added safeguard of the flip over warning, when you are past the point of no return and only the back brake or engine break can bring you back to the land of the healthy living.

Even if you could benefit from a PD input, you’d still have problems controlling your wheelies or stoppies without it, since that is basically what a human stuntman does, closing the feedback loop with your wrist, foot and brain.

“Available for under $3, the ITG-3200 delivers breakthrough motion processing technology for gaming and 3D remote controls.”
That was from a google search for a digital gyro. There are many out there.
Thanks for the help guys (gals?). Right now this is more of a thought experiment than actual project. I wanted some input to see if it was practical.
As an aside, I know that more seat time would help me develop the mad skilz to stunt ride. I just dislike making contact with the road.
Some time ago I went to Road America to watch the bike races. After the race was over some riders would come into the slowdown area before a turn, brake too much to lift the rear wheel, and crank open the throttle so the rear tire would start smoking. It looked cool so I thought I would try it.
The next ride out I was going 60 mph, got to be going fast because the front brake on my Buell is pretty good at scrubbing off speed, and I grabbed a handful of brake while cranking the throttle open.
The front wheel locked up with a screech and I almost crashed. Dumb.

I guarantee you some of those racers have flipped bikes and landed on their asses. But don’t be that guy or go at it like a moron. You need to ease into this stuff and understand what you are doing and be as safe as possible, especially to others.