Can’s Slash Analyzer v.0.1

You swing the sword. The air splits. Inside, you tell yourself, “That was a perfect cut.” You are lying. Both to yourself and to the blade.

1. The Tedium of Camera Recording and 600-Year-Old Flaws

I’ve been practicing Tenshin Shōden Katori Shintō-ryū (Kenjutsu) for a while now. It’s one of the oldest, most unforgiving schools of Japanese swordsmanship. There’s no joking around here: you can’t just swing a sword like an anime character. A katana has a cutting plane (Hasuji - 刃筋). If you deviate even 3-4 degrees from that plane, the moment a real blade hits the target, it will either snap, bend, or bounce off the target and leave you humiliated.

What was I doing before? Set up the tripod, turn on the phone, record yourself in 60 FPS while performing hundreds of suburi (cutting repetitions). Then, sit at the desk and scrub frame by frame in a video editor. (Yes, I did this occasionally. 😶)

It was absolute drudgery. After swinging the sword for a bit, I grew sick of sitting there for minutes watching my own mediocre cuts. The human brain loves to rationalize flaws anyway: “Nah, the camera angle is skewed, I don’t think that was a bad cut.”

Screw that.

One night after training, I thought: Why the hell would I sit and watch video? I’m a systems guy. I have a soldering iron on my desk, and Rust in my code. Let physics itself throw my failure in my face with millisecond telemetry.

And so, Can’s Slash Analyzer v.0.1 was born.

2. Drilling into the Kashira: Mechanical Integrity and Center of Mass Warfare

The idea was simple: mount a micromechanical IMU (Inertial Measurement Unit) and an MCU to the back of the bokken (wooden sword) and record the physics of the swing.

But real life isn’t like circuit simulators.

When you swing a sword with full force and suddenly lock it at the end of the movement (Tenouchi), dozens of Gs of shockwaves and centrifugal force slam into the hilt. You can’t just slap the circuit onto the hilt with zip ties, tape, or silicone—one hard swing and the circuit would snap off and embed itself in the opposite wall.

It had to be rugged. But it also had to be modular; I shouldn’t damage the bokken if I need to swap sensors or remove the circuit tomorrow. (Bokken prices are absurd.)

Iranian Glue and Brass M3 Inserts

I secured the kashira (the pommel end of the hilt) of the bokken.
I drilled two symmetrical holes.
I tapped in pilot guides and filled the area with Iranian glue (two-component epoxy).
I embedded two brass M3 female standoffs (screw inserts) into the holes.
I let it cure under the sun for two days until it turned into rock.

The result? Solid as a rock. Now I have standard M3 screw holes on the back of my bokken. I can attach a telemetry module, or attach weights to the back of the sword. This is what they call modularity.

The Power Struggle: Rescuing an 18650 from a Dead Shaver

The mechanics were sorted; next was power.

I said, “I’ve got a 14500 Li-ion battery I pulled from an old shaver five years ago, it’s small and light, I’ll use that.” I soldered it, powered it up. At the fifth minute, the MCU gave a brownout and died. The battery had been sitting in a drawer for five years and had chemically died, damn it. Its internal resistance had risen so high that the voltage would crash below 2.8V the second the ESP32 pulled a spike of current.

I rummaged through the drawers again. I found a solid 18650 Li-ion battery from a discarded desktop USB fan. I tacked on a protected TP4056 USB-C charging/BMS module that I bought online for pennies. (The module itself cost 14 TL, cheaper than a plastic battery holder—welcome to supply and demand, babyy)

Center of Gravity Physics

There was a lethal engineering problem here: Weight balance.

The center of gravity (CoG) of a sword should be a few fingers’ width ahead of the tsuba (handguard). If you add random weight to the back of the hilt, you ruin the pivot point of the sword. Your hand gets used to ridiculous torque when swinging, and your biomechanics collapse. I placed the 18650 battery and charging module on the bottom layer, and the ESP32-C3, OLED screen, and sensor circuit on the top layer.

The total weight increased slightly with the M3 bolts (admitted), but I kept all this mass in perfect vertical alignment with the direction of the kissaki (the tip of the sword). Zero deviation on the X-axis. The center of gravity only shifted a few centimeters back toward the hilt—meaning the wobble moment applied to the wrist is zero.

3. Sword Physics: Hasuji, Tenouchi, and Sensor Data

Let’s get to the main point of the project: How do you capture a sword cut with code?

As a sensor, I used the LSM6DS series, which is the most logical price/performance choice on the market. It has hardware FIFO, a low noise threshold, and the sampling rate is more than sufficient.

As the sword is swung, the MCU tracks three core metrics:

Hasuji (Cutting Plane Consistency): Did the sword flow in a single 2D plane, or were there wobbles and wrist twists during the swing?
Tenouchi (Kime / Locking): Did the sword lock like a razor the moment the cut finished, or did it vibrate back and forth due to a loose wrist?
Kissaki Linear Velocity ( $v_{\text{tip}}$ ): At what km/h did the tip of the sword descend?

Hasuji Calculation: AI-Generated Math and Underlying Logic

To be honest: I didn’t derive the linear algebra model here from scratch with pen and paper. I threw the dynamics of the sword movement and IMU constraints at an AI (Claude); after a few trials and iterations, this structure emerged.

Looking at the formulas, 3x3 tensors and eigenvectors look cool, but the logic behind it is actually quite intuitive:

We accumulate every gyroscope sample taken while swinging the sword into a rotational energy matrix ( $M$ ):

M = \sum_{i=1}^{N} \vec{\omega}_i \vec{\omega}_i^T = \begin{bmatrix} \sum g_{x}^2 & \sum g_x g_y & \sum g_x g_z \\ \sum g_x g_y & \sum g_y^2 & \sum g_y g_z \\ \sum g_x g_z & \sum g_y g_z & \sum g_z^2 \end{bmatrix}

When the cut is complete, the system tries to understand: “How much of the energy this guy spent swinging the sword went into a single primary cutting line, and how much did he waste on wobbling side-to-side?”

To do this, we run a small 4-step Power Iteration (PCA) on the matrix to find the dominant axis of rotation ( $\vec{u}$ ):

\vec{u}_{k+1} = \frac{M \vec{u}_k}{\|M \vec{u}_k\|}

The energy settled into the main axis is $E_{\text{dominant}} = \vec{u}^T M \vec{u}$ . When we subtract this from the total energy, we calculate the stray energy ratio ( $r_{\text{off}}$ ) and from there, the effective deviation angle:

\theta_{\text{sapma}} = \arcsin\left(\sqrt{r_{\text{off}}}\right) \times \frac{180^\circ}{\pi}

Then we score it based on human biomechanics:

$\theta \le 8^\circ$ : 92% - 100% (A+) — The sword descended on a single razor line.
$\theta \approx 15^\circ$ : 78% (B) — Not bad, but the wrist slipped.
$\theta \ge 25^\circ$ : D (Trash cut) — You’re swinging a baseball bat, not a sword.

Tenouchi: Kime and Braking Time

In sword arts, being able to freeze on target is as essential as swinging. When you finish the movement, the wrist must not remain loose; it must lock instantly.

The firmware measures the braking time ( $\Delta t_{\text{fren}}$ ) from peak angular velocity ( $DPS_{\text{peak}}$ ) down to the stopping threshold ( $DPS \le 80$ ):

$\le 80\text{ ms}$ : NET (Instantly locked, perfect kime)
$81 - 150\text{ ms}$ : MID (Acceptable)
$> 150\text{ ms}$ : LOOSE (Loose wrist, springy stance)

This calculation is still a bit problematic, but at least it’s functional for now.

Tip Speed

Assuming the effective rotation radius of the bokken is $R \approx 0.90\text{ m}$ , we extract the linear speed of the sword tip from the angular velocity:

v_{\text{tip}} = \omega_{\text{peak}} \times \left(\frac{\pi}{180}\right) \times 0.90 \times 3.6 \quad \text{km/h}

When you rotate at 1200 dps (degrees/second) at the hilt, the tip of the sword rips through the air at ~68 km/h.

4. Software & War with AI: Rust `no_std`, Embassy, and Limits

On the firmware side, of course, there is Rust.

I used no_std and the Embassy asynchronous architecture (esp-hal + esp-rtos) on the ESP32-C3 (RISC-V).

// A snippet from analyzer/hasuji.rs:
for _ in 0..4 {
    let next_x = self.sum_gx_sq * ux + self.sum_gxgy * uy + self.sum_gxgz * uz;
    let next_y = self.sum_gxgy * ux + self.sum_gy_sq * uy + self.sum_gygz * uz;
    let next_z = self.sum_gxgz * ux + self.sum_gygz * uy + self.sum_gz_sq * uz;

    let mag = libm::sqrtf(next_x * next_x + next_y * next_y + next_z * next_z);
    if mag > 1e-6 {
        ux = next_x / mag;
        uy = next_y / mag;
        uz = next_z / mag;
    }
}

The AI Code Bug

In the first drafts, the AI tried to solve everything with classic Euler angles and raw gyroscope integration. (These AIs have a tendency to do every damn thing in the most complex and convoluted way possible. Interesting.👾) When I forced the AI to use linear algebra and known Rust libraries, everything improved. AI is still not advanced enough to be left alone entirely.

Current Flaw: Linear Projection

There is a simplification I intentionally left in the current algorithm: the Hasuji calculation treats the movement as a linear plane projection. Yet, the human arm moves like a triple-jointed pendulum consisting of the shoulder, elbow, and wrist; there are natural dynamic curves in the cutting arc.

In the future, I will implement numerical optimizations to model these wobbles more accurately (Maybe I won’t, because it’s good enough for now; let’s avoid over-engineering); but even in its current state, it’s more than enough to distinguish right from wrong during training.

5. Interface and Exercise Addiction (0.91” OLED & Buzzer)

The device has a tiny 0.91” 128x32 OLED screen and an active buzzer. The interface runs in three different modes (switched via buttons):

LIVE CUTTING MODE (Live Training):
- Kamae: Take your stance.
- Countdown: The buzzer goes “beep… beep…” (2 seconds).
- CUT!: Plays a high-pitched “BEEP!” — you swing the sword.
- 5s Review: Results are instantly printed on the screen: #42 HASUJI:%94[A+] SPEED:1120dps 63km/h TENOUCHI:NET
SESSION STATS: Total suburi count, average Hasuji percentage, session speed record.
KAMAE MONITOR: Live pitch/roll angles and stance balance percentage (TILT:-10d LEAN:-113d READY! CUT!).

To be honest: I didn’t expect this level of impact.

My goal was just to measure cutting accuracy. But seeing the score on that tiny OLED screen, cutting to the buzzer’s command, and getting that feeling of satisfaction when a %98 A+ pops up has turned training into a total addiction. I used to say, “I’ll swing for 10-20 minutes for semi-sport and call it a day,” but now, because of that beep and the curiosity for the score, you end up swinging even more.

In other words, if you use technology well, it can hack you from the positive side.

6. Test & Demo Videos

Below are the demonstrations of how the device actually reacts, the interface flow, and live swing tests. I couldn’t find a proper place to steady the camera.

Live Swing and Practice Demo

Future

I’ve attached one more photo for the curious (CSI wall-penetration motion radar integrated into a pistol body with ESP32-S3). But that’s months away.

Final Word

It looks a bit mad-max, a bit cyberpunk. But as it sits on the kashira of the sword, it’s a nice feeling to have it tell me the physics of a 600-year-old tradition.

In this life, time is unfortunately limited. Hardware is just a medium for me. In these spare moments left over from social life and work, I want to engage with art more these days. My real and ultimate focus right now is elsewhere. 🤔

EOF.

Firmware repo (Rust, Embassy, no_std): github.com/caneroglu/slash-analyzer

Can's Slash Analyzer v.0.1

Can’s Slash Analyzer v.0.1

1. The Tedium of Camera Recording and 600-Year-Old Flaws