DEV Community: Takeo

Trying VLA (Part 4): Testing Teleoperation from the Command Line

Takeo — Thu, 03 Sep 2026 03:03:05 +0000

Trying VLA (Part 4): Testing Teleoperation from the Command Line

In the previous article, I completed the assembly and calibration of the LeRobot SO-101.

https://dev.to/takeofuture/trying-vla-part-3-finally-assembling-lerobot-from-joint-2-to-calibration-3g79

This time, I will send commands to each joint individually and check whether the robot moves correctly.

First, let's check the current state of the robot.

Before doing that, connect the control PC to the Waveshare board on the LeRobot arm, and connect the 12V power supply as well.

For safety, I also keep the robot arm folded before starting.

Next, activate the Python virtual environment.

$ source ~/pyenv/lerobot/bin/activate

Now, let's check the current position of each joint.

This time, I will run the Python code directly from the command line. Of course, you could also save the same code in a Python file and execute it.

(lerobot)$ python - <<'PY'
from lerobot.robots.so_follower import SOFollower, SOFollowerRobotConfig

robot = SOFollower(
    SOFollowerRobotConfig(
        port="/dev/ttyACM0",
        id="takeo_so101",
        use_degrees=True,
    )
)

robot.connect()

try:
    obs = robot.get_observation()

    for name, value in obs.items():
        if name.endswith(".pos"):
            print(f"{name:22s} = {value:.2f}")

finally:
    robot.disconnect()

PY

If everything is working correctly, you should see values similar to the following:

shoulder_pan.pos       = 5.67
shoulder_lift.pos      = -102.59
elbow_flex.pos         = 97.63
wrist_flex.pos         = 22.77
wrist_roll.pos         = 2.07
gripper.pos            = 20.16

One thing worth mentioning here is what happens after calibration or after running a Python script that only reads the joint positions.

At that point, you can still move the arm manually.

However, if the arm is extended forward, it may suddenly drop downward under its own weight.

This happens because the default setting is:

disable_torque_on_disconnect=True

When the robot disconnects, the servo torque is turned off.

As a result, joints such as shoulder_lift, elbow_flex, and wrist_flex can no longer hold the weight of the arm against gravity.

The SOFollower follows this setting and disables torque when it disconnects.

Now let's create a small script that moves each motor only a little so that we can verify that every joint works correctly.

Testing Each Motor

Create the following file:

test_motor.py

#!/usr/bin/env python3

import sys
import time

from lerobot.robots.so_follower import SOFollower, SOFollowerRobotConfig


JOINTS = {
    1: "shoulder_pan.pos",
    2: "shoulder_lift.pos",
    3: "elbow_flex.pos",
    4: "wrist_flex.pos",
    5: "wrist_roll.pos",
    6: "gripper.pos",
}


def print_positions(title, obs):
    print()
    print("=" * 55)
    print(title)
    print("=" * 55)

    for motor_id, joint in JOINTS.items():
        value = obs[joint]

        if motor_id == 6:
            print(f"ID{motor_id}  {joint:20s} = {value:8.2f}")
        else:
            print(f"ID{motor_id}  {joint:20s} = {value:8.2f} deg")

    print("=" * 55)


def main():
    if len(sys.argv) != 3:
        print("Usage:")
        print("  python test_motor.py MOTOR_ID DELTA")
        print()
        print("Examples:")
        print("  python test_motor.py 1 5")
        print("  python test_motor.py 2 -2")
        print("  python test_motor.py 6 5")
        sys.exit(1)

    motor_id = int(sys.argv[1])
    delta = float(sys.argv[2])

    if motor_id not in JOINTS:
        print("ERROR: MOTOR_ID must be 1 - 6")
        sys.exit(1)

    # Do not move the joint too far during the initial motion test.
    if abs(delta) > 10:
        print("ERROR: For safety, DELTA must be between -10 and +10.")
        sys.exit(1)

    joint = JOINTS[motor_id]

    robot = SOFollower(
        SOFollowerRobotConfig(
            port="/dev/ttyACM0",
            id="takeo_so101",
            use_degrees=True,
        )
    )

    robot.connect()

    try:

        # -------------------------------------------------
        # 1. Read the current positions.
        # -------------------------------------------------

        robot.bus.disable_torque()

        before = robot.get_observation()
        print_positions("BEFORE", before)

        current = before[joint]
        target_value = current + delta

        print()
        print(f"Selected motor : ID{motor_id}")
        print(f"Joint          : {joint}")
        print(f"Current        : {current:.2f}")
        print(f"Delta          : {delta:+.2f}")
        print(f"Target         : {target_value:.2f}")
        print()

        # -------------------------------------------------
        # 2. Set the current position as the goal position
        #    for every motor.
        #    This prevents sudden jumps when torque is enabled.
        # -------------------------------------------------

        hold_action = {
            name: before[name]
            for name in JOINTS.values()
        }

        robot.send_action(hold_action)

        input(
            "Support the arm and make sure it is safe.\n"
            "Press ENTER to enable torque and move the motor..."
        )

        # -------------------------------------------------
        # 3. Torque ON
        # -------------------------------------------------

        robot.bus.enable_torque()

        time.sleep(0.5)

        # -------------------------------------------------
        # 4. Change the target only for the selected motor.
        # -------------------------------------------------

        action = hold_action.copy()
        action[joint] = target_value

        print()

        print(
            f">>> Moving ID{motor_id} "
            f"{joint}: {current:.2f} -> {target_value:.2f}"
        )

        robot.send_action(action)

        # Wait briefly for the motor to move.
        time.sleep(2.0)

        # -------------------------------------------------
        # 5. Display the position after the movement.
        # -------------------------------------------------

        after = robot.get_observation()
        print_positions("AFTER", after)

        print()
        print(f"Requested target : {target_value:.2f}")
        print(f"Actual position  : {after[joint]:.2f}")
        print()

        input("Press ENTER to disable torque and exit...")

    finally:
        robot.disconnect()

    print()
    print("Torque OFF / disconnected.")


if __name__ == "__main__":
    main()

Now let's actually run it.

I tested each motor using the following commands:

# ID1: Shoulder pan, +5°
python test_motor.py 1 5

# ID2: Shoulder lift, +2°
python test_motor.py 2 2

# ID3: Elbow, -5°
python test_motor.py 3 -5

# ID4: Wrist flex, +2°
python test_motor.py 4 2

# ID5: Wrist roll, +5°
python test_motor.py 5 5

# ID6: Gripper open/close, +5
python test_motor.py 6 5

When you run these commands, each motor moves only a small amount.

For Motor 3, I used a negative value to move it in the desired direction.

Also, once torque is turned off, the arm drops again under gravity.

During actual teleoperation, we normally keep the torque enabled so that the robot can maintain its posture instead of collapsing under its own weight.

Here are the actual results from my tests.

Motor 1: Shoulder Pan

(lerobot)$ python test_motor.py 1 5

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    10.33 deg
ID2  shoulder_lift.pos    =   -91.60 deg
ID3  elbow_flex.pos       =    98.15 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID1
Joint          : shoulder_pan.pos
Current        : 10.33
Delta          : +5.00
Target         : 15.33

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID1 shoulder_pan.pos: 10.33 -> 15.33

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -91.60 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Requested target : 15.33
Actual position  : 15.08

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

Motor 1 moved from 10.33° to 15.08°, very close to the requested target of 15.33°.

Motor 2: Shoulder Lift

(lerobot)$ python test_motor.py 2 2

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -91.60 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID2
Joint          : shoulder_lift.pos
Current        : -91.60
Delta          : +2.00
Target         : -89.60

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID2 shoulder_lift.pos: -91.60 -> -89.60

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.67 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Requested target : -89.60
Actual position  : -89.67

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

Motor 2 also reached almost exactly the requested position.

Motor 3: Elbow Flex

(lerobot)$ python test_motor.py 3 -5

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.67 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID3
Joint          : elbow_flex.pos
Current        : 97.89
Delta          : -5.00
Target         : 92.89

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID3 elbow_flex.pos: 97.89 -> 92.89

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    14.99 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    95.08 deg
ID4  wrist_flex.pos       =    24.88 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Requested target : 92.89
Actual position  : 95.08

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

Motor 3 also moved in the expected direction, although the actual position did not reach the requested target as closely as some of the other joints.

Motor 4: Wrist Flex

(lerobot)$ python test_motor.py 4 2

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    98.07 deg
ID4  wrist_flex.pos       =    25.05 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID4
Joint          : wrist_flex.pos
Current        : 25.05
Delta          : +2.00
Target         : 27.05

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID4 wrist_flex.pos: 25.05 -> 27.05

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    26.73 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Requested target : 27.05
Actual position  : 26.73

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

Motor 4 moved from 25.05° to 26.73°, close to the requested target of 27.05°.

Motor 5: Wrist Roll

(lerobot)$ python test_motor.py 5 5

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    26.73 deg
ID5  wrist_roll.pos       =     6.99 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID5
Joint          : wrist_roll.pos
Current        : 6.99
Delta          : +5.00
Target         : 11.99

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID5 wrist_roll.pos: 6.99 -> 11.99

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    26.73 deg
ID5  wrist_roll.pos       =    11.56 deg
ID6  gripper.pos          =    24.70
=======================================================

Requested target : 11.99
Actual position  : 11.56

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

Motor 5 also moved correctly.

Motor 6: Gripper

(lerobot)$ python test_motor.py 6 5

=======================================================
BEFORE
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    26.73 deg
ID5  wrist_roll.pos       =    11.56 deg
ID6  gripper.pos          =    24.70
=======================================================

Selected motor : ID6
Joint          : gripper.pos
Current        : 24.70
Delta          : +5.00
Target         : 29.70

Support the arm and make sure it is safe.
Press ENTER to enable torque and move the motor...

>>> Moving ID6 gripper.pos: 24.70 -> 29.70

=======================================================
AFTER
=======================================================
ID1  shoulder_pan.pos     =    15.08 deg
ID2  shoulder_lift.pos    =   -89.76 deg
ID3  elbow_flex.pos       =    97.89 deg
ID4  wrist_flex.pos       =    26.73 deg
ID5  wrist_roll.pos       =    11.56 deg
ID6  gripper.pos          =    29.31
=======================================================

Requested target : 29.70
Actual position  : 29.31

Press ENTER to disable torque and exit...

Torque OFF / disconnected.

The gripper also responded correctly.

With this test, I was able to confirm that the assembly, wiring, motor ID assignment, and calibration were basically working correctly.

All six motors responded to commands and moved in the expected way.

So now the SO-101 is finally ready for actual operation.

For my setup, however, I am not planning to use a leader arm.

Instead, I want to try controlling the SO-101 using a 3D mouse (SpaceMouse).

That will be the next step.

Trying VLA (Part 3): Finally Assembling LeRobot — From Joint 2 to Calibration

Takeo — Thu, 03 Sep 2026 02:51:15 +0000

In the previous article, I explained how to assemble the first joint, Joint 1.

I covered Joint 1 separately because there were several things worth paying attention to, such as the different types of screws, tips for fitting the parts together, and a few points that could easily cause trouble — at least, they did for me.

https://dev.to/takeofuture/trying-vla-part-1-preparing-lerobot-and-assigning-ids-to-the-motors-538g

In this article, I will continue the assembly process and go all the way through calibration.

Based on the difficulties I encountered during the assembly, I want to mention one important point right at the beginning:

For Joint 5, I recommend slightly changing the order of the assembly steps.

Joint 2

(As long as you connect the wiring first, I think you can basically follow the video as-is.)

Slide the second motor into place from above.

Use four M2×6mm screws to secure Motor 2.

Attach motor horns to both sides of Motor 2. As before, use M3×6mm motor-horn screws to secure them.

Attach the Upper Arm and secure it with four M3×6mm screws on each side.

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Joint2_v2.mp4

It may be easier to connect the motors to each other before assembling them. Also, when fitting the motor into place, the motor horn can easily shift, so it may be better to push it into position in one motion. If it shifts out of alignment, the screw holes can become hidden, making it impossible to insert the screws.

Joint 3

(Again, as long as you connect the wiring first, I think you can basically follow the video as-is.)

Insert the third motor and secure it using four M2×6mm screws.

Attach motor horns to both sides of Motor 3. As before, secure one side using an M3×6mm motor-horn screw.

Attach the Forearm to Motor 3 and secure it with four M3×6mm screws on each side.

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Joint3_v2.mp4

Joint 4

(As long as you connect the wiring first, I think you can follow the video as-is.)

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Joint4_v2.mp4

Joint 5

(For this joint, I strongly recommend connecting the wiring before tightening the screws!)

First, assemble only the section shown in the video.

Insert the motor and attach the motor horn on only one side.

👆 It is very important to connect the power cables before tightening the screws as shown above!

Do not install the screws immediately. At this stage, connect Motor 4 to Motor 5, and also connect the cable from Motor 5 that will later go to Motor 6.

In other words, once Motor 5 has been inserted into the frame, complete the wiring from Motor 4 to Motor 5 and from Motor 5 to Motor 6.

If you tighten the screws before doing this, inserting the power connectors afterward becomes extremely difficult.

I originally followed the video exactly and ended up struggling quite a lot.

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Joint5_v2.mp4

Because I installed Motor 5 and tightened the screws first, connecting Motor 4 to Motor 5 and connecting the power cable from Motor 5 to Motor 6 became extremely difficult.

To make things worse, once I had installed the screws, I was unable to remove one of them, so I could not simply take everything apart and redo the assembly.

I suspect this may have been related to the quality of the frame parts I purchased. The screw hole appeared to become damaged or stripped, and I could no longer remove the screw that was holding the frame together.

Eventually, I managed to insert the power connectors using tweezers and carefully pushing them into place with my little finger.

However, I probably spent around two hours on this step alone.

👆 If you assemble and tighten everything before wiring, accessing the power connectors becomes extremely difficult!

Gripper / Handle / Waveshare Board Installation

Attach the gripper to Motor 5.

Secure it to the wrist-side motor horn using four M3×6mm screws.

Insert the gripper motor and secure it using two M2×6mm screws on each side.

Attach the motor horn and secure it using the M3×6mm motor-horn screw.

Attach the Gripper Claw and secure it with four M3×6mm screws on each side.

For this part, I think you can simply follow the video without any major problems.

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Gripper_v2.mp4

Once the assembly is complete, attach the board and connect it to Motor 1.

Depending on the quality of the frame parts, some components may not fit properly.

If necessary, you may need to carefully widen or clean up a distorted opening using a file or utility knife.

Since I had already connected the motors to each other while assembling the arm, at this stage I only needed to connect the Waveshare board to Motor 1, as shown at the beginning of the video.

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Wiring_v2.mp4

Securing the Robot Arm to the Desk

If you leave the robot arm as-is, it can tip over when the arm is extended because of the shift in its center of gravity.

For that reason, I secured the base to my desk.

For some reason, I still had one frame part left over, and I was not completely sure what it was supposed to be used for.
I decided not to worry about it and continued.

Next, connect the PC to the Waveshare board using USB-C and connect power to the Waveshare board as well.

At this point, check that power is reaching Motor 6, which is the last motor in the daisy-chain connection.

Calibration

At this point, each motor can still be rotated manually by hand.

You will feel some resistance and hear a slight mechanical sound while turning them, but they should still rotate manually.

Before starting calibration, move each joint to approximately the middle of its range of motion.

$ source ~/pyenv/lerobot/bin/activate
(lerobot)$ lerobot-calibrate \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=takeo_so101

INFO 2026-09-02 10:30:46 calibrate.py:89 {'robot': {'calibration_dir': None,
           'cameras': {},
           'disable_torque_on_disconnect': True,
           'id': 'takeo_so101',
           'max_relative_target': None,
           'num_read_retries': 2,
           'port': '/dev/ttyACM0',
           'position_d_coefficient': 32,
           'position_i_coefficient': 0,
           'position_p_coefficient': 16,
           'use_degrees': True},
 'teleop': None}
INFO 2026-09-02 10:30:46 follower.py:109 takeo_so101 SOFollower connected.
Press ENTER to use provided calibration file associated with the id takeo_so101, or type 'c' and press ENTER to run calibration:

I had already calibrated this robot once before.

If I want to reuse the previous calibration file, I can simply press ENTER.

If I want to perform calibration again, I can type c and press ENTER.

If this is your first time calibrating the robot, I believe you can proceed by pressing ENTER.

For this article, however, I wanted to show the calibration process again, so I entered c.

Press ENTER to use provided calibration file associated with the id takeo_so101, or type 'c' and press ENTER to run calibration: c
INFO 2026-09-02 10:35:41 follower.py:126
Running calibration of takeo_so101 SOFollower
Move takeo_so101 SOFollower to the middle of its range of motion and press ENTER....
Move all joints except 'wrist_roll' sequentially through their entire ranges of motion.
Recording positions. Press ENTER to stop...

-------------------------------------------
-------------------------------------------
NAME            |    MIN |    POS |    MAX
shoulder_pan    |   1171 |   2131 |   2968
shoulder_lift   |    325 |   2690 |   2697
elbow_flex      |    818 |    866 |   3021
wrist_flex      |   1100 |   2514 |   3418
gripper         |   1311 |   2719 |   2720
Calibration saved to /home/takeo/.cache/huggingface/lerobot/calibration/robots/so_follower/takeo_so101.json
INFO 2026-09-02 10:37:13 follower.py:238 takeo_so101 SOFollower disconnected.

As you manually rotate each joint, the values in the table above continuously change.

The following motors and joints are involved in the calibration process:

ID1 shoulder_pan → Left/right rotation
ID2 shoulder_lift → Shoulder up/down
ID3 elbow_flex → Elbow
ID4 wrist_flex → Wrist up/down
ID5 wrist_roll → Not included in this calibration process
ID6 gripper → Gripper open/close

The calibration parameters are then stored in the following JSON file.

(lerobot)$ cat /home/takeo/.cache/huggingface/lerobot/calibration/robots/so_follower/takeo_so101.json
{
    "shoulder_pan": {
        "id": 1,
        "drive_mode": 0,
        "homing_offset": -1979,
        "range_min": 1171,
        "range_max": 2968
    },
    "shoulder_lift": {
        "id": 2,
        "drive_mode": 0,
        "homing_offset": -422,
        "range_min": 325,
        "range_max": 2697
    },
    "elbow_flex": {
        "id": 3,
        "drive_mode": 0,
        "homing_offset": 1146,
        "range_min": 818,
        "range_max": 3021
    },
    "wrist_flex": {
        "id": 4,
        "drive_mode": 0,
        "homing_offset": 795,
        "range_min": 1100,
        "range_max": 3418
    },
    "wrist_roll": {
        "id": 5,
        "drive_mode": 0,
        "homing_offset": 2006,
        "range_min": 0,
        "range_max": 4095
    },
    "gripper": {
        "id": 6,
        "drive_mode": 0,
        "homing_offset": 1764,
        "range_min": 1311,
        "range_max": 2720
    }
}

With this, the assembly and calibration of the SO-101 follower arm are complete.

In the next article, I plan to run teleoperation from the command line and check whether the robot moves correctly.

https://dev.to/takeofuture/trying-vla-part-4-testing-teleoperation-from-the-command-line-1721

Trying VLA (Part 2): Assembling LeRobot — Joint 1

Takeo — Tue, 01 Sep 2026 07:09:28 +0000

In the previous article, I assigned IDs to each motor and determined where each motor should be installed.

https://dev.to/takeofuture/trying-vla-part-1-preparing-lerobot-and-assigning-ids-to-the-motors-538g

Now it is finally time to start assembling the robot.
👉 All the parts required for assembly should already be included, so the only tool you really need is a screwdriver.
However, I strongly recommend using a magnetic screwdriver that can hold the screws in place against gravity.
Without one, installing some of the screws can be surprisingly difficult!

For the assembly process, I mainly referred to the following official documentation and videos.
https://huggingface.co/docs/lerobot/main/assemble_so101

https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/lerobot/Joint1_v2.mp4

One thing that may not be very obvious from the video is that I strongly recommend connecting the cable to the next motor before assembling the frame.

Once the motor is installed inside those small frame parts, connecting the cable becomes much more difficult. Looking at the structure, it makes sense — there is simply not much space left to work with afterward 💦.

In this article, I will not cover the entire assembly process. Instead, I will focus on Joint 1 and explain how I assembled it, including several places where I personally got stuck or had to redo the work.

First, each motor comes with a motor horn and screws like these.

An M3 screw has a diameter of 3 mm and, in this case, a length of 6 mm.
An M2 screw has a diameter of 2 mm — measured around the shaft directly below the screw head — and in this case also has a length of 6 mm. The M2 screws used here have a countersunk-style head.

Understanding screw specifications is actually quite useful when building robots like this.
It becomes especially important when planning a project or sourcing replacement parts. At the very least, it is worth asking your LLM assistant about screw standards and making sure you understand them before starting.

This kind of basic mechanical knowledge will become useful again if you build other robots, drones, or similar hardware projects in the future.
If possible, I also recommend learning some basic soldering and how to repair power cables. If you accidentally pull a wire too hard and disconnect or damage it, knowing how to solder can allow you to repair at least some of those problems yourself.

Installing the Motor Horn — Pay Attention to the Orientation!!!

Now let's install the motor horn.

There is one important thing to be careful about at this stage.

When I first installed the horn, I pushed it onto the motor and secured it with an M3x6mm screw like this.

However, the orientation of the horn must match the screw positions of the frame part. Otherwise, you may have to remove it and reinstall it later.

At first, I followed the orientation shown in the video, where the screw holes looked like a diamond shape.

However, I eventually had to redo it because the screw positions on my frame part did not match that orientation.

Push the horn slightly onto the motor shaft, and then secure it using the M3 screw.

The important point is the orientation.

When looking at the four outer screw holes, I initially positioned them so that connecting the holes would form a diamond shape, similar to what appeared in the video.

For my frame, however, the holes needed to form a square instead.

This was my first mistake.

Install the horn at an angle where the four screw holes look like the red circles shown below — forming a square rather than a diamond.

More precisely, you should check the screw positions on your actual frame part at this stage and align the horn orientation accordingly.

The horn on the opposite side does not need to be secured with a screw.

You also do not necessarily need to install it at this stage. It may be easier to place it later while assembling the frame parts so that you can align the orientation correctly.

I will explain this part later, so you do not need to install it yet.

However, just like the other side, its orientation also needs to match the frame. In my case, it needed to be positioned as a square rather than a diamond.

I believe this depends on the frame parts you ordered or printed with a 3D printer.

The screw-hole positions may differ slightly depending on the specific parts you have.

Therefore, before tightening everything, check the screw-hole layout of your own frame and adjust the motor horn orientation accordingly.

Installing the Motor

TIP 1: First, test-fit the parts before tightening any screws.

TIP 2: Connect Motor 1 and Motor 2 before installing Motor 1 into the frame.

I personally struggled because I did not follow TIP 2.

Before installing the first motor into the frame, I strongly recommend connecting the first motor to the second motor.

At this stage, before installing any screws, check that the motor can be pushed properly into the frame part, as shown in the assembly video.

I think it is safer to verify the fit first and only then install the screws.

Do not force the parts too hard.

If you apply too much pressure, you may damage the threaded parts of the frame, strip the screw head, or make the screw difficult or impossible to remove later.

Before installing screws into the motor, first check whether the following frame part fits properly.

The official video installs the screws first, but based on my experience, I recommend checking the fit of the frame part beforehand.

Without tightening the screws, first check that the frame part fits correctly.

Then check whether the motor screw holes align with the screw positions of the frame.

The following image shows one of my mistakes, where the screw-hole orientation was offset by about 45 degrees.

This happened because I followed the orientation shown in the video without first checking the actual frame part.

So before tightening the horn, look carefully at your frame and determine how the screw holes need to be aligned.

I followed the screw-hole orientation in the video and ended up with the wrong position.

So I corrected the orientation.

Again, this may vary depending on the frame parts you are using!

Once you confirm that everything fits correctly, you can tighten the screws.

To be honest, considering that this robot is mainly intended for education and experimentation, if the frame itself holds the motor firmly enough, it may not always be necessary to tighten every screw extremely firmly.

Because of the quality of some screws and 3D-printed frame parts, applying too much force can potentially strip the screw head or damage the threaded hole.

If that happens, removing the screw later can become very difficult.

So first confirm that everything fits properly, and only then secure it with screws.

If you discover, as I did, that the screw holes do not align correctly, one option is to redo the motor horn orientation.

Another possibility, depending on how securely the motor is already held by the frame, may be to leave one side without screws rather than forcing a badly aligned screw into place.

Next, after securing the motor with the M3x6mm screws, install the next frame part.

This is the part with a small protruding section on the upper-right side.

There is another part with a very similar shape, so be careful not to confuse them.

As mentioned earlier, I recommend connecting the cable to the next motor before installing the motor into the frame.

In my case, I assembled the frame first without connecting the cable.

As a result, I had to do the wiring afterward in a very narrow space, which made the work slightly more difficult.

If I had connected the cable beforehand, the assembly would have been much easier.

Rather than simply following the assembly video step by step, I recommend checking the following three points first. Doing this can significantly reduce the amount of rework.

Check the orientation of the motor horn screw holes against the screw positions on the actual frame parts.
Push the motor into the frame and test-fit the next part before tightening the screws.
Before installing Motor 1 into the frame, connect the power/data cable between Motor 1 and Motor 2.

That's it!

In the next article, I’ll finish assembling the robot arm, secure it to the desk, and complete the calibration.

https://dev.to/takeofuture/trying-vla-part-3-finally-assembling-lerobot-from-joint-2-to-calibration-3g79

Trying VLA (Part 1): Preparing LeRobot and Assigning IDs to the Motors

Takeo — Sun, 30 Aug 2026 23:16:21 +0000

In the previous article, I briefly explained what VLA is, what LeRobot is, and what makes it useful, and then introduced the products I purchased.
https://dev.to/takeofuture/getting-started-with-lerobot-and-so-101-building-a-low-cost-physical-ai-robot-arm-part-0-6j1

Now that all the parts have arrived, it is finally time to start assembling the robot.

However, before jumping straight into the assembly, there is one important step we need to complete first. You should have received six motors, and each of them needs to be assigned its own ID. In this article, I will first explain how to do that.

We will connect the controller board to a PC and assign the IDs from there. You can also install Ubuntu on Windows using WSL (Windows Subsystem for Linux), but if possible, I recommend using a native Ubuntu installation. As of August 30, 2026, the latest stable LTS version is Ubuntu 24.04.

Installing the setup tools

I will assume that Python 3 is already installed. If it is not, install it with the following command.

apt install python3 python3-venv python3-pip

Next, let's create a Python virtual environment. Here, I will name it lerobot, and then activate it.

$ python3 -m venv lerobot
$ source lerobot/bin/activate
(lerobot)$ pip install --upgrade pip

After that, install LeRobot.

Because the SO-101 uses STS3215 motors, the feetech option is important.

If this PC is only being used for configuration or teleoperation and does not have an NVIDIA GPU, it is better to install the CPU-only version of PyTorch first so that unnecessary NVIDIA GPU-related PyTorch packages are not downloaded.

(lerobot)$ pip install \
  torch==2.11.0+cpu \
  --index-url https://download.pytorch.org/whl/cpu

(lerobot)$ cd ~
(lerobot)$ git clone https://github.com/huggingface/lerobot.git
(lerobot)$ cd lerobot
(lerobot)$ pip install -e ".[feetech]"

Once the installation is complete, you should be able to use commands such as the following!

(lerobot)$ lerobot-find-port --help
(lerobot)$ lerobot-setup-motors --help

Setting the Waveshare board to USB mode

To communicate with the PC via USB-C, insert six jumpers arranged in two columns and three rows vertically into the appropriate pins.

Connect the Waveshare board to the PC via USB, and also connect the power cable.

The USB connection itself supplies power to the board, but it does not provide enough power to operate the motors, so you also need to connect the 12V power supply.

Run the following command from the terminal to identify the port.

(lerobot) $ lerobot-find-port
Finding all available ports for the MotorsBus.
Ports before disconnecting: ['/dev/ttyACM0', '/dev/ttyprintk', '/dev/ttyS31', '/dev/ttyS30', '/dev/ttyS29', '/dev/ttyS28', '/dev/ttyS27', '/dev/S20', '/dev/ttyS19', '/dev/ttyS18', '/dev/ttyS17', '/dev/ttyS16', '/dev/ttyS15', '/dev/ttyS14', '/dev/ttyS13', '/dev/ttyS12', '/dev/ttyS11', '/d', '/dev/ttyS3', '/dev/ttyS2', '/dev/ttyS1', '/dev/ttyS0', '/dev/tty63', '/dev/tty62', '/dev/tty61', '/dev/tty60', '/dev/tty59', '/dev/tty58', '1', '/dev/tty50', '/dev/tty49', '/dev/tty48', '/dev/tty47', '/dev/tty46', '/dev/tty45', '/dev/tty44', '/dev/tty43', '/dev/tty42', '/dev/tty41', 34', '/dev/tty33', '/dev/tty32', '/dev/tty31', '/dev/tty30', '/dev/tty29', '/dev/tty28', '/dev/tty27', '/dev/tty26', '/dev/tty25', '/dev/tty24',y17', '/dev/tty16', '/dev/tty15', '/dev/tty14', '/dev/tty13', '/dev/tty12', '/dev/tty11', '/dev/tty10', '/dev/tty9', '/dev/tty8', '/dev/tty7', 'ev/tty']
Remove the USB cable from your MotorsBus and press Enter when done.

As instructed by the command, disconnect the USB cable connecting the Waveshare device to the PC, and then press Enter.

The port of this MotorsBus is '/dev/ttyACM0'
Reconnect the USB cable.

Success! We can now confirm that this Waveshare device is associated with
/dev/ttyACM0

If you are not running these commands as root, give your user account permission to access serial devices with the following command.

(lerobot) $ sudo usermod -aG dialout yourusername

Reconnect the USB cable to the PC. Then disconnect the power supply temporarily and connect a motor.

Both the motors and the Waveshare board have two connectors, and either connector can be used. However, it is better to keep the connection pattern consistent. I will proceed using the following connection scheme.

Board left connector
   ↓
Motor 1 left connector

Motor 1 right connector
   ↓
Motor 2 left connector

Motor 2 right connector
   ↓
Motor 3 left connector
...

Once the motor is connected, run the following command.

(lerobot) $ lerobot-setup-motors \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0
Connect the controller board to the 'gripper' motor only and press enter.

After pressing Enter, you should see the following output.

'gripper' motor id set to 6

The motor ID is important because it determines which motor will be installed at which joint of the robot. In this case, the motor was assigned ID 6, so it is a good idea to physically label the motor.

Then repeat the same process for the remaining five motors.

Disconnect the 12V power supply
Disconnect the current motor
Connect only one new motor to the board
Reconnect the 12V power supply
Press Enter
Attach a label to the configured motor

Repeat this process until IDs have been assigned to all six motors.

(lerobot)$ lerobot-setup-motors \
  --robot.type=so101_follower \
  --robot.port=/dev/ttyACM0
Connect the controller board to the 'gripper' motor only and press enter.
'gripper' motor id set to 6
Connect the controller board to the 'wrist_roll' motor only and press enter.
'wrist_roll' motor id set to 5
Connect the controller board to the 'wrist_flex' motor only and press enter.
'wrist_flex' motor id set to 4
Connect the controller board to the 'elbow_flex' motor only and press enter.
'elbow_flex' motor id set to 3
Connect the controller board to the 'shoulder_lift' motor only and press enter.
'shoulder_lift' motor id set to 2
Connect the controller board to the 'shoulder_pan' motor only and press enter.
'shoulder_pan' motor id set to 1

To summarize, the motor IDs are assigned as follows. This mapping is very important, so make sure to record it carefully.
ID 1 = shoulder_pan
ID 2 = shoulder_lift
ID 3 = elbow_flex
ID 4 = wrist_flex
ID 5 = wrist_roll
ID 6 = gripper

Next, we’re finally ready to start assembling the robot arm.
https://dev.to/takeofuture/trying-vla-part-2-assembling-lerobot-joint-1-2npj

Trying VLA (Part 0): Getting Started with LeRobot and SO-101: Building a Low-Cost Physical AI Robot Arm

Takeo — Sun, 30 Aug 2026 22:44:36 +0000

With the rapid development of LLMs (Large Language Models) and VLMs (Vision-Language Models), a new type of model called VLA (Vision-Language-Action) has been attracting increasing attention in robotics.

In this series, I will use Hugging Face LeRobot and the relatively low-cost SO-101 robot arm to experiment with imitation learning, robot learning, and eventually VLA models on real hardware.

In this Part 0, I will first cover:

What VLA is
What LeRobot is
Why I chose LeRobot instead of starting with ROS + Raspberry Pi
What hardware I purchased to build the SO-101

In the following articles, I plan to move from assembling the robot to calibration, teleoperation, dataset collection, imitation learning, and eventually VLA experiments.

What Is VLA?

VLA stands for Vision-Language-Action.
In a very simplified form, it looks like this:

Vision
"What can the robot see?"
        +
Language
"What does the human want?"
        ↓
       VLA
        ↓
Action
"How should the robot move?"

LLMs have already become widely known through systems such as ChatGPT.
An LLM primarily works with language.
From there, VLMs (Vision-Language Models) expanded AI systems so that they could process both language and visual information such as images.
A simplified progression looks like this:

LLM
Understand and generate language
        ↓
VLM
Understand language + images
        ↓
VLA
Understand language + images
and generate physical actions

Up to the VLM stage, AI primarily observes information in a digital environment and responds to it.

VLA goes one step further.

The goal is for an AI model to:

observe the physical world, understand a human instruction, and actually control a robot to perform the task.

For example, suppose a camera sees:

a red block
a blue box
a robot arm

and the user says:
"Put the red block into the blue box."

A VLA system could generate a sequence of robot actions such as:

Move the arm toward the red block
↓
Open the gripper
↓
Grasp the block
↓
Lift the block
↓
Move toward the blue box
↓
Open the gripper

The important difference is that the AI does not simply respond:
"There is a red block in the image."

Instead, it takes action in the physical world.

Physical AI
Combining AI with robots, cameras, sensors, motors, and other physical systems so that the AI can

perceive → reason → act

in the real world is increasingly described as Physical AI.

VLA is one important approach toward building Physical AI systems.

For my experiments, I will use:

Hugging Face LeRobot
SO-101 robot arm

to explore this area using relatively inexpensive hardware.

Physical AI Is Becoming Accessible to Individuals

Traditionally, buying a robot for serious robotics research could be extremely expensive.

Even relatively small research or industrial robot systems could easily cost tens of thousands of dollars.

In that environment, a robot costing approximately as much as a passenger car could almost be considered "inexpensive" for research use.

However, the situation has been changing rapidly.

Today we have access to increasingly affordable:

servo motors
cameras
Raspberry Pi computers
NVIDIA Jetson devices
small robots
drones
3D printers
open-source robotics software
open AI models

Because of this, robotics is gradually moving away from a world where meaningful experiments require expensive proprietary hardware.
Instead, individuals can now assemble relatively inexpensive components and experiment with robotics and AI themselves.

The SO-101 is a good example of this trend.
Instead of purchasing an expensive research-grade robot arm, it is possible to build a small robot arm for only a few hundred dollars and use it to experiment with technologies such as:

imitation learning
robot learning
VLA
Physical AI

For me, this is one of the most exciting aspects of the SO-101.

Why LeRobot Instead of ROS + Raspberry Pi?

Of course, SO-101 + LeRobot is not the only way to combine inexpensive hardware with AI.
For example, it is possible to connect motors, sensors, and cameras to a Raspberry Pi and build a small robot car or robot arm.
I previously experimented with this approach by modifying a very inexpensive toy robot car and combining it with an LLM.
You can find that experiment here(Sorry Japanese only now but you can translate by LLM/VLM, I will translate and publish here soon):
https://zenn.dev/takeofuture/articles/458c1a3abcce04

Experimenting with an LLM and a Low-Cost Robot Car
For more advanced robotics projects, another very common option is ROS (Robot Operating System).
A typical architecture might look like this:

Camera / LiDAR / Sensors
          ↓
      Raspberry Pi
       / Jetson
          ↓
          ROS
          ↓
 Motor Controller
          ↓
        Robot

ROS provides a common framework for many important robotics functions, including:

acquiring images from cameras
reading LiDAR and other sensors
controlling motors
estimating robot position
planning paths
exchanging data between different programs and devices

For this reason, ROS is one of the most important platforms in modern robotics.
So why am I using LeRobot instead of starting with Raspberry Pi + ROS?
The Goal Is Not Just to Program the Robot
The goal of this project is not simply:
"Write a program that moves a robot."

Instead, I want to explore the following process:
Have a human demonstrate a task, collect the robot data, train an AI model using that data, and finally let the AI control the robot by itself.
This is where LeRobot becomes especially interesting.
LeRobot is an open-source framework from Hugging Face designed for robot learning.

At a high level, the workflow looks like this:

Human operates the robot
        ↓
Teleoperation
        ↓
Record camera images,
joint states, and actions
        ↓
Dataset
        ↓
Train an AI model
        ↓
ACT / SmolVLA / π0 / etc.
        ↓
The trained AI controls the robot

For example, imagine that a human demonstrates the following task dozens of times:

Pick up the red block and put it into the box.

During each demonstration, LeRobot can record data such as:

Camera images
+
Robot joint states
+
Actions performed by the human

This becomes a training dataset.
The dataset can then be used to train an imitation-learning policy or a VLA model.

After training, the goal is for the robot to observe the camera image and perform the same task without continuous human control.

In a very simplified comparison:
ROS
Focus:
"How do I build and control the robot system?"

LeRobot
Focus:
"How do I collect robot data, train a model,and let AI control the robot?"

This is obviously an oversimplification, but I think it is a useful way to understand the difference.
ROS and LeRobot are also not competing technologies.
They can be used together.
For example:

Sensors / Camera
       ↓
      ROS
       ↓
Hardware Control
       ↓
    LeRobot
       ↓
Dataset / Training
       ↓
    Robot AI

ROS could handle hardware interfaces and sensors while LeRobot manages robot-learning datasets and AI policies.

A Simple SO-101 Setup

The SO-101 is a relatively simple robot arm.
Because of that, I do not necessarily need to place Raspberry Pi or ROS between the computer and the robot.
I can start with a much simpler architecture:

Camera
   ↓
PC running Ubuntu
   ↓
LeRobot
   ↓ USB
Servo Controller
   ↓
SO-101

For this project, my main goal is not to build every part of the robot infrastructure from scratch.
Instead, I want to reach the robot AI experiments as quickly as possible.
In particular, I want to experiment with:

teleoperation
dataset collection
imitation learning
learned robot policies
VLA models

That is why I chose LeRobot + SO-101 for this project.

SO-101 Hardware

So what do we actually need to build an SO-101?
It is possible to purchase a completely assembled SO-101, but the mechanical structure itself is relatively simple.
The frame can also be produced using a 3D printer.
In other words, you do not necessarily need to purchase a pre-made frame kit.
A basic system could be assembled from:

3D-printed frame
       +
Servo motors
       +
Servo controller
       +
PC

This can reduce the cost even further.
I think this is another very interesting part of modern low-cost robotics.
Instead of purchasing an entire robot from a manufacturer, we can download designs, print the mechanical parts ourselves, purchase inexpensive motors and controllers, and assemble the system.
I would eventually like to try this approach with other robots or drones and build the mechanical structure myself using a 3D printer.
However, that is not the main goal of this particular project.

My priority this time is:
Build the SO-101 as quickly as possible and move on to LeRobot, imitation learning, and VLA experiments.
Therefore, I decided to purchase a pre-made SO-101 Follower Arm Frame Kit instead of printing every frame component myself.
I also purchased an Electronics Kit rather than sourcing every servo motor, cable, controller, and power supply individually.
In other words, my goal is not:
Build every component of the robot completely from scratch.

My goal is:
Reach the robot-learning and Physical AI experiments as quickly as possible.

What I Purchased

I purchased two main kits.
I currently live in the United States, so I purchased them through Amazon.com.
Similar SO-101 kits and components are also available from various sellers in other countries.

SO-101 Follower Arm Frame Kit The frame kit contains the mechanical components required to assemble the robot arm. The kit includes items such as:
3D-printed frame parts
gripper components
camera mount
screws and assembly hardware
Amazon.com Product:
SO-101 Follower Arm Frame Kit
ASIN:B0GH429G4X
SO-101 Follower Arm Electronics Kit
The Electronics Kit contains most of the electronic components required to operate the SO-101.
The kit includes:
6 × Feetech STS3215 servo motors
Waveshare Serial Bus Servo Controller
12V 5A power supply
connection cables
Amazon.com
Product:
SO-101 Follower Arm Electronics Kit

ASIN:B0GH35175P
Hardware Architecture
With these components, the basic architecture looks like this:

PC running Ubuntu
       ↓ USB
Waveshare
Serial Bus Servo Controller
       ↓
Feetech STS3215 × 6
       ↓
SO-101 Frame

After adding a camera, the system becomes:

Camera
   ↓
PC
   ↓
LeRobot
   ↓
Servo Controller
   ↓
SO-101

This will allow me to start experimenting with:

Teleoperation
      ↓
Dataset Collection
      ↓
Model Training
      ↓
AI-controlled Robot

What's Next?
The next step is to assemble the SO-101.
However, before physically assembling the robot arm, there is one important task:
assigning an ID to each servo motor.
The SO-101 uses multiple servo motors connected through the same serial bus.
Because of this, each servo must have its own unique ID so that the controller can identify and control it independently.
The next article covers this servo ID configuration process in detail:
SO-101 Servo Motor ID Configuration
After that, I plan to proceed roughly in the following order:

Servo ID Configuration
        ↓
SO-101 Assembly
        ↓
Calibration
        ↓
Teleoperation
        ↓
Dataset Collection
        ↓
Imitation Learning
        ↓
VLA / Physical AI

My final goal is not simply to build the robot arm.
I want to use this inexpensive hardware platform to explore how far an individual can go today with robot learning, VLA, and Physical AI.

In the next article, I’ll walk through how to assign an ID to each motor and prepare the SO-101 for the next steps.

👉 Part 1:
https://dev.to/takeofuture/trying-vla-part-1-preparing-lerobot-and-assigning-ids-to-the-motors-538g

From Sentinel-1 SLC to InSAR with Python: A Kumamoto Earthquake Example

Takeo — Sat, 29 Aug 2026 02:45:17 +0000

In my previous article, I introduced how to download and visualize SAR polarization data using Google Earth Engine.
https://dev.to/takeofuture/visualizing-surface-changes-after-the-2026-kumamoto-earthquake-with-sentinel-1-sar-and-google-earth-2ob3

In this article, I will take a different approach.
Instead of relying on Google Earth Engine, we will use NASA's Alaska Satellite Facility (ASF) to search for and download Sentinel-1 data directly.
Then we will generate InSAR (Interferometric Synthetic Aperture Radar) products using ASF HyP3, including:

Wrapped Phase
Unwrapped Phase
Coherence
LOS Displacement

As a practical example, I will use Sentinel-1 observations around the 2026 Kumamoto earthquake in Japan.
The goal of this article is not yet to analyze the earthquake itself.
Instead, the goal is to build the dataset required for later analysis.

A Quick Review: What Are VV and VH in SAR?
Before moving on to InSAR, let's quickly review the VV and VH polarization channels introduced in the previous article.

What Is SAR Polarization?
SAR stands for Synthetic Aperture Radar.
A SAR satellite sends microwave signals toward the Earth's surface and measures the signals that are reflected or scattered back toward the satellite.
One important property of these signals is polarization.
A Quick Review: What Are VV and VH in SAR?
Before moving on to InSAR, let's quickly review the VV and VH polarization channels introduced in the previous article.
What Is SAR Polarization?
SAR stands for Synthetic Aperture Radar.
A SAR satellite sends microwave signals toward the Earth's surface and measures the signals that are reflected or scattered back toward the satellite.
One important property of these signals is polarization.

Polarization describes the orientation in which the electric field of the electromagnetic wave oscillates.
SAR commonly uses two polarization directions:
H: Horizontal polarization
V: Vertical polarization
SAR products describe the transmitted and received polarization using two letters.
For example:
VV: transmitted vertically and received vertically
VH: transmitted vertically and received horizontally
HH: transmitted horizontally and received horizontally
HV: transmitted horizontally and received vertically

VV and HH are called co-polarized channels.
VH and HV are called cross-polarized channels.

Why Do VV and VH Look Different?

Microwaves interact differently with soil, vegetation, buildings, and other surface structures.

Because of that, VV and VH can provide different information even when observing exactly the same location.

In general:
VV often responds strongly to direct surface and structural reflections.
VH is often more sensitive to vegetation and complex multiple scattering.

In the previous article, I used SAR backscatter intensity and visualized how VV changed before and after the earthquake.
I also experimented with treating VV and VH as two input channels for image models.
For example, a conventional RGB image contains three channels:
R,G,B
A SAR-based model might instead use:
VV,VH
as two channels.
However, VV and VH backscatter do not respond only to earthquakes.

They are also affected by factors such as:

vegetation
soil moisture
rainfall
surface roughness
building orientation
satellite viewing geometry

For this reason, I decided to move from simple backscatter comparison to InSAR, which uses phase information to estimate changes in the distance between the satellite and the ground.

What Is InSAR?
InSAR stands for Interferometric Synthetic Aperture Radar.
VV and VH mainly describe the strength of the reflected radar signal.
InSAR goes one step further and also uses the phase of the microwave signal.
A simplified way to think about the difference is:
VV / VH: How did the radar signal reflect from the surface?
InSAR: How much did the radar phase change between two observations?
SAR satellites repeatedly observe the same area.

For example:
Observation 1: before an earthquake
Observation 2: after an earthquake

If the ground moves between the two observations, the distance traveled by the radar wave also changes.
That produces a change in the phase of the returned radar signal.
InSAR analyzes this phase difference to detect very small changes in the Earth's surface.
In other words, instead of simply asking:

"Did the image look different?"
we can ask:
"Did the distance between the satellite and the ground change?"
However, InSAR does not directly measure pure vertical displacement.
The measurement is projected along the satellite's viewing direction, called the Line of Sight (LOS).

A simple interpretation is:
LOS displacement = how much the ground moved along the satellite's viewing direction

Three InSAR Products Used in This Project
For this project, I mainly focus on three InSAR products:

Wrapped Phase
Coherence
LOS Displacement

Wrapped Phase
Radar signals are waves, so they have a phase.
When two SAR observations are compared, changes in the satellite-to-ground path length produce a phase difference.
The phase is typically represented within the range:
-π to +π
This is called the Wrapped Phase.
Because phase is periodic, values repeat after one full cycle.
When visualized, this can produce repeating colored bands known as interferometric fringes.

These fringes can indicate spatial changes in radar phase.
However, because the values are wrapped repeatedly between -π and +π, we cannot directly read a displacement such as "10 cm" from the Wrapped Phase alone.
Coherence
Another important InSAR product is Coherence.
Coherence describes how consistently the radar signals from two observations correspond to each other.
Its value is generally between:
0 and 1
A rough interpretation is:
close to 1: the two SAR observations correspond well, and the phase is relatively reliable
close to 0: the correspondence is weak, possibly because of noise or significant surface changes
Coherence can decrease because of:
vegetation changes
water surfaces
rainfall
soil moisture changes
major surface changes
differences in observation conditions
Coherence is therefore useful when deciding which LOS displacement values are reliable enough to analyze.
For example, in a later analysis I use only pixels satisfying:
Coherence >= 0.5
LOS Displacement
Wrapped Phase contains periodic phase values.
To estimate physical displacement, the phase wrapping first needs to be resolved using phase unwrapping.
The result is an Unwrapped Phase, where phase changes are represented continuously.
The radar wavelength can then be used to convert the phase difference into a distance change.
This produces LOS Displacement.

The processing concept is:
Wrapped Phase
↓
Phase Unwrapping
↓
Unwrapped Phase
↓
Convert phase using radar wavelength
↓
LOS Displacement

One important point is that Unwrapped Phase is still phase, not yet distance.
LOS Displacement is the product expressed as physical distance.
For the HyP3 LOS products used here, the sign convention is generally interpreted as:

positive: displacement toward the satellite
negative: displacement away from the satellite A LOS displacement of 10 cm does not necessarily mean that the ground moved vertically upward by 10 cm.

It means that the ground displacement projected onto the satellite's viewing direction was 10 cm.

VV/VH vs. InSAR We can summarize the difference as follows: In very simplified terms: VV/VH asks whether the way the surface reflects radar has changed. InSAR asks whether the satellite-to-ground distance has changed. Now let's obtain the actual data.

Create a NASA Earthdata Login
To download Sentinel-1 data from ASF, first create a NASA Earthdata Login account.
Registration instructions:
https://urs.earthdata.nasa.gov/documentation/for_users/how_to_register

Because we will use Python tools such as asf_search and hyp3_sdk, you may also need to pre-authorize the appropriate ASF/HyP3 applications for your Earthdata account.
Instructions:
https://urs.earthdata.nasa.gov/documentation/for_users/how_to_preauth_app

In this workflow, we will:

Search Sentinel-1
        ↓
Download SLC data
        ↓
Create observation pairs
        ↓
Submit InSAR jobs to HyP3
        ↓
Download the processed InSAR products

Install the Python Libraries The main libraries used in this article are: asf_search: search and download Sentinel-1 data from ASF hyp3_sdk: submit and retrieve HyP3 processing jobs shapely: work with geographical areas and geometries Create a requirements.txt file:

asf_search==12.3.1
hyp3_sdk==7.7.7
shapely==2.1.2

Then install them in your Python virtual environment:

pip install -r requirements.txt

Search for Sentinel-1 SLC Data The earthquake used in this example occurred in Kumamoto, Japan, on July 28, 2026. I searched for Sentinel-1 acquisitions from June through August 16, 2026. Rather than searching only at a single epicenter coordinate, I define a rectangular Area of Interest (AOI) around the epicenter. The bounding box is given as: west south east north I also restrict the search to Relative Orbit 156. This matters because InSAR compares phase between acquisitions, so observation geometry should be as consistent as possible. Create: 0.list_up.py

import asf_search as asf

# Kumamoto earthquake epicenter
EPICENTER = (130.6783333333, 32.625)

# Area of Interest
AOI_BBOX = (
    130.515,  # west
    32.480,   # south
    130.845,  # east
    32.765,   # north
)

RELATIVE_ORBIT = 156


def bbox_wkt(bbox):
    west, south, east, north = bbox

    return (
        f"POLYGON(("
        f"{west} {south},"
        f"{east} {south},"
        f"{east} {north},"
        f"{west} {north},"
        f"{west} {south}"
        f"))"
    )


results = asf.geo_search(
    dataset=asf.DATASET.SENTINEL1,
    processingLevel="SLC",
    beamMode="IW",
    relativeOrbit=RELATIVE_ORBIT,
    intersectsWith=bbox_wkt(AOI_BBOX),
    start="2026-06-01T00:00:00Z",
    end="2026-08-16T23:59:59Z",
    maxResults=100,
)

print("Search results:", len(results))

for product in results:
    p = product.properties

    print(
        p.get("sceneName"),
        p.get("startTime"),
        p.get("flightDirection"),
        p.get("polarization"),
        "frame =", p.get("frameNumber"),
    )

Run:

python 0.list_up.py

The result in this case was:

Search results: 7

S1C_IW_SLC__1SDV_20260815T091320_20260815T091347_009004_011DF6_CC4C 2026-08-15T09:13:20Z ASCENDING VV+VH frame = 102
S1C_IW_SLC__1SDV_20260803T091319_20260803T091346_008829_011833_BE60 2026-08-03T09:13:19Z ASCENDING VV+VH frame = 102
S1C_IW_SLC__1SDV_20260722T091318_20260722T091345_008654_01125E_4884 2026-07-22T09:13:18Z ASCENDING VV+VH frame = 102
S1C_IW_SLC__1SDV_20260710T091318_20260710T091345_008479_010C8A_76D5 2026-07-10T09:13:18Z ASCENDING VV+VH frame = 102
S1C_IW_SLC__1SDV_20260628T091317_20260628T091344_008304_0106DC_85C8 2026-06-28T09:13:17Z ASCENDING VV+VH frame = 102
S1D_IW_SLC__1SDV_20260622T091330_20260622T091357_003347_005E09_DD43 2026-06-22T09:13:30Z ASCENDING VV+VH frame = 102
S1D_IW_SLC__1SDV_20260610T091329_20260610T091356_003172_005852_B0A1 2026-06-10T09:13:29Z ASCENDING VV+VH frame = 102

Seven SLC acquisitions were found.

For example:
S1C_IW_SLC__1SDV_20260722...
contains information such as:
S1C Sentinel-1C
IW Interferometric Wide Swath mode
SLC Single Look Complex
20260722 Acquisition date

The results also show consistent:
ASCENDING
VV+VH
frame = 102
ASCENDING means the satellite was traveling generally from south to north during the acquisition.
VV+VH means both VV and VH polarization channels are included.
Frame 102 is one of the observation-geometry parameters used to keep the acquisitions comparable.
At this stage, we have not generated any InSAR products yet.
We are only checking whether suitable Sentinel-1 SLC acquisitions exist before and after the earthquake.

Download Sentinel-1 SLC Data
ASF metadata search can be performed without authentication, but downloading the actual Sentinel-1 SLC files requires NASA Earthdata authentication.
Instead of writing credentials directly inside the source code, store them as environment variables.

export EARTHDATA_USERNAME="your-earthdata-username"
export EARTHDATA_PASSWORD="your-earthdata-password"

Create:
1.download_s1_slc.py

import os
from pathlib import Path

import asf_search as asf


# --------------------------------------------------
# Search configuration
# --------------------------------------------------

AOI_BBOX = (
    130.515,  # west
    32.480,   # south
    130.845,  # east
    32.765,   # north
)

RELATIVE_ORBIT = 156
FRAME_NUMBER = 102
FLIGHT_DIRECTION = "ASCENDING"

SEARCH_START = "2026-06-01"
SEARCH_END = "2026-08-16"

DOWNLOAD_DIR = Path("./data/slc")


def bbox_wkt(bbox):
    west, south, east, north = bbox

    return (
        f"POLYGON(("
        f"{west} {south},"
        f"{east} {south},"
        f"{east} {north},"
        f"{west} {north},"
        f"{west} {south}"
        f"))"
    )


# --------------------------------------------------
# Earthdata Login
# --------------------------------------------------

username = os.environ.get("EARTHDATA_USERNAME")
password = os.environ.get("EARTHDATA_PASSWORD")

if not username or not password:
    raise RuntimeError(
        "Please set EARTHDATA_USERNAME and EARTHDATA_PASSWORD."
    )

session = asf.ASFSession().auth_with_creds(
    username,
    password,
)


# --------------------------------------------------
# Search Sentinel-1 SLC
# --------------------------------------------------

results = asf.geo_search(
    dataset=asf.DATASET.SENTINEL1,
    processingLevel="SLC",
    beamMode="IW",
    relativeOrbit=RELATIVE_ORBIT,
    intersectsWith=bbox_wkt(AOI_BBOX),
    start=f"{SEARCH_START}T00:00:00Z",
    end=f"{SEARCH_END}T23:59:59Z",
    maxResults=100,
)


# --------------------------------------------------
# Filter by observation geometry
# --------------------------------------------------

selected = []

for product in results:
    p = product.properties

    direction = str(
        p.get("flightDirection", "")
    ).upper()

    frame = p.get("frameNumber")

    polarization = str(
        p.get("polarization", "")
    ).upper()

    if (
        direction == FLIGHT_DIRECTION
        and frame == FRAME_NUMBER
        and "VV" in polarization
    ):
        selected.append(product)


print("Products to download:", len(selected))


# --------------------------------------------------
# Download
# --------------------------------------------------

DOWNLOAD_DIR.mkdir(
    parents=True,
    exist_ok=True,
)

for product in selected:
    p = product.properties

    print()
    print(
        "Downloading:",
        p.get("sceneName")
    )

    product.download(
        path=str(DOWNLOAD_DIR),
        session=session,
    )


print()
print("Download complete.")
print("Output:", DOWNLOAD_DIR.resolve())

Because these files can be large, I ran the script in the background:

nohup python 1.download_s1_slc.py > 1.download_s1_slc.log 2>&1 &

After the download completed:

data/slc/
├── S1C_IW_SLC__1SDV_20260628T091317_20260628T091344_008304_0106DC_85C8.zip
├── S1C_IW_SLC__1SDV_20260710T091318_20260710T091345_008479_010C8A_76D5.zip
├── S1C_IW_SLC__1SDV_20260722T091318_20260722T091345_008654_01125E_4884.zip
├── S1C_IW_SLC__1SDV_20260803T091319_20260803T091346_008829_011833_BE60.zip
├── S1C_IW_SLC__1SDV_20260815T091320_20260815T091347_009004_011DF6_CC4C.zip
├── S1D_IW_SLC__1SDV_20260610T091329_20260610T091356_003172_005852_B0A1.zip
└── S1D_IW_SLC__1SDV_20260622T091330_20260622T091357_003347_005E09_DD43.zip

Look Inside an SLC Product
Let's inspect one downloaded ZIP file.

unzip -l data/slc/S1C_IW_SLC__1SDV_20260722T091318_20260722T091345_008654_01125E_4884.zip \
  | grep -i preview

One of the files inside the archive is:
preview/quick-look.png
We can extract only that preview:

mkdir -p preview
unzip -j \
 data/slc/S1C_IW_SLC__1SDV_20260722T091318_20260722T091345_008654_011DF6_CC4C.zip \
  '*/preview/quick-look.png' \
  -d preview

If your filename differs, replace it with the actual downloaded granule name.
Here is an example of the Sentinel-1 SLC quick-look image:

This is not yet an InSAR image.
It is a preview of one SAR acquisition covering a much larger area than the Kumamoto AOI.

Generate InSAR Products with ASF HyP3
Now we have the Sentinel-1 SLC acquisitions.
The next step is to combine observations from two different dates and generate InSAR products.
For this, I use ASF HyP3 InSAR GAMMA.
InSAR requires a pair of compatible SLC acquisitions observing the same area.
In this example, I automatically select acquisitions separated by 12 days.
For example:
2026/07/10 → 2026/07/22 PRE-earthquake
2026/07/22 → 2026/08/03 COSEISMIC
2026/08/03 → 2026/08/15 POST-earthquake
The important point is that the local SLC ZIP files are not uploaded to HyP3.
Instead, the script extracts the Sentinel-1 granule IDs from the filenames and submits those IDs to HyP3.
ASF performs the InSAR processing on its side.
Make sure the Earthdata credentials are still available:

export EARTHDATA_USERNAME="your-earthdata-username"
export EARTHDATA_PASSWORD="your-earthdata-password"

Create:
2.make_insar.py

import os
import re
import zipfile
from datetime import datetime
from pathlib import Path

import hyp3_sdk as sdk


# --------------------------------------------------
# Configuration
# --------------------------------------------------

SLC_DIR = Path("./data/slc")
RESULT_DIR = Path("./data/insar")

EARTHQUAKE_DATE = datetime(2026, 7, 28)

PAIR_DAYS = 12


# --------------------------------------------------
# Earthdata Login
# --------------------------------------------------

username = os.environ.get("EARTHDATA_USERNAME")
password = os.environ.get("EARTHDATA_PASSWORD")

if not username or not password:
    raise RuntimeError(
        "Please set EARTHDATA_USERNAME and EARTHDATA_PASSWORD."
    )

hyp3 = sdk.HyP3(
    username=username,
    password=password,
)


# --------------------------------------------------
# Read acquisition date and granule ID
# --------------------------------------------------

def get_slc_info(zip_path):

    granule_id = zip_path.stem

    # Example:
    # S1C_IW_SLC__1SDV_20260722T091318_...

    match = re.search(
        r"_(\d{8})T\d{6}_",
        granule_id
    )

    if not match:
        raise RuntimeError(
            f"Could not parse acquisition date: {granule_id}"
        )

    date = datetime.strptime(
        match.group(1),
        "%Y%m%d"
    )

    return {
        "path": zip_path,
        "granule": granule_id,
        "date": date,
    }


slcs = [
    get_slc_info(path)
    for path in sorted(SLC_DIR.glob("*.zip"))
]

slcs.sort(
    key=lambda x: x["date"]
)


print("SLC acquisitions")
print("-" * 70)

for s in slcs:
    print(
        s["date"].strftime("%Y-%m-%d"),
        s["granule"]
    )


# --------------------------------------------------
# Build 12-day InSAR pairs
# --------------------------------------------------

pairs = []

for i in range(len(slcs)):
    for j in range(i + 1, len(slcs)):

        reference = slcs[i]
        secondary = slcs[j]

        delta = (
            secondary["date"]
            - reference["date"]
        ).days

        if delta != PAIR_DAYS:
            continue

        if secondary["date"] < EARTHQUAKE_DATE:
            role = "pre"

        elif (
            reference["date"]
            <= EARTHQUAKE_DATE
            <= secondary["date"]
        ):
            role = "coseismic"

        else:
            role = "post"

        pairs.append({
            "role": role,
            "reference": reference,
            "secondary": secondary,
        })


print()
print("Selected InSAR pairs")
print("-" * 70)

for pair in pairs:
    print(
        f"{pair['role']:10s}",
        pair["reference"]["date"].strftime("%Y-%m-%d"),
        "->",
        pair["secondary"]["date"].strftime("%Y-%m-%d"),
    )


# --------------------------------------------------
# Submit HyP3 InSAR jobs
# --------------------------------------------------

RESULT_DIR.mkdir(
    parents=True,
    exist_ok=True,
)

for number, pair in enumerate(
    pairs,
    start=1
):

    reference = pair["reference"]
    secondary = pair["secondary"]
    role = pair["role"]

    ref_date = reference["date"].strftime("%Y%m%d")
    sec_date = secondary["date"].strftime("%Y%m%d")

    pair_name = (
        f"kumamoto_{role}_{ref_date}_{sec_date}"
    )

    pair_dir = RESULT_DIR / pair_name
    download_dir = pair_dir / "download"
    product_dir = pair_dir / "product"

    download_dir.mkdir(
        parents=True,
        exist_ok=True,
    )

    product_dir.mkdir(
        parents=True,
        exist_ok=True,
    )

    print()
    print("=" * 70)

    print(
        f"SUBMIT {number}/{len(pairs)}:",
        pair_name
    )

    print(
        "Reference:",
        reference["granule"]
    )

    print(
        "Secondary:",
        secondary["granule"]
    )

    # ----------------------------------------------
    # HyP3 InSAR GAMMA
    # ----------------------------------------------

    job = hyp3.submit_insar_job(
        reference["granule"],
        secondary["granule"],
        name=pair_name,

        looks="10x2",

        include_wrapped_phase=True,
        include_displacement_maps=True,

        include_look_vectors=True,
        include_inc_map=True,
        include_dem=True,

        apply_water_mask=True,

        phase_filter_parameter=0.6,
    )

    # ----------------------------------------------
    # Wait for processing
    # ----------------------------------------------

    print("Waiting for HyP3 processing...")

    completed = hyp3.watch(
        job,
        timeout=12 * 60 * 60,
        interval=60,
    )

    # ----------------------------------------------
    # Download completed product
    # ----------------------------------------------

    print("Downloading InSAR product...")

    downloaded = completed.download_files(
        location=download_dir
    )

    # ----------------------------------------------
    # Extract ZIP
    # ----------------------------------------------

    for file_path in downloaded:

        file_path = Path(file_path)

        if file_path.suffix.lower() != ".zip":
            continue

        with zipfile.ZipFile(
            file_path,
            "r"
        ) as z:
            z.extractall(
                product_dir
            )

    print(
        "Completed:",
        pair_name
    )


print()
print("=" * 70)
print("ALL InSAR PROCESSING COMPLETE")
print("Output:", RESULT_DIR.resolve())

HyP3 processing can take some time, so I recommend running it in the background:

nohup python 2.make_insar.py > 2.make_insar.log 2>&1 &

You can monitor progress with:

tail -f 2.make_insar.log

*InSAR Data Is Ready
After HyP3 finishes processing and the product is downloaded, each observation pair contains a set of InSAR products.
For example:

data/
└── insar/
    └── kumamoto_pre_20260610_20260622/
        ├── download/
        │   └── ...zip
        └── product/
            └── S1DD_20260610T091329_20260622T091330_.../
                ├── *_corr.tif
                ├── *_wrapped_phase.tif
                ├── *_unw_phase.tif
                ├── *_los_disp.tif
                ├── *_dem.tif
                ├── *_inc_map.tif
                ├── *_water_mask.tif
                └── ...

The main products used later are:
*_wrapped_phase.tif Wrapped Phase
*_unw_phase.tif Unwrapped Phase
*_corr.tif Coherence
*_los_disp.tif LOS Displacement
At this point, we have completed the process of turning Sentinel-1 SLC acquisitions into a dataset that can be used for quantitative InSAR analysis.
Example: Wrapped Phase
Below is an example of a Wrapped Phase visualization generated by HyP3.

The colors represent wrapped phase values.
The repeating color pattern does not mean that the ground moved by a corresponding physical color-coded distance.
The phase still repeats periodically between approximately -π and +π.

Example: Unwrapped Phase
The following image shows the corresponding Unwrapped Phase.

The important distinction is:

Wrapped Phase
phase angle with wrapping
        ↓
Unwrapped Phase
continuous phase
        ↓
LOS Displacement
physical distance

The Unwrapped Phase is not yet the final distance measurement.
It is still phase, but the periodic wrapping has been resolved.
The radar wavelength is then used to convert the phase into physical LOS displacement.

What's Next?
In this article, I focused only on:

Sentinel-1 search
        ↓
SLC download
        ↓
Observation pairing
        ↓
HyP3 InSAR processing
        ↓
InSAR GeoTIFF products

I have not yet evaluated whether the earthquake produced a large displacement signal.
That will be the next step.
Using the products generated here, we can investigate questions such as:
How much did LOS displacement change before and after the earthquake?
Which pixels should be trusted based on Coherence?
What spatial patterns appear in the Wrapped Phase?
Can machine learning detect the earthquake as an anomaly?
Can self-supervised models such as MAE + Vision Transformer detect abnormal InSAR patterns?
The important point for this article is that the InSAR dataset is now ready.
We can now move from data preparation to actual earthquake deformation analysis.

Data and Processing
Data source:
ESA / Copernicus Sentinel-1 IW SLC
Distributed through:
NASA Alaska Satellite Facility (ASF) DAAC

InSAR processing:
ASF HyP3 InSAR GAMMA

Visualizing Surface Changes After the 2026 Kumamoto Earthquake with Sentinel-1 SAR and Google Earth Engine

Takeo — Sun, 02 Aug 2026 17:18:29 +0000

Introduction

On July 28, 2026, at approximately 4:27 p.m. Japan Standard Time, a magnitude 7.1 earthquake struck the Kumamoto region of southwestern Japan at a depth of about 10 kilometers.

The Japan Meteorological Agency reported a maximum seismic intensity of 7, the highest level on Japan’s seismic intensity scale. For readers outside Japan, this is not another expression of earthquake magnitude. Magnitude represents the energy released by an earthquake, while the Japanese seismic intensity scale describes the strength of shaking observed at individual locations. At intensity 7, unsecured furniture may move or topple, buildings may suffer serious damage, and landslides or major ground failures may occur.
https://www.data.jma.go.jp/multi/quake/quake_detail.html?eventID=20260728163528&lang=en

The earthquake caused fatalities, injuries, structural damage, power outages, transportation disruptions, and continuing emergency-response operations. One of the most widely reported locations was AEON Mall Kumamoto, where the earthquake was followed by an explosion and severe building damage.
https://www.reuters.com/business/environment/magnitude-71-earthquake-hits-japans-kyushu-region-jma-says-2026-07-28/

Where is Kumamoto?

Kumamoto Prefecture is located in Kyushu, the southwesternmost of Japan’s four main islands.

Tokyo, Kyoto, and Osaka are located on the much larger island of Honshu. Kumamoto lies considerably farther southwest, near the center of Kyushu. The prefecture includes Kumamoto City, Mount Aso, coastal and agricultural areas, and numerous smaller communities.

The study area used in this article covers Kumamoto City and surrounding areas including Kashima, Uki, Yatsushiro, and parts of the Aso region.
https://www.japan.travel/en/destinations/kyushu/kumamoto/

The historical context

The 2026 earthquake occurred only a little more than ten years after the devastating 2016 Kumamoto earthquake sequence.

In April 2016, the region was first struck by a strong foreshock and then by a larger earthquake at 1:25 a.m. local time on April 16. The Japan Meteorological Agency measured the later event as magnitude 7.3, while the USGS reported a moment magnitude of 7.0.

The 2016 sequence involved the Hinagu and Futagawa fault systems and caused major damage across Kumamoto Prefecture.

This article does not attempt to establish a direct seismological relationship between the 2016 and 2026 earthquakes. However, the geographic proximity and the region’s recent history make satellite-based change monitoring especially relevant.
https://www.usgs.gov/news/featured-story/magnitude-70-earthquake-japan

What this article does
This is the first article in a planned series.
In this initial step, I use:

Google Earth Engine
Google Colab
Sentinel-1 Synthetic Aperture Radar imagery
Python and geemap

The goal is to:

Retrieve a Sentinel-1 SAR image acquired before the earthquake.
Retrieve the first available image acquired after the earthquake.
Calculate the difference in VV-polarized radar backscatter.
Display areas with large changes on an interactive map.
Mark the location of AEON Mall Kumamoto as a geographic reference point.

This is a rapid, first-pass visualization rather than a final damage-classification product.

The objective is to identify locations that may deserve closer inspection using optical imagery, official damage reports, aerial photographs, field observations, and additional satellite analysis.

What is SAR?

SAR stands for Synthetic Aperture Radar.

Optical satellites observe sunlight reflected from Earth’s surface. This means that clouds, darkness, smoke, and other atmospheric conditions can limit what an optical sensor can see.

SAR satellites transmit microwave signals toward Earth and measure the signals reflected back to the sensor. This allows radar satellites to observe the surface during both day and night and through most cloud cover.

For this analysis, I use Sentinel-1, a European C-band SAR mission.

The Google Earth Engine collection:

COPERNICUS/S1_GRD
https://developers.google.com/earth-engine/datasets/catalog/COPERNICUS_S1_GRD

contains calibrated and terrain-corrected Ground Range Detected imagery. Its backscatter values are provided in decibels. Earth Engine applies preprocessing that includes orbit information, thermal-noise removal, radiometric calibration, and terrain correction.

Radar backscatter is affected by several factors:

Surface roughness
Building geometry
Soil moisture
Vegetation
Water coverage
Radar incidence angle
Satellite orbit direction

A major change in backscatter can therefore indicate a meaningful surface change, but it does not identify the cause by itself.

Implementation

Install the required libraries

Run the following cell in Google Colab:

!pip install -q -U earthengine-api geemap

Then import the libraries:

import ee
import geemap

About Earth Engine access and pricing
earthengine-api is Google’s official Python client library for Earth Engine. The library itself can be installed free of charge.

Commercial Earth Engine use is available through usage-based and subscription plans. As of August 2026, the Basic plan has a platform fee of $500 per month, while the Professional plan costs $2,000 per month. A Limited plan is also available without a fixed monthly platform fee, but compute and storage usage may still be charged.

Verified noncommercial projects—including qualifying educational, research, nonprofit, and personal-learning projects—can use monthly free compute quotas. Registration as a noncommercial project is required; simply being a student does not automatically configure the project for free access.

*Official information:
Google Earth Engine pricing
https://cloud.google.com/earth-engine/pricing

Earth Engine noncommercial tiers
https://developers.google.com/earth-engine/guides/noncommercial_tiers

Creating and registering an Earth Engine project
https://developers.google.com/earth-engine/guides/access

Earth Engine configuration in Google Cloud
https://console.cloud.google.com/earth-engine/welcome

Authenticate and initialize Earth Engine

ee.Authenticate()
ee.Initialize(project='YOUR_GOOGLE_CLOUD_PROJECT_ID')

Replace YOUR_GOOGLE_CLOUD_PROJECT_ID with the ID of a registered Google Cloud project.

For example:

ee.Authenticate()
ee.Initialize(project='ee-takeofuture')

The authentication step opens a Google account authorization flow. The project passed to ee.Initialize() is then used for Earth Engine requests.

Create a map centered on Kumamoto

Map = geemap.Map(
    center=[32.72, 130.70],
    zoom=10
)
Map.add_basemap('HYBRID')

The center is placed between the broader epicentral region and AEON Mall Kumamoto.
The HYBRID basemap combines satellite imagery with geographic labels, roads, and place names.

Define the area of interest
The selected area covers a relatively broad portion of Kumamoto Prefecture, including Kumamoto City, Kashima, Uki, Yatsushiro, and areas toward Aso and Amakusa.

kumamoto_aoi = ee.Geometry.BBox(
    130.40,
    32.45,
    131.10,
    32.95
)

ee.Geometry.BBox() uses the following coordinate order:
west longitude,
south latitude,
east longitude,
north latitude

The selected bounds are:
West: 130.40° E
South: 32.45° N
East: 131.10° E
North: 32.95° N

Load the Sentinel-1 collection

s1 = (
    ee.ImageCollection('COPERNICUS/S1_GRD')
    .filter(ee.Filter.eq('instrumentMode', 'IW'))
    .filter(
        ee.Filter.listContains(
            'transmitterReceiverPolarisation',
            'VV'
        )
    )
    .filterBounds(kumamoto_aoi)
)

Interferometric Wide Swath mode

.filter(ee.Filter.eq('instrumentMode', 'IW'))

IW stands for Interferometric Wide Swath. It is a common Sentinel-1 acquisition mode for wide-area land observations.

VV polarization

.filter(
    ee.Filter.listContains(
        'transmitterReceiverPolarisation',
        'VV'
    )
)

VV means that the radar signal is transmitted with vertical polarization and received with vertical polarization.

Geographic filtering

.filterBounds(kumamoto_aoi)

This retains scenes that overlap the Kumamoto study area.

Handle the time-zone conversion The earthquake occurred at approximately: July 28, 2026, 16:27 JST Earth Engine date strings are interpreted in UTC unless a time zone is explicitly handled. Japan Standard Time is nine hours ahead of UTC, so the corresponding UTC time is: July 28, 2026, 07:27 UTC I therefore define the event boundary as follows:

EARTHQUAKE_TIME_UTC = '2026-07-28T07:27:00Z'

This prevents an image acquired after the earthquake from accidentally being classified as a pre-earthquake observation.

Select the latest pre-earthquake image

pre_eq = (
    s1
    .filterDate(
        '2026-07-15T00:00:00Z',
        EARTHQUAKE_TIME_UTC
    )
    .sort('system:time_start', False)
    .first()
    .select('VV')
)

The collection is sorted from newest to oldest, and first() selects the most recent available observation before the earthquake.

“Pre-earthquake” does not necessarily mean that the satellite passed over Kumamoto only minutes before the event. It means that this is the closest available Sentinel-1 acquisition within the specified period.

Select the first post-earthquake image

post_eq = (
    s1
    .filterDate(
        EARTHQUAKE_TIME_UTC,
        '2026-08-05T00:00:00Z'
    )
    .sort('system:time_start', True)
    .first()
    .select('VV')
)

This time, the images are sorted from oldest to newest so that the first available acquisition after the earthquake is selected.

Only scenes already ingested into Earth Engine are available. Setting an end date in the future does not create or predict an image.

Print the actual acquisition times

The actual satellite observation times should be included in any interpretation of the result.

pre_date_jst = ee.Date(
    pre_eq.get('system:time_start')
).format(
    'YYYY-MM-dd HH:mm:ss',
    'Asia/Tokyo'
)
post_date_jst = ee.Date(
    post_eq.get('system:time_start')
).format(
    'YYYY-MM-dd HH:mm:ss',
    'Asia/Tokyo'
)
print('Pre-earthquake image, JST:', pre_date_jst.getInfo())
print('Post-earthquake image, JST:', post_date_jst.getInfo())

This prints the acquisition times in Japan Standard Time rather than UTC.

Calculate the SAR difference
Subtract the pre-earthquake VV image from the post-earthquake image:

diff = post_eq.subtract(pre_eq)

Conceptually:
SAR change = post-earthquake VV − pre-earthquake VV

A strongly negative value means that radar backscatter decreased after the earthquake.
A strongly positive value means that radar backscatter increased.
Possible causes include:

Changes to buildings or structures
Collapsed or tilted surfaces
Rubble or newly exposed objects
Landslides and sediment movement
Flooding or new water surfaces
Changes in soil moisture
Vegetation changes
Differences in orbit geometry
SAR speckle noise

The difference map is therefore best treated as a change indicator, not as a direct label for one specific type of damage.

Configure the visualization

vis_diff = {
    'min': -12,
    'max': 4,
    'palette': [
        '#d73027',
        '#fc8d59',
        '#fee08b',
        '#ffffff',
        '#e0f3f8',
        '#91bfdb'
    ]
}

The approximate interpretation is:

Red and orange: backscatter decreased These areas returned a weaker radar signal after the earthquake. Possible explanations include:
A building changed orientation or partially collapsed
A formerly complex surface became smoother
Ground failure altered the local geometry
An area became covered by water

These locations may represent earthquake-related changes and deserve closer examination.

White: relatively little change

The difference between the two observations is relatively small.
This does not prove that no damage occurred. Smaller changes, indoor damage, and changes below the effective spatial resolution may not appear clearly.

Light blue and blue: backscatter increased These areas returned a stronger radar signal after the earthquake. Possible explanations include:
Debris increased surface roughness
Fallen structures created new radar-reflecting geometry
Sediment or exposed materials changed the surface
Objects became oriented in a way that reflected more energy toward the satellite

Both strong red and strong blue regions can therefore be treated as locations of interest.

The values -12 and 4 are visualization limits chosen to make large changes easier to see. They are not universal damage thresholds. However, strongly colored areas can help narrow a broad region into a smaller set of locations for follow-up analysis.

Add the SAR layers to the map

Map.addLayer(
    pre_eq.clip(kumamoto_aoi),
    {
        'min': -25,
        'max': 0
    },
    '1. Pre-earthquake SAR',
    False
)
Map.addLayer(
    post_eq.clip(kumamoto_aoi),
    {
        'min': -25,
        'max': 0
    },
    '2. Post-earthquake SAR',
    False
)
Map.addLayer(
    diff.clip(kumamoto_aoi),
    vis_diff,
    '3. SAR backscatter change',
    True
)

The pre- and post-earthquake layers are initially hidden.
The difference layer is visible when the map first loads.
Users can switch between the following layers:

Pre-earthquake SAR
Post-earthquake SAR
SAR backscatter change

Mark AEON Mall Kumamoto
AEON Mall Kumamoto is located in Kashima Town, south of central Kumamoto City.
Because the mall was one of the most widely reported damage locations, I add it as a geographic reference point:

aeon_kumamoto = ee.Geometry.Point([
    130.7414,
    32.7431
])
Map.addLayer(
    aeon_kumamoto,
    {'color': 'cyan'},
    'AEON Mall Kumamoto'
)

Earth Engine point coordinates use:
[longitude, latitude]
This is the reverse of the [latitude, longitude] order commonly displayed by some mapping services.
A single Sentinel-1 pixel cannot describe the condition of an entire shopping mall. However, if strong red or blue changes appear around a location with independently reported damage, that spatial correspondence becomes a useful clue.
The mall marker therefore provides a reference for comparing the SAR change pattern with a known real-world location of serious impact.

Display the map

Map.add_layer_control()
Map

The map can now be explored interactively in Google Colab.
Users can enable and disable each layer from the layer control in the upper-right corner.

How to interpret the result
The resulting map shows several red and orange areas across Kumamoto Prefecture. These are locations where VV backscatter decreased substantially between the selected observations.

Changes to buildings, slopes, ground surfaces, sediment, and water coverage can alter the radar signal. Areas with unusually large differences may therefore indicate locations affected by the earthquake.

The map cannot, by itself, tell us:

Exactly what changed
Whether a building completely collapsed
Whether a change was caused by the earthquake
How severe the damage was

Nevertheless, the analysis is useful.

Satellite radar can scan a broad area and highlight places where the surface response changed significantly. Those locations can then be compared with:

RGB optical imagery
Government damage reports
News reports
Aerial photography
Rainfall records
Elevation and slope data
Field observations

In this sense, the SAR difference map acts as a guide for narrowing the search area, rather than as a final damage map.

Limitations of this first-pass analysis

Orbit direction is not matched Sentinel-1 observes Earth from both ascending and descending orbits.

Buildings and slopes may appear very different when viewed from opposite radar directions. Some of the measured difference may therefore be caused by observation geometry rather than physical surface change.

Relative orbit numbers are not matched Even if two images cover the same region, differences in relative orbit number and incidence angle can affect backscatter.

A more rigorous comparison should use scenes with:

The same orbit direction
The same relative orbit number
Similar incidence angles
The same polarization and acquisition mode

Only one image is used for each period
SAR imagery contains granular noise known as speckle.
Using several pre-earthquake and post-earthquake scenes and calculating a median or mean composite can reduce random variation and make persistent changes easier to identify.
Rainfall and moisture may affect the result
Radar backscatter responds to soil moisture, standing water, vegetation, and wet surfaces.
Any location with a large difference should therefore be checked against rainfall and weather data from the same period.
This is a screening analysis
The purpose of this first article is not to issue a final damage assessment.
It is to locate areas where the radar response changed enough to justify closer investigation.
Known damaged locations such as AEON Mall Kumamoto can also help evaluate whether satellite-observed changes correspond to documented real-world impacts.

Next step: matched SAR, RGB imagery, and AI
In the next article, I plan to make the analysis more precise by:

Matching the Sentinel-1 orbit direction.
Matching the relative orbit number.
Comparing multiple pre- and post-earthquake observations.
Reducing SAR speckle noise.
Adding rainfall, elevation, and terrain information.
Incorporating Sentinel-2 or other RGB optical imagery.
Applying AI-based image analysis to identify consistent change candidates.

SAR and RGB imagery provide complementary information.

SAR can detect changes in radar scattering even through clouds and at night. RGB imagery can help visually distinguish buildings, landslides, exposed soil, vegetation, and water when cloud-free observations are available.

AI can then be used to compare the two data sources, prioritize locations where both indicate change, and classify possible forms of damage.

This first visualization is therefore the initial screening stage. The next step will combine matched multi-temporal SAR, RGB imagery, additional geospatial data, and AI to produce a more reliable list of possible damage locations.

Complete code

!pip install -q -U earthengine-api geemap

import ee
import geemap

# Authenticate and initialize Earth Engine.
ee.Authenticate()
ee.Initialize(project='ee-takeofuture')

# Create a map centered on Kumamoto.
Map = geemap.Map(
    center=[32.72, 130.70],
    zoom=10
)

Map.add_basemap('HYBRID')

# Define the study area.
kumamoto_aoi = ee.Geometry.BBox(
    130.40,
    32.45,
    131.10,
    32.95
)

# Load Sentinel-1 IW scenes containing VV polarization.
s1 = (
    ee.ImageCollection('COPERNICUS/S1_GRD')
    .filter(ee.Filter.eq('instrumentMode', 'IW'))
    .filter(
        ee.Filter.listContains(
            'transmitterReceiverPolarisation',
            'VV'
        )
    )
    .filterBounds(kumamoto_aoi)
)

# July 28, 2026, 16:27 JST = July 28, 2026, 07:27 UTC.
EARTHQUAKE_TIME_UTC = '2026-07-28T07:27:00Z'

# Select the latest available pre-earthquake image.
pre_eq = (
    s1
    .filterDate(
        '2026-07-15T00:00:00Z',
        EARTHQUAKE_TIME_UTC
    )
    .sort('system:time_start', False)
    .first()
    .select('VV')
)

# Select the first available post-earthquake image.
post_eq = (
    s1
    .filterDate(
        EARTHQUAKE_TIME_UTC,
        '2026-08-05T00:00:00Z'
    )
    .sort('system:time_start', True)
    .first()
    .select('VV')
)

# Print acquisition times in Japan Standard Time.
pre_date_jst = ee.Date(
    pre_eq.get('system:time_start')
).format(
    'YYYY-MM-dd HH:mm:ss',
    'Asia/Tokyo'
)

post_date_jst = ee.Date(
    post_eq.get('system:time_start')
).format(
    'YYYY-MM-dd HH:mm:ss',
    'Asia/Tokyo'
)

print('Pre-earthquake image, JST:', pre_date_jst.getInfo())
print('Post-earthquake image, JST:', post_date_jst.getInfo())

# Calculate post-earthquake minus pre-earthquake VV backscatter.
diff = post_eq.subtract(pre_eq)

# Configure the difference visualization.
vis_diff = {
    'min': -12,
    'max': 4,
    'palette': [
        '#d73027',
        '#fc8d59',
        '#fee08b',
        '#ffffff',
        '#e0f3f8',
        '#91bfdb'
    ]
}

# Add the three SAR layers.
Map.addLayer(
    pre_eq.clip(kumamoto_aoi),
    {'min': -25, 'max': 0},
    '1. Pre-earthquake SAR',
    False
)

Map.addLayer(
    post_eq.clip(kumamoto_aoi),
    {'min': -25, 'max': 0},
    '2. Post-earthquake SAR',
    False
)

Map.addLayer(
    diff.clip(kumamoto_aoi),
    vis_diff,
    '3. SAR backscatter change',
    True
)

# Add AEON Mall Kumamoto as a reference point.
aeon_kumamoto = ee.Geometry.Point([
    130.7414,
    32.7431
])

Map.addLayer(
    aeon_kumamoto,
    {'color': 'cyan'},
    'AEON Mall Kumamoto'
)

Map.add_layer_control()
Map

Conclusion
This article used Google Earth Engine, Google Colab, and Sentinel-1 VV-polarized SAR data to visualize radar-backscatter changes before and after the 2026 Kumamoto earthquake.

The resulting difference map does not provide a final building-damage classification. However, it can reveal locations where the radar response changed substantially and help prioritize areas for further investigation.

By marking AEON Mall Kumamoto, the analysis also provides a way to compare a documented damage location with the surrounding satellite-observed change pattern.

In the next stage, I will improve the comparison by matching Sentinel-1 orbital conditions, using multiple observations, incorporating RGB optical imagery and additional geospatial data, and applying AI to identify more reliable earthquake-related change candidates.

How to Use an NVIDIA GPU Inside a Docker Container

Takeo — Mon, 27 Jul 2026 18:00:38 +0000

I do not normally use Docker very often. However, I recently needed to install PyTorch3D, a library that is no longer actively updated, and I could not get it working properly in my current environment.

I could have launched a separate GPU machine running the older Ubuntu 22.04 or installed another CUDA version on the host system. However, I was concerned that adding multiple CUDA versions might cause problems with library paths and symbolic links.

So, somewhat reluctantly, I decided to use Docker.

Running a normal Docker container is relatively straightforward: pull an image and start the container. However, when using a GPU machine, some additional configuration is required to make the host GPU available inside the container.

This article is a short memo describing the setup process.

Host environment

My host environment is Ubuntu 24.04 with CUDA 13.1.

The following command also displays information about the NVIDIA driver and the GPU:

# nvidia-smi

The output looks like this:

Although nvidia-smi may display a different CUDA version, the CUDA Toolkit installed on the host is CUDA 13.1, as shown by the output of nvcc --version.

Target Docker environment

For this test, I wanted to launch a container with the following combination:

Ubuntu 22.04
CUDA 12.4.1

To make the host GPU available inside Docker containers, the NVIDIA Container Toolkit must first be installed.

Installing the NVIDIA Container Toolkit

I installed it using the following commands:

# curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# apt update
# apt install nvidia-container-toolkit

The installation completed without any problems.

Configuring Docker to use the NVIDIA runtime

Next, configure Docker to use the NVIDIA Container Runtime and restart the Docker service.

# nvidia-ctk runtime configure --runtime=docker
# systemctl restart docker

You can confirm that the NVIDIA runtime has been registered by running:

# docker info | grep -i runtime
 Runtimes: nvidia runc io.containerd.runc.v2
 Default Runtime: runc

You can also inspect Docker's configuration file:

# cat /etc/docker/daemon.json
{
    "runtimes": {
        "nvidia": {
            "args": [],
            "path": "nvidia-container-runtime"
        }
    }
}

The default runtime remains runc, but the NVIDIA runtime is now available when a container is started with GPU support.

Selecting a CUDA Docker image

For this example, I used a CUDA 12.4.1 runtime image based on Ubuntu 22.04.

Other CUDA and Ubuntu combinations can be found on the NVIDIA CUDA image page on Docker Hub:

Selecting a CUDA Docker image

For this example, I used a CUDA 12.4.1 runtime image based on Ubuntu 22.04.

Other CUDA and Ubuntu combinations can be found on the NVIDIA CUDA image page on Docker Hub:
CUDA Image

Testing GPU access inside the container

To confirm that the GPU is available inside the Docker container, run nvidia-smi in the container:

# docker run --rm --gpus all \
  nvidia/cuda:12.4.1-runtime-ubuntu22.04 \
  nvidia-smi

The options used here are:

--rm: Automatically removes the container after it exits.
--gpus all: Makes all available host GPUs accessible inside the container.
nvidia/cuda:12.4.1-runtime-ubuntu22.04: Specifies the CUDA 12.4.1 runtime image based on Ubuntu 22.04.
nvidia-smi: Runs the NVIDIA system management command inside the container.

If the setup is working correctly, information about the host GPU should be displayed:

The downloaded Docker image can also be confirmed with:

# docker image ls

Conclusion

By installing the NVIDIA Container Toolkit and starting the container with the --gpus all option, I was able to use the host GPU from a Docker container running an older combination of Ubuntu and CUDA.

This approach is useful when a library requires an older CUDA or operating-system environment and you do not want to modify the CUDA configuration of the host machine.

In my case, Docker allowed me to prepare an Ubuntu 22.04 and CUDA 12.4.1 environment without adding another CUDA installation directly to my Ubuntu 24.04 host.