Ways I could get better detection of thrust events?

ProffieOS
21

But if the velocity is higher than needed, you also have to move the saber much further to trigger, effectively creating a “maximum speed”, which I suspect was not intended.

22

Any chance we could get a video clip of what these tests looks like when performed?
I feel like I might be stabbing / thrusting quite differently.
For ignition, I think I mostly do this (although not necessarily pointing angled downward)

It’s like if you had an inch of water in a glass and you toss it out. There’s a definite “stop” at the end.
Whereas a stab is more of a “run him through” motion… if that makes any sense.

23

Yeah, the motion in this video is far too short to count as a stab with my method. I’m going for the “run him through” stab with optional lunge, so the thresholds are perhaps too high.

I think i can get it to detect shorter stabs by tweaking some thresholds. Let me try some changes this weekend.

24

So, let’s say we get this working well… It’s definitely a different type of gesture than the current “stab” (which is actually hitting something with the tip of the saber.). So how do we see this going…

  1. We use this to replace the current “stab”, perhaps controlled by a define.
  2. We create a new gesture (thrust? air-stab? ??) with a new event for this? Some props call this “thrust” to separate it from stabs I think, but it’s not clear to me what we actually want.
  3. Let each prop do whatever they want.
  4. Something else??
25

Is this possibly part of the solution regarding the lack of motion detection during translation in general?

I came across that issue again, when I gave a sword buddy a saber and two movements that are super common in eastern and western sword traditions were silent to their astonishment. It’s my top wish feature, as a motion centered guy.

Edit: I’ll try it I think it’s half of it.

26

You mean straight x/y/z movement?

27

That. But curved movements without a lot of rotation also. Like lifting the saber up to block an over head strike. Some very well known kata (routines) start with a lunging thrust, then a lifting block.

Here’s the oldest example on film, since this guy choreographed the kata. It’s the first 2 movements that repeat before the next transition.

It’s also something like the german longsword guard the “ochs”…or a scoop up version to get to it.

28

Just for reference, I made my prop work like this because it works for me:

  • Hitting tip of saber to something (no button held) = melt.
  • Thrust forward when ON (and backward too when dual blades) = stab (air stab/running through).
  • Thrust forward when OFF (and backward too when dual blades) = FastOn() ignition of the blade thrusted toward. (define BC_THRUST_ON)
29

How do you stop melting something?

30

Move the saber, like start a swing away from the area.

31

This modified thrust and my melt:

32

Actually my intended use was for Wushu Sword Drills (武术剑术）as they sometimes use a light prop sword that makes a nice “snap” during a stab. Stabs typically start at/near the hip and end with a fully extended arm, which would be around 1m throw distance. That’s why my detection works only on long/far thrust motions. I could experiment with detecting 20cm or 50cm distance stabs instead.

Maybe a shorter stabby movement could replace the current thrust, but I think EVENT_THRUST is mostly used for “thrust-on”. I don’t actually use thrust-on so I can’t say if my method is a good replacement. For longer thrusts (which I’m mapping to EFFECT_STAB) it produces less false positives which is what I was after.

Here’s a video of thrust/stab distance with the props file that I posted:

1 Like
33

Nice! I see…it triggers a proper clash like event after a lunge. I like it, but it’s not what I was after, which is essentially a smooth swing like hum over movements that don’t involve enough rotation to trigger the algorithm.

It really is a nice substitute for a spring steel snap. I’ll load it up this weekend.

34

Ok I reduced the velocity/acceleration thresholds and the duration as well. This produces detection for fairly short thrusts (around 6 inches) but false positives are a bit more frequent. Here is the code I changed from the previous code post above:

    // EVENT_THRUST
    // start of thrust/stab motion
    if (sqrt(mss.y * mss.y + mss.z * mss.z) < 15.0 &&
        velocity_estimate_ > 1.0f &&
        mss.x > 3 &&
        fusor.swing_speed() < 130) {
        thrust_begin_millis_ = millis();
    }
    // end of thrust/stab motion
    if (sqrt(mss.y * mss.y + mss.z * mss.z) < 15.0 &&
        velocity_estimate_ > 0.7f &&
        mss.x < -3 &&
        fusor.swing_speed() < 130) {
	uint32_t thrust_duration = millis() - thrust_begin_millis_;	
       	if (thrust_duration < 200 && thrust_duration > 30) {
		velocity_estimate_ = 0.0f;
        	Event(BUTTON_NONE, EVENT_THRUST);
        } 
    }

Also the full updated props file:

saber_fett263_custom.h (212.3 KB)

Also note that I define #define FETT263_USE_BC_MELT_STAB in my config

Feel free to try this out and compare. Not sure what I would need to change to reduce false positives while still detecting the gestures that I want.