RATS from Myongji University (Korea): our own 10MB language model running on the LattePanda Mu N305
RATS.MJU 2026-10-06 15:42:20 65 Views2 Replies Hi everyone, I'm Mingyu Park from RATS (Robotic Automatic Technology Society), the robotics and embedded club at Myongji University in South Korea. We've been running since 1993 and have around 80 members. Our club page is at https://join.mju-rats.com/
.
A while back the LattePanda team sponsored us with a Mu N305 16GB module. I wanted to come back and show what we've been doing with it.
.
First, some good news. The project running on this board was awarded the Myongji University President's Award at the 5th Creative Software Competition, in the AI Applications division. The photo below is from the award ceremony, with our club logo and the LattePanda logo.
.
What we're building is called Industry Gyu Arm. You speak to it in plain language and it drives a SO-ARM101 robot arm, with every motion verified in a digital twin before the real arm moves.
.
The part that matters for this forum is what the Mu is actually running. Two pieces of software we wrote ourselves.
.
RACHEL is a small language model we trained from scratch. About 10 million parameters, 10MB on disk, 21.9MB of memory at runtime. Its only job is turning a spoken instruction into a sequence of blocks, the way Scratch works. Coordinates, paths, reachability and collision checks are all plain computation, not the model. On a 200-sentence validation set it scores 98.5%. We gave the same sentences to Gemma 4 E4B, a 5.15GB general purpose model, and it managed 39%. A model 500 times smaller, running on a single CPU thread, beat it.
.
That last point is why the Mu is a good fit. We don't need a GPU. We need a machine that can hold the rest of the system while a tiny model does its job on the CPU, and the N305 does that comfortably.
.
AI is something we're studying as a club, not just using. RACHEL is 10MB today, but it's ours from the ground up, trained from scratch rather than fine-tuned. We want to keep going and build models at 100MB, then 1GB, and eventually up to around 16GB, and see what changes at each step.
.
The other one is HOTEL, an app we're building that designs PCBs for you. You describe the board you want and it handles placement, routing, verification and the fabrication files. Right now we're using it to design DUSK V1, a small TPU built from 74HC logic chips and multiplication tables in flash, meant to run RACHEL without any GPU at all.
.
The second photo is the Mu next to the IOTA we already had.
.
Our competition season wraps up in December. After that we'll open the full GitHub repository and post the finished build here. Until then I'll keep sharing whatever we tidy up along the way.
.
If anyone wants to get in touch, our club email is mjurats.official@gmail.com and we're on Instagram at https://www.instagram.com/mjurats/
.
Thanks again to the LattePanda team.
Thank you for the kind words, and for asking about the part we care about most.
On where this would actually be used. Our target isn't large factories that run one fixed task for years. It's smaller manufacturers who own one robot arm and need it to switch between different jobs week to week. Reprogramming an arm for each new task normally means calling in someone who writes robot code. If an operator on the floor can just say what they want in plain language, that barrier drops. We're also looking at education, where students can see how an instruction becomes motion without learning a vendor-specific language first.
On preventing mistakes, this is the core of our design. Our position is that the language model should do as little as possible.
Most natural-language robot work lets the model generate coordinates or action commands directly. We don't. The model's only job is picking blocks, in the sense of Scratch blocks, where one block means one action like move, grip, or release. Coordinates, paths, reachability and collision checks are all ordinary computation. The model never touches them.
Before any block becomes a joint angle, three checks run. A block pointing at an object that doesn't exist is discarded. A position the arm cannot reach is filtered out by a reachability table. A path that would collide with something is flagged. Then the whole motion is replayed in a digital twin, so the operator sees the block list and the 3D motion together before the real arm moves.
What this guarantees is specific. Unregistered objects never execute, unreachable poses are never generated, and colliding paths surface before execution. One error does remain, which is the model choosing the wrong destination in the first place. That's a question of whether it picked the right block, and we measure it directly. On a 200-sentence validation set our 10MB model scored 98.5%.
One finding that surprised us. When we let the model handle the lookup between colors and positions, accuracy sat at 65.2% for color-referenced instructions. Moving that lookup out of the model and into plain computation raised it to 99.6%. The less we asked the model to do, the better a small model performed. That's been the guiding principle since.
RATS.MJU As students, you have conducted such in-depth research on the three aspects of artificial intelligence, embedded systems, and robots. You are truly remarkable. Furthermore, I would like to ask about Industrial Guai. Could you please tell me where his actual application scenarios will be in the future? How did you manage to prevent him from making mistakes? Could you share your design ideas or thoughts on this?
Jason.Miao 