Ways I could get better detection of thrust events?

ProffieOS
1

I was attempting to add some transitions that occur during a thrust. To this end I’ve defined FETT263_USE_BC_MELT_STAB so that thrusts trigger an EVENT_STAB and added transitions on EFFECT_STAB. However, the thrust seems a little unreliable (I guess it was meant mostly to trigger ignition) so I was wondering what possible paths I could take to improve it? I’m proficient in C++ code so that is not a problem.

Looking at Fett263’s prop file it appears that acceleration toward the tip for >15ms triggers a thrust event. However this doesn’t always trigger when I think it should. Also if I quickly pull back on the saber I can sometimes also trigger an EVENT_THRUST.

I considered making a second check for acceleration AWAY from the tip that occurs a short interval after after the initial thrust (50-200ms?). This might reduce false positives and allow me to reduce the current acceleration thresholds. Are there reasons this might be a good or bad idea? I read in a previous post that integrating the acceleration to estimate velocity is pretty noisy/unreliable, so I’ve skipped that idea.

2

I’ve made some adjustments to accommodate staff style dual blades (bi-directional thrust/stab detection).

Feel free to have a look

2 Likes
3

Thrust is currently only supported in some props, partially because I think the detection is too ambiguous, and partially because I don’t really want “air fencing” in my own props. (I make a distinction between controls that look good to onlookers, and controls that seem natural to the wielder, and my focus is more on the wielder than onlookers.)

However, any ideas for how to improve the detection are welcome, especially if they can also be used to improve other aspects. I’d be happy to add code for detecting thrust to the base prop if we can make the detection solid. (Even if I don’t actually want to use it myself.)

4

Ok, thanks for the background info! I’ll look over NoSloppy’s code and try to gather some acceleration data. Then I’ll have a better idea of what will or won’t work.

5

Quick update: I added some code to capture fusor telemetry and dump it to the SD card when a thrust event occurs. Here’s some initial data:

initial_thrust_telemetry
initial_thrust_telemetry762×425 26.7 KB

Looks like a positive acceleration followed by a similar negative acceleration after about 200ms. However, I think I would like to trigger the event before the end of the stab (at the deceleration) so I am going to look at getting a good velocity estimate and checking that about 50-100ms after the initial positve acceleration.

1 Like
6

Wow that is cool, thanks for playing along!

7

Another update - I added some code for a velocity estimate. Basically I just try to find the axial velocity by integrating the axial acceleration. I don’t make adjustments based on angular velocity, rotation or anything like that. I also added a slight velocity decay to avoid running off to infinity as noisy integrators are prone to do.

// update velocity estimate
if (millis() != velocity_estimate_last_update_timestamp_)
{
    uint32_t current_timestamp = millis();
    // clamp max dt at 100mS
    float dt = min(0.1f,
        (current_timestamp - velocity_estimate_last_update_timestamp_) * 0.001f);
    velocity_estimate_last_update_timestamp_ = current_timestamp;
    velocity_estimate_ += mss.x * dt;
    float decay = 0.995f; // needs fine-tuning
    velocity_estimate_ *= decay;
}

This gives me a pretty good velocity estimate - shown below is the telemetry where I stab forward (blue is axial accel, orange is axial velocity estimate)

thrust_velocityestimate
thrust_velocityestimate1548×183 28.2 KB

Seems like I can just check for a velocity over some threshold (maybe 40?) to trigger thrust events. Using this method will also avoid the spurious triggers when I yank backward to prepare for a stab. The other requirements (low transverse accel, low swing speed) will also help prevent spurious triggers in a few other cases as well.

1 Like
8

The problem I’ve always had with doing things like this is that the decay tends to mess up longer movements.

Basically, the decay ends up reducing the velocity over time, and then when you stop the movement, the integration results in a fairly large negative speed.

I’ve been meaning to experiment with a two-level integration. One that is much longer (10 seconds or more) which calculates the drift of the accelerometer and subtracts that out, then another integration which calculates the speed in a similar way to yours. The idea is that the decay can be made slower if the drift has already been subtracted out before integrating.

4 Likes
9

I agree, in my case the movement I’m trying to detect is pretty short (<300mS) so I think it will work adequately. It might also be better to use sliding window average instead of a real integrator, but I’m hoping this method (coupled with swing speed checks) will give me good results.

1 Like