> [HTML view](https://gyropup.com/site/pages/docs-requirements-md.html) · [Markdown index](https://gyropup.com/llms.txt). Generated from the same published content. Interactive controls and 3D scenes are available in the HTML view.

[← Design notebook](https://gyropup.com/site/)

BUILT BY AUTONOMOUS SYSTEMS · WORK IN PROGRESS

# Requirements

Each requirement in the user's own words, the feature that meets it, and how we check it. Statuses are updated as the work lands.

| # | The user said | Feature | Check | Status |
| --- | --- | --- | --- | --- |
| R1 | "design a robot for me like the diablo robot" | Self-balancing wheel-legged biped: two legs (hip + knee), a driven wheel at each foot | Mass, torque and balance budgets in the designer; simulation in MuJoCo, then Isaac Sim | open |
| R2 | "find the most available hub motors and actuators that are a bit chunky" | Catalog of buyable QDD leg actuators and hub motors, with seller, stock and date checked | `catalog/*.json` items carry `buy` links, `in_stock` and `price_checked` | open |
| R3 | "a choose your own adventure book web based guided design where I pick parts, you tell me pricing and such" | `designer/`: chapter-by-chapter guide; every choice shows price, mass and what it changes | Every option has a price and a source; the totals match the BOM | open |
| R4 | "make sure it can all be 3d printed but then swap out for parts made by sendcutsend metal brakcets, carbon fiber rods, whatever we need" | Every structural part has a printed version and, where useful, a SendCutSend / CF tube version with the same interfaces | Each part lists its fabrication options; sheet parts pass SendCutSend's design rules | open |
| R5 | "make a new private repo under valpatel with a cute name for a robot" | Private repo, renamed from `Valpatel/wobbit` to `Valpatel/gyropup` (R18) | `gh repo view` shows PRIVATE | open |
| R6 | "make the robot designer tool as important as the robot" | The designer is a first-class deliverable: tested model, catalog, docs | Model unit tests; the designer's output builds the CAD and the sim model | open |
| R7 | "Use our valpatel agent-cad and improve that agent-cad as we work" | Project runs on `cad-agent`; generic pieces (robot export, mass properties, BOM/cost, sheet-metal rules) go into cad-agent | cad-agent tests for each addition | open |
| R8 | "I want the robot simulated in Isaac-sim eventually for RL training" | URDF + meshes with CAD mass and inertia, actuator limits; USD via Isaac Sim's importer; Isaac Lab task later | URDF validity and inertia checks; MuJoCo load and balance test | open |
| R9 | "assume jetson orin agx 32GB with our new compute box" | The J501 compute box (206 × 181 × 112 mm, 12–36 V in) is the body payload | Mass and power budgets include it; the battery voltage suits it, or a DC-DC is in the BOM | open |
| R10 | "Ideally this is mostly 3d printed for low cost and we use a fancier bambu printer to make it a carbon fiber filled material later on. But start with PLA" / "(Bambu P1S to start)" | PLA on a P1S is the default for every printed part; a material ladder (PLA → PETG → CF-filled) rescales parts | Every part fits a 256 mm bed; stress and heat margins are computed for the chosen material | open |
| R11 | "Take notes from that new hugging face duck robot, cute and fun but works." | Character design (proportions, head/eyes, expressive motion) and the Open Duck Mini build and RL lessons | `research/reference-robots.md` has the lessons; the designer has a character chapter | open |
| R13 | "our main goal is to use the jetson orin agx because that's what we have, along with vlp-16 lidar, zed x or zed2i camera, intel realsense depth camera, just sticking with parts we have but list them as preferred compoennts" / "don't list owned parts as owned in the repo, just list their price and separate sensors/compute from chassis and actuators." | The AGX Orin J501 box, VLP-16, ZED X or ZED 2i and RealSense are the preferred defaults, listed at retail price. The BOM has separate **Sensors & compute** and **Chassis & actuators** sections with their own subtotals. A sensor head holds them | `catalog/sensors_compute.json` (`preferred: true`, no ownership field); mass and power budgets include the full sensor payload; the lidar has a clear 360° view | open |
| R14 | "Honestly the real goal should be closed loop - design a robot, evaluate it in sim, look at the stress points and how well it can drive around etc, iterate independently. Any components, any specs, choose your own adventure robot design + sim + manufacturing." | Closed loop: design (catalog or custom parts with any specs) → CAD + robot model → MuJoCo scenarios (balance, push, drive course, slope, curb, squat, hop) → sim loads → per-part FEA stress → manufacturing checks and cost → an optimizer or agent iterates without a human in the loop | `tools/evaluate.py design.json` writes one scored report; `tools/iterate.py` improves a design over many evaluations; the designer shows the sim and stress results | open |
| R15 | "Zed X is probably overkill because we don't need GMSL, not a large vehicle with lots of camreas." / "So honestly the intel realsense is probably the best for our size with vlp-16 lidar." | Default perception is a USB RealSense plus the VLP-16; no ZED and no GMSL board (the compute box uses the P4 front plate) | The default design has `stereo: null`, a USB RealSense and the VLP-16; ZED stays in the catalog as an alternative | open |
| R16 | "I have D415 and D435, a few of each" / "We can use one facing forward and one facing backwards, swap them out as needed? The VLP-16 has an IMU but I have some other options for IMU as well." | Front and rear depth-camera positions with one printed cradle (1/4-20) that fits both the D415 and D435; D435 is the default; a separate balance IMU rigidly on the body | `depth_front` and `depth_rear` slots; the cradle fits both camera envelopes; the IMU sits on the body, not the lidar mast | open |
| R17 | "VN-100 is a good IMU I have" / "Why a teensy 4.1? I don't have one of those but I have other microcontrollers with CAN I think. yes I have vn-100 in housing." | VN-100 Rugged (housed) is the default balance IMU, read over serial at up to 800 Hz. The balance controller is a set of requirements, not a fixed part: one of the user's own CAN microcontrollers, or a real-time loop on the Jetson | Default design uses `vectornav-vn-100-rugged`; it is mounted rigidly on the body near the centre of mass | open |
| R18 | "wobbit.com is already taken find a different name? OR we just use Valpatel Wobbit?" / "try another name?" | Renamed to **Gyropup** (gyro: it balances itself; pup: a small robot pet), chosen from a shortlist whose .com domains were unregistered on 2026-10-25 | Repo, folder, code and docs say Gyropup; gyropup.com still to be registered by the user | done |
| R19 | "We aren't making a duck, the duck was just a design reference for a new friendly robot. gyropup is a cool name" | Gyropup is its own friendly robot; Open Duck Mini is only a reference for charm and buildability. No duck features (beak, duck naming) in the design. The name stays | The designer and docs show no duck styling | done |
| R20 | "Also our board likely has CAN built in? For the AGX board but the microcontroler board is the main one for CAN" | The microcontroller owns the motor CAN bus; the J501's built-in CAN-FD (J25) links the Jetson to the microcontroller | Decision D9; the default design's controller requirements list both buses | done |
| R21 | "waveshare 0.71inch Double Eye Round LCD Display Module 160×160 Resolution 65K Colors IPS Display Supports Controller Boards Like ESP32 / Arduino, Embedded GC9D01 Driver <-- cool robot eyes" | Gyropup's eyes are the Waveshare DualEye module (two round 160×160 screens), driven by a small separate controller; the 3D model shows two round eye screens | Catalog item `waveshare-0-71-dualeye-lcd`; the default design and the eyes chapter use it | done |
| R22 | "To be clear you are making cad agent too robot specific it seems? It should be for any 3d model: housings, robots, whatever?" | cad-agent features are generic for any 3D model; robot features are optional modules; character UI (faces, eyes) lives here, not in cad-agent; generic features are tried on the J501 enclosure first | cad-agent's viewer and site run on j501-agx | open |
| R23 | "I would like to use LiFeP04 cells/battery pack if possible because they are safer to charge etc." | 8S LiFePO4 (29.2 V full keeps the J501 inside 36 V), high-discharge pack or custom high-rate cells with a 60–150 A BMS | The model knows LiFePO4 cut-off voltages; the battery check passes the motor current | open |
| R24 | "If LiFeP04 doesn't work that's OK too... I just like them." / "I would like the robot to be able to auto dock and charge that's where LiFeP04 is nice because of the sketchyness of LiPo" | Auto-docking and charging: the robot drives over a low dock, aligns on a fiducial with its rear camera, and crouches so a contact plate under the battery tray lands on spring contacts; the dock holds the charger. LiFePO4 preferred for unattended charging, Li-ion acceptable | A docking chapter in the designer; a dock design; a docking scenario in simulation | open |
| R25 | "Honestly the goal is for this to drive around outdoors and be able to shoot nerf darts with a turret on it's head, that's the whole dream with tritium : kids battling robots. (lidar could go under it's waist and just accept leg obstructions." | Gyropup is a Tritium robot: outdoor driving (grass, gravel, kerbs, slopes, weather), a foam-ball turret on the head (pan/tilt, flywheel launcher, hopper; R45), kid-safe by design; the lidar moves under the waist | Turret and outdoor chapters in the designer; recoil, terrain and slope scenarios in simulation; a safety requirements list enforced in design and software | open |
| R26 | "The robot mounted nerf gun with automated reload and firing is a clear separate session/lane with massive amounts of open source online resources to discover." | The turret is a separate project. Gyropup provides a head payload interface (mounting, power, data, mass and height budget, recoil limit) and simulates a payload of that size, including a recoil burst | `head_payload` in the design; recoil scenario; the interface documented in docs/head-payload.md | open |
| R27 | "Can you just make things up and keep going independently until we have a realistic design that fires darts in sim, has forward facing lights, and is awesome?" / "The turret needs to turn and aim, ideally with a green laser as well that is visible." / "(laser next to dart shooter)" | Labelled assumptions (D24); a target-practice scenario where the turret pans, tilts, walks its shots in and fires real foam-ball bodies with drag (dart bodies until R45); headlights as a part with spotlights in 3D; a green aiming laser beside the barrel with a visible beam and dot | `targets` scenario passes with 23/24 hits; headlights and laser show in the designer and simulator | open |
| R28 | "Honestly don't stop, keep going until we have manufacturable designs and the ability to train them in RL" / "We are ok with some limits, limits make things fun and reasonable to manufacture, like not aiming up.," / "(but with the legs the pup should be able to bend and look up a bit)" | CAD parts for every printed piece with printability checks and CAD masses; FEA on the legs from simulated loads; an RL training pipeline (mjlab) with an exported policy. Limits are welcome (never aiming up); the body can lean back on the legs to look up while the turret still never fires upward | `look` scenario; cad/ parts pass cad-agent checks; rl/ trains and exports ONNX | open |
| R29 | "The darts don't hit the target well they look cheesy" / "Also we need cool sfx" | Projectiles fly true and visibly hit (foam balls with a turning seam and a streak since R45; nose-first darts before); targets react (knock-down plates, hit bursts); synthesised sound for the launcher, hits, knock-downs, laser, servos and wheels | The `targets` scenario knocks all 5 plates down; the simulator plays the sounds (SOUND toggle) | done |
| R30 | "Also the gyropup is hidden behind the UI when blasting target practice, I need camera to show all of it." / "Right side hovering ui should be fully collapsable in the sim" | The replay camera frames the robot and every target inside the area the panels leave free, and follows the robot until you move the camera; the right panel collapses fully (HIDE PANEL, or the tab on its edge) | Screenshots with the panel open and collapsed show the whole robot and all targets | done |
| R31 | "Gyropup on one flexvolt 60v and replay target practice should be the sim default" | The default design is one FLEXVOLT in 60 V mode (D25); the simulator opens on the target-practice replay of it (`?run=none` for the live pose) | `designer/sim.html` with no parameters replays `default/targets` | done |
| R32 | "gyropup should talk like Moxie does as well and have word bubbles, Moxie has STT" | Speech bubbles over the head, a voice, listening (STT) and a kid-safe brain, from Moxie's stack with browser fallbacks (D27); reactions to hits and knock-downs | The talk dock in the simulator answers typed and spoken questions | open |
| R33 | "laser should be toggleable, toggle on when getting ready to fire, toggle off in-between targets and at stat." | Laser AUTO / ON / OFF; in AUTO it is off at the start and between targets, on while getting ready to fire, in physics and in the page (D26) | `laser_on`/`laser_off` events in the target run; the page follows them | done |
| R34 | "Can't we just make this thing a tricycle with 3 legs? Then it could recover and balance a lot easier, handle any crazy terrain? Or is that a waste?" | Compared in reasoning and in simulation: a tail gives most of a tripod's benefits (rest, safe stop, backward fall catch) at a fraction of the mass, without losing the balancing character (D28) | (Superseded: the tail was removed at the user's request, D30) | dropped |
| R35 | "Don't worry about cost can you just think about light weight, high quality with good tail motors but not driving wheels?" | Tail motors chosen for weight and quality, sized by simulation: RS-06 lift, RS-00 wag, carbon tube, TPU skid shoe (not driven), a fail-safe ratchet; CAD for the mount, yoke (aluminium), clamp and shoe | (Superseded: the tail was removed, D30) | dropped |
| R36 | "The beni robot is another good consumer exmaple product for inspiration, but we want this way heavier, more durable, more capable." | Beni in the reference robots; Gyropup keeps ~19 kg and aims for tougher parts (metal where loads peak, TPU bumpers), weather resistance, self-righting, hops and follow-me (D29) | research/reference-robots.md | open |
| R37 | "the tail is ridiculous please remove it" | No tail anywhere (D30); e-stop becomes a controlled crouch before the motors are cut; an uncontrolled power cut is the legs' fault case (D39: nothing may break, the knees are inspected after one) | No tail parts in the design, sim, views or CAD | done |
| R38 | "we need to start the real mechanical design ... the interface between motor and leg, knee motor interface, hip motor interface, keeping it flexible so we can swap motors and change our leg designs but have modular mating interfaces ... real cable routing, real motor attachment points. Real stiffness studies" | The GMI standard (docs/mechanical-interfaces.md); motor adapters from the vendors' drawings; cable routes checked over the leg's whole range; FEA of every load-bearing leg part under the simulator's worst loads (D31) | cad/gmi.py builds valid adapters for six motors; cad/cables.py passes; exports/fea/summary.json meets the targets | open |
| R39 | "You should be able to work on the nerf gun in parallel ... custom nerf guns ... drum magazine ... jamming ... motors ... highly compact turret, may make more sense to use water gel balls" / "gel blasters" / "foam balls instead of darts are also an alternative that is good for indoor, gel blaster is outdoor only." | A launcher study (research/turret-launcher-study.md): foam darts, foam balls (indoor) and gel blasters (outdoor), feed, jams, motors, safety, against the head payload interface | Done: the study recommends Rival-size foam balls from a hopper, with a swappable launcher cartridge; the user called it for balls (R45) | open |
| R40 | "To be clear we have an RTX4090, AGX thor, and GB10-01 + GB10-02 to use for this process also." / "iterate on the CAD all night with the best parts that are most available. Use the RTX4090 and the Thor" / "RTX4090 priority." / "The large model is the one you should kill...." | The design loop runs on the RTX 4090 (32 cores; its large and small LLM services and Whisper stopped by the user's choice; restart commands recorded); RL trains on its GPU; Thor needs this machine's SSH key first | exports/iterate/leaderboard.json fills overnight; the Results page shows it | open |
| R41 | "The mechanical modedl in the simulator doesn't make any sense anymore, you might need to use Fable 5.1 to check things and make our real CAD plan for the turret + robot?" | The simulator draws the real CAD per link, posed by the physics; an independent Fable 5.1 review and a staged CAD plan for robot and turret (docs/cad-plan.md) | research/mech-review-2026-10-25.md; S0 done (D32) | open |
| R42 | "To be clear I want to 3d print it" / "we have PA6-CF I believe" | Every made part printed; PA6-CF for structure (hardened nozzle), PETG otherwise; each part fits the 256 mm bed (exports/print-plan.json) | Strength targets met in printed allowables; print plan has no part too big | open |
| R43 | "For this kind of analysis I want to see simulations of it breaking etc animations showing the deformation and overload scenarios as part of our standard report." | Every strength case writes an overload video (load ramped past failure, overstressed region in black) shown in the report | exports/fea/\*.mp4 on the Progress page | done |
| R44 | "please keep a localhost website up to date withy your progress, designs, sim videos, and send me a link" | designer/progress.html: status, log, leg pictures, strength videos, sim videos, print plan, shopping list; live reload | [http://127.0.0.1:8642/designer/progress.html](http://127.0.0.1:8642/designer/progress.html) | open |
| R45 | "The robot ammo still looks like darts not balls." | The simulator fires what the CAD turret fires: Rival-size foam balls (22.7 mm, 1.83 g, 70 fps cap) from a 30-ball hopper. Ball bodies with drag in the physics, balls that spin, bounce and roll in 3D, ball sounds, the hopper count, and balls in Gyropup's lines (D34) | `targets` passes with ball bodies (all five plates down); no darts left in the simulator or Gyropup's lines | done |
| R46 | "The voice is odd, we need a new Piper voice." | Gyropup's own Piper sidecar (tools/tts\_server.py): en\_US-hfc\_female-medium lifted 2 semitones at a kid-friendly pace, cached; the talk dock names the voice; a gentler browser fallback (D35) | The talk dock reads `VOICE piper (hfc_female)` and plays the sidecar's WAV | done |
| R47 | "why do we need to send a vendor quote requests? We should use mostly off the shelf parts, 3d printed parts, and sendcutsend or similar parts?" | Every part is off the shelf with a listed price and a buy link, 3D printed, or a custom part ordered online at an instant price (SendCutSend, Xometry or JLCCNC, JLCPCB); nothing needs a quote (D40) | Every BOM line has a price and a buy link or is a printed part or an instant-quote drawing; `catalog/alternates.json` gives each bought part a second source | open |
| R12 | "Don't rush" | Research first, decisions with sources, verified outputs | Every number cites a source or is marked as an estimate | ongoing |

Created by [Valpatel Software LLC](https://valpatel.com/). © 2026. All rights reserved. Repository materials retain their stated licenses.