Killian Embler

Overview

LECTER is a full lower limb exoskeleton for able-bodied people who work physically intensive jobs and need assistance to prevent injury, while wearing something unrestrictive enough not to inhibit them. It does this with 10 active degrees of freedom and 4 passive. In practice it is not a commercial project and works primarily as a research test platform.

Team

I work alongside Bryan Gonzalez, Manuel Buenrostro, Max Pizzurro, Cole Finney, and Dr. Shuzhen Luo, our overseeing faculty advisor. Bryan initially led the project. I took over as lead at the end of the Fall 2025 semester, after he finished his master's degree.

My role

• Mechanical design, such as the universal ankles with dual four-bar linkages and Heim joints.
• Redesigning the electrical system to include a simple PCB and dual E-stop system for compactness, safety, and battery operation.
• Tuning the impedance controller for squat assistance.
• Running tests with Max or Cole wearing the exoskeleton.
• Leading the presentation of our work at the IROS 2026 workshop.

Hardest problem

The hardest technical problem has always been balancing an exoskeleton that is as unrestrictive as possible against structural integrity and controllability. There have been many times where we added mobility, only to have the new moving components break under the full stress of an assisted squat or sit-to-stand.

Results so far

In low-torque impedance controller squat tests, peak output reached 6-8 Nm at each hip and knee joint. That was enough to offset the weight of the exoskeleton during a squat, and it showed the structure holding up mechanically while applying a smooth curve of assistance through the whole motion. Each actuator can output up to 26 Nm if needed. Further figures and details are in the extended abstract.

Architecture and what's next

A high-level controller (of any kind) runs on a Raspberry Pi 4 and sends CAN signals that delegate low-level control to an ODrive S1 on each actuator. Future work focuses on more complex control methods, such as deep reinforcement learning, to match natural human gait and movement, conserve energy, and apply torque to the joints as effectively as possible. Changes in progress also aim to increase actuator torque, reduce weight, increase durability, and maximize user safety and comfort.

Why it exists

SAMSARA is the flagship product of Embler Control Systems. Many of our student members were in STEM or rocketry clubs in high school, then realized after starting an engineering degree that they were still unprepared for a large part of what real engineering involves. I had the same experience at my high school on Project Meridian, which set out to build a TVC model rocket. Even though we had spent much of our lives doing model rocketry, the PCB design, software, and controls work was nearly insurmountable for the team.

SAMSARA is meant to be a bridge into avionics and intelligent launch vehicles, and to let people get meaningful data from every launch so they can evaluate and iterate on their rocket designs. It also has a place in college rocketry labs, where good avionics and data measurement tools are always in high demand.

Team

The team is 12 engineering and physics students from 3 universities in Florida, 3 of whom work mainly on the business side. As CTO, I lead the other 9, split into PCB design, software, and implementation teams. Until summer 2026 the team had not fully expanded, and the people who had joined were still training with me, so I personally handled a large portion of SAMSARA's development.

Version history

• V0 (fall 2025): The first PCB I ever designed start to finish on my own, made before the project was named SAMSARA. A bare-bones 2-layer board with a few breakout boards for sensing and power. It was large and bulky, but it just barely let an Arduino Nano read IMU data and move servos.
• V1: More refined, with altitude sensing and SD card data recording added. It flew more than 5 times on our ALTAI platform in spring 2026 and gave us data and feedback to improve the design.
• V1.5 (never produced): A big jump in ambition. I went straight from a 2-layer breakout board to a fully integrated microcontroller design based on the Teensy 4.1 architecture, on a 4-layer PCB with a custom DCDC converter.
• V2: The current version, in production and in bench testing.

V0 and V1 were designed in EasyEDA. V1.5 and V2 were designed in KiCad.

Hardest problem

The hardest technical problem for me has definitely been the PCB design. With V1.5, I bit off more than I could chew. By the time I reached a finalized design I had put in nearly a hundred hours, and it was still clearly unrefined, with poor EMI management. Most significantly, it used an inconsistent assortment of components that drove up assembly cost and complicated sourcing, and it depended on a critical flash memory part that entered a multi-month global shortage partway through the project.

For V2, I went back to the drawing board with the experience from that failure. I set strict design requirements for myself: FCC limitations, supplier sourcing, existing inventory, replaceability of parts, and estimated production cost, all balanced against keeping full functionality. I made high-level design diagrams first, sourced the key components, and only then moved into a KiCad schematic and the board layout, applying what I had learned about proper circuit design for microcontrollers.

V2 still takes some inspiration from the core Teensy architecture, and uses a Teensy bootloader chip to help with firmware. It takes much less than V1.5 did, since it is designed specifically for flight computing and not as a general-purpose development board.

Status

The newest version is in production and currently going through bench testing and software development. It has not yet flown, so no flight data is available.

Why it exists

The hip exoskeleton started as a middle ground for the Robotics Intelligent Learning Lab between in-house controls research and in-house mechanical design. Two of the lab's main projects sit on either side of that gap. LECTER focuses on mechanical design but lags behind in controls because of its added mechanical complexity. A second hip exoskeleton project, led by a PhD student, focuses on reinforcement learning and not on in-house mechanical design.

I was given the task of bridging the two: a new hip exoskeleton that uses what we learned mechanically from LECTER and begins testing with reinforcement learning.

Team

I am the primary contributor, with Dr. Shuzhen Luo as faculty advisor. Members of the LECTER team have recently helped prepare for the reinforcement learning work.

Key design decision

The biggest choice was removing the two hip degrees of freedom in the coronal plane that LECTER has. This exoskeleton focuses on gait, which does not need significant motion in the coronal plane, and removing those actuators allowed hip width adjustability, a more condensed back plate section, and an overall decrease in weight. Hip width adjustability lets the exoskeleton fit a wider range of wearers, which gives us more versatility in gait patterns. At each hip, flexion/extension is actuated and abduction/adduction is passive.

Hardware

The actuators are the same custom 3D printed cycloidal actuators used on LECTER, evaluated on the actuator testbed up to 26 Nm. The exoskeleton uses a wide variety of 3D printed parts depending on function, in PETG, PLA, polycarbonate, and resin.

FEA was used heavily on both LECTER and the hip exoskeleton. Exoskeleton materials need to be lightweight and unrestrictive while keeping a significant safety factor so a human user is never at risk. Since much of both exoskeletons is 3D printed, parts that take multi-axial torques, like the hip chassis, need in-depth analysis to make sure they can handle the full actuation load before a human ever wears the exoskeleton.

Hardest problem

This was the first project where I had expectations to meet but could work at my own discretion. That made design decisions hard, like what to keep or simplify mechanically and how it would benefit the project overall. The issue seems small, but it held back my work until I learned to take my design ideas, back them with reasoning under design constraints, and then carry them out with confidence that my decisions rested on sound logic.

Status and what's next

The exoskeleton is in the late stages of assembly and has not been fully tested. The new PCB design is complete but has not been manufactured, so it currently uses a less compact wired setup. The controller is being built from simulations of a high-fidelity human model interacting with the exoskeleton's URDF, to produce a sim-to-real controller that will run on the exoskeleton's Raspberry Pi 4.

Next is refining the hardware implementation and starting to train the reinforcement learning controller for gait testing. Metabolic cost will be assessed in human experiments. It is one of the primary metrics of the other hip exoskeleton at the lab, so it allows a direct comparison of the mechanical designs and the controllers.

Overview

ALTAI is a thrust vector controlled model rocketry system designed as a high-performance testbed for the Embler Control Systems flight computers. I see TVC stabilization of a finless rocket as an excellent demonstration of what a flight computer can do: rapidly process sensor inputs, run control algorithms, and give precise control outputs throughout a flight, even at a small scale.

The rocket is a simple external shell around a self-supporting internal architecture that holds all the avionics and output systems, like the gimbal.

Team and role

The team is the same as SAMSARA's. I completed most of the early design work, and Yusong Liang, an undergraduate, contributed extensively on the software side. For more on the teams and the company, see the Embler Control Systems website.

Hardest problem

The hardest technical problem was the software. Arduino Nanos are fantastic learning tools, but they hit a wall when parsing sensor inputs quickly and running controls out to servo motors. TVC is also a demanding area of model rocketry with very little documentation on proper implementation. Getting effective gimbal actuation took studying the basics of quaternion analysis, borrowing ideas from camera stabilization gimbal software, and a long iteration process within the limited computation and memory of an Arduino Nano.

Flights

ALTAI has flown more than 5 times, carrying SAMSARA V1 (and V0 once). Flights reach roughly 30-40 ft at low velocity, primarily on D class motors, chosen deliberately to produce low-velocity test hops that allow closer study of the stabilization.

During one of our most successful launches, the system recovered and held a vertical trajectory despite the low velocity and a gust of over 20 mph. Unfortunately, the data from that flight was lost. Power disconnected on impact and interrupted the SD card write. That has since been fixed: the computer now detects altitude and finalizes data recording before landing.

Recovery stage

We designed a recovery stage that needs no deployment charges. The parachute sits in the nose cone, which is made of two spring-loaded fairings held shut by pins. A servo pulls the pins when the computer's altimeter detects apogee.

Status

Use and development of the rocket have slowed while we focus on bench testing the new flight computer. The implementation team is reworking the architecture to be lighter, more precise, and to fit the new computer, which will soon begin test flights for full validation.

Overview

This project was built to do in-depth analysis of the custom 3D printed cycloidal actuators developed for LECTER. I developed the platform and studied the actuators alongside Manuel Buenrostro. I designed much of the testing rig and tried to make it as modular and adjustable as possible so other actuators can be tested later. Manuel designed the spider coupling that connects the motor to the dynamometer and helped with the overall rig.

I also took charge of the experimental design and the microcontroller communication with the DYN-210 dynamometer, which is the core sensing device of the apparatus. Each actuator was tested with a linearly increasing torque output against sliding friction until it stalled.

Hardest problem

The hardest technical problem was communication between the controller and the DYN-210. Its output is a frequency-modulated signal that needed low-interference pullups and voltage dividers to work with the 3.3V SparkFun Pro Micro collecting the data. Documentation was limited and often roughly translated from Chinese. Getting the communication parameters right in my Arduino code was difficult, and it required my own basic Chinese along with help from native speakers I know who do not have a technical background.

Results

The testbed was used for a full evaluation of the cycloidal actuators, producing several important figures, including the key metrics of 26 Nm peak torque output and 94% torque transmission efficiency. The rig and dynamometer have a capacity of 100 Nm.

Status

The project is on hold while the feedback from the testbed is used to iterate on and improve the cycloidal actuators.

Overview

OpenMutt is a low-cost quadruped test platform that is easy to manufacture. It is an externally funded lab project of the Engineering Physics Propulsion Lab, with 12 actuators controlled by a Jetson. I joined the team as a freshman at EPPL and have been a contributing member since, working on the electrical, mechanical, and URDF parts of the project.

Joint jigs

The jigs allow the joints to be zeroed in an exact position when the controller initializes, and they keep results repeatable between testing sessions.

Hardest problem

The largest ongoing problem has been getting the gait working and overcoming the mechanical problems that interfere with the controls. In the current gait the robot holds its legs in the wrong positions, sitting too low to the ground, and its motion is not smooth enough, which often stalls motors and causes the controller to fail. At its core this is a control issue, but reducing backlash in the limbs and increasing motor torque capacity will make the control problem easier to solve in the long run. We have also worked to cut weight as much as possible through compact redesigns and 3D printed manufacturing.

Status

The quadruped has performed several walking demos in the lab (internal to the lab), primarily on a tether to take some of the weight off the robot and keep the environment controlled. Work is underway to update the cycloidal actuators for higher torque output and to improve the controller toward a consistent gait off the tether.

Overview

OpenArm is a 5-DOF 3D printed robot arm designed to complement OpenMutt. It mounts on the quadruped's back to increase its functionality and interaction with its environment. I was one of the founding members of the project in Spring 2025, and I contributed a significant part of the mechanical design, the URDF modeling, and the manufacturing and assembly of a physical prototype.

The arm is cable driven, with 3D printed cycloidal gearboxes at the base joints. Keeping actuators off the outer part of the arm removes weight from it, but introduced backlash problems. It took several iterations to get the right tension in the system and reliable operation for precise tasks.

Funding and presentation

The work received support from an ERAU Spark Grant and was presented at the 2025 Student Research Symposium, with both demos and a poster.

The redesign

In spring 2026, another EPPL project, Amigo, which designs payloads for the Unitree Go2 quadruped, asked us to adapt the arm into a more refined and compact version. The new design drops cable-driven actuation in favor of high torque density CubeMars actuators, and gives up one degree of freedom (wrist rotation), so the mini arm is 4 DOF. The new arm and dog combination was to be presented to ERAU executives and the project's industry supporter.

Hardest problem

The hardest part by far was the timeline. Significant redesigns had to be made, implemented, evaluated, and revised in time to prepare for the demonstration.

Results

The mini arm works effectively with high torque capacity and little backlash, and it is within the constraints to mount on the Go2 payload. The demonstration was successful.

My role and team

I was part of the EPPL team and contributed significantly to the initial design and testing of the base arm, and Manuel Buenrostro developed the end effector.

Status

Work is in progress to further reduce backlash on the large version, reduce overall weight, and fully integrate its controls and electronics with those of the OpenMutt quadruped.

Overview

A marine ecosystem simulator built around a genetic algorithm. The user picks a coral reef, open ocean, or deep sea trench, then adds or removes species from a directory of 49 base species (and can define new ones in the program). Time advances in monthly turns, and the user watches whether the ecosystem holds its balance or collapses. Each organism carries eight genetic stats that drift over generations through reproduction. Every turn includes aging and death checks, grazing on producers, predation, reproduction, and an update of a Shannon biodiversity index.

The full design, including the equations behind each mechanic, is in the Software Design Document linked below.

Design

The program is built from eleven classes in two inheritance hierarchies (environments and organisms), plus supporting classes for species data, the species directory, and predation. A single driver class runs a text menu and handles all file input and output, so save files and the species directory are never edited by hand.

Hardest problem

In terms of actual development, the hardest problem was approaching the complexity of a real ecosystem in software and deciding what to simplify and what to keep high fidelity, so the model would give meaningful results. I handled that in a few ways, such as simplifying the predation system and using asexual reproduction while keeping the processes behind them. Tuning the system for greater fidelity and long-term stability would take more time and biological background than I had at the time, so getting even partial success through experimentation was very satisfying.

Results

Full environmental studies were not performed, but testing showed that introducing an invasive predator species to a coral reef often more than halved the time before the ecosystem collapsed. Removing important species had a similar effect.

What's next

The next major steps are increasing the accuracy of the simulation and getting more ecological backing for its parameters.