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.
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.)
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.
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.
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.
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)
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.
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.
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.
I have pretty good detection by estimating velocity and combining that with a two-step test:
event 1: high acceleration toward the tip and a positive velocity toward the tip
event 2: high acceleration toward the hilt and (still) positive velocity toward the tip
If these two events happen closely in time (my current code uses 60-300ms) it triggers a thrust event.
This cuts out a lot of false positives and triggers the event a little more than halfway through the thrust. This is good enough for me. I can post my props file if you’d like. I’m not sure it’s reliable enough for general use yet. In particular if your thrust is too short it won’t trigger which is maybe unintuitive.
While perhaps not perfect, this seems like a much better definition of an “air thrust” than anything we have so far. Could probably fit in pretty well with how we detect twist and shakes as well.
Ok, here’s my current custom props file. Might be hard to diff against the original (saber_fett263_buttons.h from October) but if you search for “velocity_estimate” you should find all of the relevant chunks of code.
I’ve just tried this out. It seems “reliable” at first, although a little “unlearning what you have learned” is needed when you’ve become used to the way it has been up until now.
Would you say it’s designed to have an intentional “drawback” motion first before the forward thrust? Something like drawing an arrow, where some reverse motion is required first?
I did find it more easily activated by doing it that way.
Also, I did find it to be a bit too long of a throw required, to the degree that my shoulder was just about popping out of the socket.
What value would be adjusted to shorten the throw distance?
Hm, yeah I’m tall and lanky, the total throw might be a bit long. I don’t do any drawback, but you definitely need a full-length stab to activate it.
To allow a shorter “throw” you can:
-reduce the allowed interval between start and end (I think right now it’s 60-300mS)
-reduce the axial acceleration thresholds
-reduce the velocity threshold
I would first try to the accel/velocity thresholds by 25-30% and see what that gives you.
shouldn’t start-end intervals be inversely proportional to the speed?
(If someone moves the saber faster, the interval should be shorter to reach the same distance, right?)
Hm… yes, but I’m not sure if you can produce the same accelerations and speeds for shorter-distance stabs. The given thresholds might be too high too accept a shorter/slower stab.
Some stab telemetry is shown below. I generally get about ±10m/S acceleration and 20cm/S velocity for a full-speed full-distance stab. The current thresholds in my props are ±5m/S for acceleration and the 20-17cm/S for velocity. Right now I have to work really hard to reach that 20cm/S velocity threshold.
If you stab a shorter distance you probably can not reach the 20cm/S velocity threshold. So you might be able to just reduce the velocity thresholds and keep everything else the same. My duration check is pretty generous so I think it will still work for shorter stabs.
I’m confused.
I was thinking same distance, but faster, not shorter distance.
It feels like the threshold should be more like “we travelled at least 30cm in less than 300ms” rather than “for 200ms, we travelled at least 20cm/s”, but maybe those two things are basically the same?
The velocity curve always has that gaussian bump shape, so by requiring minimum velocity I’m basically also requiring the area under the velocity curve (the distance) to be some minimum as well. I could try to actually integrate the velocity for a distance estimate, but I feel like that would be pretty unreliable - the velocity estimate is already not that great.
