Bringing AI Education to Life with Sn.AI.l
This summer I had the opportunity to intern at the Institute for Intelligent Systems and Robotics (ISIR) in Paris, France. During my internship I designed the full electrical architecture and core software systems for an AI educational robot.
In this post, I’ll walk you through what the goal of this project was, what I did and why I did it, and finally, I’ll showcase a demo of Sn.AI.l.
Background
I was able to join the ISIR thanks to my tutorial supervisor, Louis Simon. After nagging him for many classes he recommended me to Dr. Nizar Ouarti, the director of the ASIMOV team at the ISIR which focuses on the interaction of robots with their environment. The day that my supervisor told me he talked to Dr. Ouarti I received a call from him. This call kept on getting better. As a first year university student I expected only to observe their work at the laboratory for a week or two. During this call not only did Dr. Ouarti grant me an internship where I would work directly on the project instead of observing but actually get paid for it. He was actually looking for someone to handle creating the interface for the project and communication between a computer and the robot. But this changed later.
A week or two after getting accepted I met one of my future coworkers, Louise, completely by chance. I was eating at the student cafeteria and I overheard someone speaking in English about Canada, my home country. I had to join in so we started talking about what she was doing in Paris. She told me that she is studying in Canada but currently interning at the ISIR for the summer, I said I’m also interning there for the summer. When I gave her my name she realized that we’d be working together, my future boss had told them I’d be joining them. What are the odds that we’d eat lunch at the same cafeteria, on the same day, at the same time, at the same table, right next to each other.
Louise introduced me to the project which got me even more excited.
The Goal
Artificial intelligence is driving today’s technological revolution, transforming the way we live and work. We encounter AI systems every day. As some jobs disappear and new ones emerge, it’s vital to equip future generations with the skills to understand and work alongside AI.
And this isn’t just for engineers — every field is touched by AI. In logistics, it can optimize delivery routes; in farming, it can automate crop care and milking. The next generation should have at least a foundational understanding of AI, both to use it effectively and to shape its impact.
That’s why we built Sn.AI.l, to make AI understandable, interactive, and fun.
Step 1 – Data
AI starts with data. With Sn.AI.l, students create and collect their own datasets by driving the robot and recording its sensor inputs. Then, with one click, they can train the robot and see the results immediately like racing Sn.AI.l through an obstacle course.
For those ready to go further, Sn.AI.l supports reinforcement learning, where the robot generates its own training data instead of relying on students to provide it. It learns entirely through trial and error, in the real world or in simulation, without any human-labeled datasets.
Step 2 – Algorithms
We don’t stop at data collection. Sn.AI.l’s interface makes AI algorithms, and the robotics concepts behind them, visible and intuitive. Students can start with simple methods like k-nearest neighbors and progress to deep neural networks, watching in real time as the robot’s “thinking” evolves.
Step 3 – Programming
With Sn.AI.l’s visual building-block interface, students can start coding with zero prior experience. They can create scripts for the robot to follow, respond to sensor data, and trigger AI models. With access to LiDAR, a depth camera, and motors, they can tackle classic robotics challenges like navigating in a room by detecting and avoiding obstacles and mapping its environment.
For advanced learners, full Python access opens the door to industry-standard tools and deeper control over every sensor, motor, and AI process.
In a world where AI shapes every industry, the ability to understand, experiment with, and innovate using intelligent systems will define the next generation’s opportunities.
My Role in Making Sn.AI.l
As mentioned before, I joined the project 2 weeks after my two coworkers, Louise and Mehdy. Lucky for me, they handled the less enjoyable phase of market research and planning.
I started out on the robot’s interface. The idea was simple: the robot would broadcast its own Wi-Fi network, and once connected, the user could go to snail.local to access a web interface.
To build this, I used HTML, CSS, and FastAPI. FastAPI handled two main jobs:
- Sending actions from the website to Python so the robot could respond.
- Streaming sensor data back into the web interface.
My first version had a homepage with a live camera feed and a D-pad for movement. It only took me two days to get it working, so after that quick win, I moved on to bigger challenges.
Electrical Design
Next up: the electrical design. I began with the most important aspect, motor control. The initial architecture planned out by my colleagues would use a SKR MINI E3 V3.0 Control Board to control 4 stepper motors. I decided to opt for a custom PCB instead.
I chose this solution because we needed to have a soft shutdown circuit as we would have a Jetson Orin Nano onboard — a small computer specialized for AI to handle all of the robot’s AI needs. You can’t just cut power to it as it can corrupt files. We also needed to read battery voltage to display battery percentage, control a servo motor for the head tilt of the snail and potentially control 5 more for a robot arm, and have 4 encoders for the 4 wheels.
So I began prototyping. I started on a breadboard with four stepper drivers and a hacked-up 12V power supply (I literally cut the DC jack off to wire it directly). Sketchy? Yes. But it worked.
Finding proper documentation for the drivers was a pain, and setting the VREF was trial-and-error. Add to that a jungle of wires, and mistakes were easy — so easy that I fried more drivers than I’d like to admit. Louise even made memes about it.
Once I got the motors spinning, I added UART-based torque control and stall detection. At this point I needed two breadboards just to fit all the wiring. Needless to say, I was eager to move to a PCB.
Soft Shutdown System
Initially I just wanted to use one MOSFET. I chose an N-MOSFET and thought I could turn it on with 12V from a momentary button and then keep it latched with 3.3V from the ESP32 through another diode. However, this didn’t work because as a high-side switch the N-MOSFET’s source is already sitting at 12V, so the gate would need to be driven several volts above 12V.
Next I tried a P-MOSFET with the gate pulled up to 12V so it would default off, and then used the button or the ESP32 to pull the gate down to GND through diodes. In theory that should have worked, but in practice it was flaky.
The Solution
What I finally arrived at was a circuit where the pushbutton sends a 12V pulse into a small transistor, which in turn pulls the gate of a P-MOSFET low to power the board. Once the ESP32 boots, it latches the transistor on with its own 3.3V GPIO, so power stays stable even after the button is released.
Pressing the button again produces another 12V pulse, but this time it’s stepped down through a divider into one of the ESP32’s inputs. That tells the ESP32 to send the shutdown command over USB, wait until the Jetson is finished, and then release the latch.
It wasn’t something I pulled from a schematic online — it was the result of a lot of trial, error, and learning what didn’t work before finally building the circuit that did.
Designing The PCB
The first step in creating a PCB is choosing the right design software. For me, that was EasyEDA. From the moment I tried it, the workflow felt natural and straightforward. I had experimented with KiCad, but I found the interface less intuitive and it lacked an easy way to share my work online.
EasyEDA’s built-in online viewer made collaboration simple, allowing my coworkers to review designs without installing extra software. On top of that, it integrates seamlessly with JLCPCB, the manufacturer we selected, which streamlined the entire design-to-fabrication process.
Power System
The circuit starts with 12V input at the PDC004 module, then passes through a 12V/4A fuse before entering the source of a P-channel MOSFET. This MOSFET is switched by pulling its gate to ground. The gate itself is controlled by another P-channel MOSFET.
The second MOSFET’s source is tied to ground, and its gate connects to two fast-switching diodes. One diode leads to a normally-open pushbutton that provides a 12V pulse when pressed. The other connects to an ESP32 GPIO pin, which supplies 3.3V to hold the MOSFET on once the button is released.
Protection and Smoothing
Towards the stepper motor drivers there is a TVS diode to clamp voltage spikes and a smoothing capacitor. Stepper drivers are noisy loads — when the motors decelerate or switch phases, they can kick energy back onto the supply rail. The TVS diode safely clamps any overvoltage by dumping the excess energy to ground, and the capacitor absorbs the short bursts of current so the supply line stays smooth.
Control and GPIO Pin Shortages
Control-wise, the ESP32 is connected to 4 stepper motor drivers, a voltage divider from the battery to read its voltage, a servo motor, and a MOSFET module to turn on the Jetson. Each stepper motor driver uses 4 GPIO pins (STEP, DIR, DIAG, INDEX) — I ran out of pins fast. That’s why I had to use some boot pins, but I chose them carefully.
UART Communication
All four TMC2209 drivers share a single UART with the ESP32. The ESP’s TX line fans out directly to all the drivers’ RX pins, while their TX pins are tied together and then pass through a 1kΩ resistor before reaching the ESP32’s RX.
Object Recognition
The next challenge was giving the robot the ability to see and understand its surroundings. My goal was to design a system that could detect everyday items out of the box, but also learn new, custom objects defined by the user.
The frontend is built with HTML/JavaScript, while the backend runs on a FastAPI server powered by multiple AI models. For general-purpose detection I used YOLOv5 (via ONNX Runtime for speed), and for custom object recognition I implemented NanoOWL alongside MobileNetV2 embeddings, using an Intel OAK-D depth camera.
Object Recognition Demo
Watch the object recognition demo on YouTube
Code Snippets
YOLOv5 for predefined objects (80+ COCO classes):
YOLOV5N_ONNX_PATH = 'yolov5n.onnx'
COCO_NAMES_PATH = 'coco.names'
with open(COCO_NAMES_PATH, 'r') as f:
COCO_CLASSES = [line.strip() for line in f.readlines() if line.strip()]
ort_session = ort.InferenceSession(YOLOV5N_ONNX_PATH)MobileNetV2 embeddings for user-defined objects:
mobilenet = mobilenet_v2(pretrained=True)
mobilenet_embed = torch.nn.Sequential(
mobilenet.features,
torch.nn.AdaptiveAvgPool2d((1, 1)),
torch.nn.Flatten()
)Key Technical Challenges
- Running multiple AI models efficiently — Moved YOLOv5 to ONNX Runtime for faster inference, added a configurable sliding-window stride, and scheduled YOLO runs first with custom detection filling in the gaps.
- Bounding box misalignment between models — Wrote a scaling/transform function to map YOLO’s resized inputs back to the original frame cleanly.
- Adding real-world distance measurements — Combined YOLO detections with OAK-D depth frames. For each bounding box, the system computes the average depth inside the region.
Blockly Editor
Once the robot had vision and recognition capabilities, the next step was to give users a way to program behaviors without writing code. To achieve this, I built a robot control interface that combines visual programming with real-time computer vision and robotics.
The environment includes both a Blockly-based visual editor and a Python text editor, all connected to a FastAPI backend that communicates with the physical robot.
Blockly Editor Demo
Watch the Blockly editor demo on YouTube
The blocks are organized into intuitive categories:
- Events: script triggers (e.g. “when flag clicked”)
- Motion: robot movement commands
- Line Following: specialized blocks for tracking lines
- Control: loops, conditionals, and flow control
- Sensing: object detection and distance measurement
- Operators: logic and math operations
Live Camera Feed
The interface integrates the live vision system so programs can react to the environment:
function checkCameraUsage() {
const code = Blockly.JavaScript.workspaceToCode(blocklyWorkspace);
const usesCamera = code.includes('isObjectDetected') ||
code.includes('getObjectDistance');
if (usesCamera) {
cameraContainer.style.display = 'flex';
startCameraFeed();
startDetectionTracking(code);
}
}Robot movement commands are passed over serial to an Arduino controller:
def move_robot_command(action: str):
if ser and ser.is_open:
command_to_send_to_arduino = f"{action}
"
ser.write(command_to_send_to_arduino.encode('utf-8'))
return {"status": "ok", "received": action}Jetson Orin Nano Setup
Since we needed SLAM and Reinforcement Learning on the Jetson, I opted to install an NVMe SSD. The first one that I bought was a PNY CS1030. I tried multiple methods to get it working but nothing worked.
Finally, I bought a Lexar NM620 instead which worked perfectly right away. The problem was that the CS1030 lacked a DRAM cache, meaning it couldn’t keep its mapping table in fast memory and had no Host Memory Buffer support to fall back on.
SLAM
I chose RTAB-MAP SLAM for this project because it could generate voxelized 3D maps of the environment and supported LiDAR and wheel odometry inputs. I could have used NVIDIA’s Isaac SLAM which is more optimized for the Jetson Orin Nano, but it didn’t support LiDAR input or wheel odometry.
RTAB-MAP was installed via Docker (building from source on ARM was painful). I used three.js to visualize the point cloud on an HTML page.
The system works seamlessly: an HTTP request triggers the start, the FastAPI backend spawns rtabmap, and the status is checked every 5 seconds — students don’t need to touch the command line.
Assembly
When my new PCB arrived, everything worked perfectly — except the soft shutdown system. It would behave very strangely: sometimes it wouldn’t turn on, other times it wouldn’t turn off.
What I thought would be a quick fix turned into three long days of debugging. In the end, the solution was surprisingly simple: replacing the BJT transistor with an N-channel MOSFET.
Conclusion
Building Sn.AI.l was an incredible experience that taught me more than any classroom ever could — from PCB design and soft shutdown circuits to computer vision pipelines and visual programming interfaces. The robot is now capable of teaching students the full AI pipeline: collect data, train models, and deploy on a real robot.