Software Completion

The chair finally drives reliably, and I can actually sit in it and move around now.The biggest challenge throughout the software was communication between the three Brains. I built a serial protocol that handles the startup handshake, LEFT/RIGHT assignment, health packets, retries, sequence/session validation, malformed frames, and local command timeouts. Early versions would still lose the link even when bytes were clearly being transmitted. This came from a combination of partial frames, serial self-echo, startup timing, and motor queries taking long enough to delay communication. I fixed these issues by improving the framing and recovery system, adding direction tags, limiting how much serial data can be processed in one loop, safely retrying packets, and prioritizing communication before slower motor checks.Motor initialization also caused problems because all of the V5 motors do not necessarily become available at exactly the same time after startup. Earlier versions would sometimes report motor disconnects or H-Bridge faults during startup. The drivetrain Brains now wait for every motor to begin returning valid health information before considering initialization complete. I also flipped the motor directions for the top and bottom of the drivetrain where needed.The controls were completed during this process. The broken throttle potentiometer was replaced with the Rotation Sensor on port 17. It now supports CENTER calibration and provides signed forward/reverse input. I corrected the steering direction and tuned the steering feedback. Controller mode now supports forward, reverse, normal turning, and turning in place.The safety system was also simplified into clear startup, parked, armed, and fault states. E-STOP is always available and is intentionally not recoverable without restarting the system. The drivetrain brakes use COAST.I moved the displays out of the main control path so rendering cannot interfere with serial communication. The master and drivetrain displays now provide live motor temperatures, faults, battery status, link state, steering/throttle positions, and communication diagnostics.I also updated VEXide and Rust during development.

Current Issue

I encountered one intermittent power issue during testing. The master Brain does not have its own battery and is powered through the Smart Cable connections from the two drivetrain Brains. During several tests, the master entered a white-screen state while one drivetrain Brain went completely black. The drivetrain side that shut off was not always the same.At the time, both drivetrain batteries were fairly low and were also at different charge levels, roughly 30–50%. I completely shut down the system, replaced both batteries, and restarted all three Brains. The issue stopped occurring after that, and the chair completed additional driving tests normally.My current theory is that the two independently powered drivetrain Brains may be interacting electrically through the master because the Smart Cable connections also carry power. Different battery voltages, or voltage sag while the motors were under load, may have caused a brief power transient. I have not confirmed this yet, so I am leaving the wiring unchanged while I collect more evidence.If the issue happens again, I may restructure the system so one drivetrain Brain also acts as the master, which would remove one Brain from the power-sharing arrangement. Another option would be changing how power is carried between the Brains while still keeping wired communication.

Hardware Completion

I finished the hardware on the chair. I added the bottom 2 drivetrain cortexes and connected everything to the master with smart cables. I added the batteries for them too. I figured out that the master cortex doesn’t need it’s own battery as it can be powered through the smart cables on p19-20 which connect to the drivetrain nodes. The batteries are shared across the whole system (3 cortex -> 2 lower bats powering wheels and controls + health checks). I added a small potentiometer and a gear to act as a speed controller but I have not determined exactly how I want to do that yet. I zip-tied all cables and such and tested that each one works and powers the device it connects to. All systems seem to be good in that regard.

Added some bad off-center racing stripes lol and also fixed the sag on the steering wheel by adding an additional support screw. I also dusted and cleaned it because it was SO DIRTY from literally nothing.

I temporarily moved it to my house so I can debug and program it at home. Bringing it back Sunday.

TODO: Software & QA + Validation

Master node will turn on first and wait for a connection from the two DT nodes. Then the DT nodes will recieve commands for voltages and will send back temperature and health records to ensure nothing breaks. If it gets too hot or too much tourque, it will initiate an emergency stop to ensure the saftey of the driver. Controls are TBD but it will also support a vex controller to drive it remotely. If a motor disconnects it will also shut down.

I’m so excited this project is becoming real!!

Lots of engineering went into this build, but I finally got a few new things working.

3D scanning:

• LiDAR depth is now filtered and fused with the AR mesh for cleaner, more accurate surfaces.
• Meshes now weld seams, remove bad geometry, preserve corners, and repair small holes.
• Blurry or fast-moving frames are rejected for sharper textures.
• AprilTags are “lock”able now and after a few positions viewed + ray casts on the mesh they cannot move.

UI changes:

• The scanner now shows mapped surfaces, live depth points, coverage, range, tracking quality, and tag-lock progress.
• Photos and 3D scans are now both “Areas”.
• The 3D viewer looks nicer and has highlighting + better camera controls now.
• Photo areas can rerun AprilTag detection without being deleted and recreated.

AprilTag Metal backend: I looked at some NVIDIA shaders and the C++ code and built a Metal backend for AprilTag detection. This runs on the GPU and gets a way higher fps for me. This reduces lag when scanning around as well as 3D scanning (makes the position more accurate to the mesh). Concurrency is also possible. Fallback to CPU.

Improve construction of chair and make it support ~160lbs of load(tested with the largest kid in my class). I am going to continue work on this. TODO: add more bar supports until I eventually reach the top. The wheels of the actual chair now float in the air which means it is fully supported by the base.

I also switched the side the bars are on with the front half of the chair, they are held from the rear facing end now. This leaves plenty of room in the front for an eventual foot support, it also increases stability.

Armrests were reinstalled again onto the new bar which goes across the front AND BACK. I ditched the middle-connectors and moved it to the back. This shifted where the center of mass could be which gives more opportunities for a rider stick their legs out.
I personally rode around in it (not powered) by pushing the floor with my feet. This caused only the motors to spin. At this stage, enough rider weight will cause the chair to sag. To resolve this I am going to simply make the 4 pillars stronger on the cross-section by adding more horizontal bars.

Overall difficulties when building this: the fact that the chair itself has weight and i couldn’t screw in or change stuff without having something holding it up… I chose to support it by 4 vex motors at a point. Screwing in at weird angles through multiple bars was pretty hard but I managed it (slowly).

Overall TODO: MORE METAL everywhere. After this, I will add the cortexes and the steering wheel. This version is due for me by september 8th by lunch, we are going to use the chair to promote our robotics club at my high school at our club day fair (best decorated club table wins money for us)

I plan on working more after school today. This log incorporates ~2 days of solid working hours.

okay so omoggle/mogwars was cool but this is cooler:

i noticed that those “backends” only ran on a static frame of your face and only measured landmarks. I decided to make one which bases it off of a 3D scan as well as texture information to estimate skincare.

After some research, I found 3DDFA, a small model which can reconstruct a 3D model of a face from photos.

the app first takes 7 poses by asking you to move your camera and then passes them all into the model. (120x120x3b tensor). The model gives 62 parameters per pose, and then the app takes the median identity-shape parameters across all views -> BFM2009 decoder -> 68 points used to calculate all the structural metrics.

then it uses the texture of the face that’s not in the eyes or mouth and samples them for clarity, eveness, texture, exposure, sharpness, etc. takes the median of that and then calculates a skin value. exact weights for them are found in the code.

improved UI. app performance, added accurate privacy policy, 3d scanning fixed and it actually works now except it’s rly laggy but the meshes don’t look ahh anymore.

Mogged

sorry for the lackluster devlog quality, my >4k char devlog was js deleted and i’m pissed

inspo

a very chopped aquantience couldn’t believe how chopped he was and I wanted to prove it to him. however, he didn’t want to go into an omoggle match w me so I needed something that supported image upload

motivation

popular websites that do an omoggle-style ranking either are not accurate to omoggle or send your photo off-device to a vLLM or server, which I don’t want

criteria

• both image and photo support
• privacy first all local on-device scoring
• accurate to the two popular mogging platforms I found, mogwars and omoggle

research

• found an excellent (althrough made by ai) writeup on omoggle. This shows that Omoggle uses Google’s Mediapipe FaceLandmarker. I knew the data fed into an algorithim but I didn’t know how the facial data was turned into a score
• so I got a codex agent to analyze the bundled JS of omoggle and mogwars to reverse-engineer the scoring mechanism. It came back with the following:
  • that both websites use the same metrics but process them differently into a score
  • the way metrics (symmetry, jawline, etc.) are calculated from the landmarks
  • and how each platform uses them

for sake of brevity (character limit) I will not be describing exactly how each platform works nor how the metrics are calculated in specific, for those interested, check out src/lib/scoring. I promise I’m not larping, I actually understand how it works lol.

implementation

I then took all of that as well as some Google-given examples for the landmarking API and created a new NextJS + Shadcn + Tailwind v4 project. I first wrote the landmarking system and then the scoring system based on the output of the landmarker. After, I made a temporary UI with google stitch and got codex to wire everything together.

demo

available at https://mogged.eli.best

It works. I attached the drivetrain fully and then (not tracked oops) programmed a very simple mock control program and put it all on one brain (not final design). I no longer have access to my school as my job ended, I’ll finish this project when I come back to school in early August. I plan on (1) fixing the height of the drivetrain so it actually presses into the floor enough to drive smoothly, (2) reinstalling wheel and programming it for self driving, (3) final tweaks for stability

It works. I attached the drivetrain fully and then (not tracked oops) programmed a very simple mock control program and put it all on one brain (not final design). I no longer have access to my school as my job ended, I’ll finish this project when I come back to school in early August. I plan on (1) fixing the height of the drivetrain so it actually presses into the floor enough to drive smoothly, (2) reinstalling wheel and programming it for self driving, (3) final tweaks for stability

I got the drivetrain basically done

kinda dumb but I built the drivetrain and now I realize the gear is bigger than the wheel so it won’t move oops

Working on drivetrain now I also programmed the rest of the chair with a few safety settings so nobody gets hurt!

Tracking works better now, I also added support for tag groups. Example: high strength gears are their own tag now instead of needing to place EVERY HS gear tag on a box

Re-added steering wheel with much stronger support bars and a shallower angle with a lower placement that makes it easier to see over and more comfortable to grip. I added the battery and a license plate to a new crossbar in the back.

I took off the steering wheel so I can fix the wobble later, I am keeping that module though but extending the bar on the seatbelt thing

improving model performance by adding new items to the dataset and recording new real data. I also worked on the 3D scanning feature on iOS and Ifixed the missing triangles error as well as got the raycast to work on the mesh instead of an AR plane which makes the positions of AprilTags 10000x better.

I switched this to a hardware project so I don’t have to use lapse anymore. I lost 4 hours today !! :|

Anyways, I added the steering wheel today. It holds (kinda) well and it will (should) not fall off.

Uses a Yoke design with a screen for HUD statistics like km/h and each node’s battery life, will program this later today. HUD will also be used for “ignition” and the unlock procedure. Considering using an SD card as a “key” for the “car”. The buttons on the wheel represent forward/reverse although I may want to make that it’s own gear shifter on the side and use both buttons as a forward (you have to click both, for saftey) I will also need to add the E-Stop somewhere.

Excited how real this project is becoming!!

Up next: 3D Printing a support bracket for the wheel bracket so that it doesn’t fall tf off anymore. (ribbed setup on the angled piece)

oh lord i forgot to make a devlog again…

anyways throughout this time and many timelapses I have fully programmed the steering wheel code, it has a full resistance turning wheel that is based on a motor + its encoder. it uses the angle to determine what direction to steer and the wheel speed to determine how much force it adjusts back to the center with like a real automobile

also I added a new bracket that mounts to the bottom of the chair with some drilled holes, this removes all wobble

moreover, I added the steering wheel / front brace / steatbelt bar that falls down over you so you can grab the wheel and not go flying out (see fig. 1)

room empty as week 1-2 kids no longer stay until 3rd and 4th period, however I now have much more time as my 4th period doesn’t exist anymore and I can grind for 2 hours minus my lunch time.

That’s all folks, more updates coming soon. Hopefully, I’ll try to remember to post them this time.

Started working on this old hunk of junk again.

Me and my very technically literate friends got this idea at the start of the year. When we first entered the PLTW lab for the first time, we saw the chairs had wheels. Like a lightbulb, it clicked in all of our minds that we wanted to make a go kart…

We didn’t work on it much, we snuck in during lunch freshman year but eventually the teacher in that room made us take it apart because we “were destroying school property” or whatever. To me, you just don’t like to have fun :(

However, I’ve recently restarted. My friend group has recently been employed at our school to teach robotics to smelly middle schoolers over the summer (dude I thought me saying 67 was bad, GET A LOAD OF THESE GUYS). Together, our schedule has 2 free periods (as well as lunch) out of our 4 period day to do whatever in the PLTW room. Since we self-moderate ourselves and have our own keycards, we truly have free will to mess around with anything and everything. Currently, there is at least one Xbox from home and 3 computers loaded with Roblox on the DAILY. Overall, it’s just really nice being with your friends at school without going to school…

Some of the middle schoolers like to stay in there during break/lunch to mess around with the parts, so I can’t lapse it during then. However, during my extra time, I am working on the chair or homework for my 4th period (pfft, I’d rather do the chair, its cool asf)

To begin with the actual devlog, the chair part of the chair is a Rio 2 4-Leg Armless chair from SitOnIt Seating. It has an angled bottom with 4 screw holes – perfect for mounting something.

Firstly, I dug up the old CAD files and trashed all of them starting from scratch. I took some measurements and 3D printed a new bracket for the bottom of the chair. Before, I just bent a piece of metal; but this time, i’d like to actually have something perfectly angled so it’s flat with the floor. I used Fusion 360 for all of my CAD work.

In CAD, I designed a left and right armrest as well as a bar + some ziptie locations to keep everything stable (note, none of this was tracked. Moreover, I did some quick planning with ChatGPT to find an optimal drivetrain configuration. We settled on 200RPM with a 72:48T gear ratio (72T on motor, 48T on wheel) with 4 motors per side of a differential drivetrain for a total of 8. Some quick numbers: 24.8 lbf push forse and 3.57 mph, reasonable for a small vehicle but not a death kart.

.. and then stardance started.. YUP! None of that work was tracked!! YIPEEE. Now, this is what I did in the 1h 28m:

Afterwards, I began work on the actual construction.

First I bolted on the bracket to the 3x C-Channel main bar. I then screwed it onto the chair and OOPS we need to drill some holes because my measurements were way off (screw you, old dial caliper.. or maybe I can’t read it idk).

I built the left and right armrest models in real life in the PLTW room at my school. (lapsed)

I then put them onto the bracket (lapsed)

.. and finally, I built the motor frame for the left half of the drivetrain.

That’s all folks, I hope (and am on track) to finish this in under a month, which is good because my summer school ends in 3 weeks..