docs(plans): BEAST-01 platform rebuild — tear it down, keep a short list, build it back - #247
docs(plans): BEAST-01 platform rebuild — tear it down, keep a short list, build it back#247Coldaine wants to merge 4 commits into
Conversation
GitHub Actions
Error
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR |
codeant-ai
Bot
added
the
size:L
PR Summary by Qododocs(plans): Define clean-room BEAST-01 platform rebuild plan
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Qodo FixerNo findings are available for this PR yet. Findings appear here once Qodo has reviewed the PR. |
There was a problem hiding this comment.
Pull request overview
Adds a new governing work-order plan under docs/plans/ describing a clean-room rebuild of the BEAST-01 ROS 2 workspace to eliminate accumulated drift (scripts, undeclared enablement, and unmanaged vendor code) by rebuilding from an explicit preserve list.
Changes:
- Add a new plan document: BEAST-01 platform rebuild (clean-room rebuild phases A–E, preserve list, watch-outs).
- Register the new plan in
docs/plans/README.mdas a live work order with a summary and gating note.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| docs/plans/README.md | Adds the new rebuild plan to the live work-orders table. |
| docs/plans/2026-08-15-beast-platform-rebuild.md | Introduces the full rebuild plan (rationale, preserve list, phases, and verified watch-outs). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| | Plan | What it covers | Blocking? | | ||
| | --- | --- | --- | | ||
| | [BEAST-01 platform rebuild](2026-08-15-beast-platform-rebuild.md) | **Governing plan — clean-room rebuild, not a migration.** The repo is not the authority on the robot and nothing reports when it is wrong: enablement and 17 machine facts exist only on one NVMe, and 7 mechanisms were observed reporting success while failing. `robot/beast/ros2_ws` (51,361 lines, 13 scripts, 17 units) is **deleted**; the preserve list is one package (`beast_power`) plus extracted knowledge. Phases: extract → build clean offline → prove twice → cut over and delete. Retires the strip-down and vendored-surface plans, whose subject ceases to exist. | Not blocking. Phase A gates everything: nothing may enter the new tree that is not on the preserve list | |
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
|
|
||
| | Plan | What it covers | Blocking? | | ||
| | --- | --- | --- | | ||
| | [BEAST-01 platform rebuild](2026-08-15-beast-platform-rebuild.md) | **Governing plan — clean-room rebuild, not a migration.** The repo is not the authority on the robot and nothing reports when it is wrong: enablement and 17 machine facts exist only on one NVMe, and 7 mechanisms were observed reporting success while failing. `robot/beast/ros2_ws` (51,361 lines, 13 scripts, 17 units) is **deleted**; the preserve list is one package (`beast_power`) plus extracted knowledge. Phases: extract → build clean offline → prove twice → cut over and delete. Retires the strip-down and vendored-surface plans, whose subject ceases to exist. | Not blocking. Phase A gates everything: nothing may enter the new tree that is not on the preserve list | |
There was a problem hiding this comment.
WARNING: Present tense "is deleted" misleadingly implies the vendored workspace is already gone; description also contradicts lines 16–17
robot/beast/ros2_ws still exists — this plan will delete it in Phase D, but "is deleted" reads as current state. The description also claims this plan "Retires the strip-down and vendored-surface plans," yet lines 16–17 of this same README still list those plans as live work. Use future tense ("will be deleted") and resolve the contradiction by marking the retired plans as superseded or removing them.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| 4. **Hardware paths** — ESP32 at `/dev/serial/by-id/usb-1a86_USB_Single_Serial_5B5E130201-if00` | ||
| (**not** `/dev/ttyTHS1`, which docs claimed for weeks), LiDAR by-id, INA219 on `i2c-7`, udev | ||
| `03e7` for the OAK-D, groups `dialout i2c video render docker`. | ||
| 5. **Pack limits** — 8.332 V measured hard trip, ~9.6 V operational floor, 0.14 Ω internal |
There was a problem hiding this comment.
WARNING: Pack limit value does not match recorded DB measurement
AGENTS.md / ins-beast-pack-cutoff-measured records 8.368 V as the measured hard cutoff, with ~9.6 V as the operational floor. This plan states 8.332 V and says "Never re-derive these," but the value differs from the recorded measurement by 36 mV. For a hardware safety threshold that gates operational decisions, accuracy matters — reconcile against the DB before treating it as authoritative.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
|
||
| Delete this plan (executed plans are deleted, not archived). Update `docs/beast-ops.md` Quick | ||
| connect, `docs/deploy.md`, and `README.md`. Retire the strip-down and vendored-surface plans, | ||
| whose subject no longer exists. |
There was a problem hiding this comment.
WARNING: "no longer exists" describes a future state in present tense
Phase E runs after the rebuild completes. The vendored workspace still exists until Phase D deletes it. "No longer exists" implies it is already gone; use future tense ("will no longer exist") to match the plan's sequence and avoid suggesting the workspace has already been removed.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
Additional Note
Fix these issues in Kilo Cloud Previous Review Summary (commit 41bbe8f)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 41bbe8f)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
Additional Note
Reviewed by step-3.7-flash · Input: 267.2K · Output: 118.9K · Cached: 4.3M |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41bbe8feb7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - `beast_hardware` — **new code**: a `ros2_control` `SystemInterface` speaking the T-code | ||
| protocol (parse inbound `T:1001` at 20 Hz → joint states; emit `T:13` on write). This is the | ||
| riskiest item in the plan; see below. |
There was a problem hiding this comment.
When Phase B replaces beast_base, the specified beast_hardware behavior only parses T:1001 and emits T:13; it omits the unconditional startup zero and the latched /ugv/set_allow_motion gate currently implemented in beast_base/base_node.py. Those behaviors are load-bearing because the ESP32 retains its last velocity, mux-source expiry emits no zero, and the browser's DISARM action depends on that service. Since C1 only requires the replacement to drive, this plan can pass its gates while allowing a pre-restart command to remain latched and removing remote disarm. Add both safety behaviors and their acceptance tests to the preserve contract.
Useful? React with 👍 / 👎.
| - `beast.repos` — pinned upstream manifest (slam_toolbox, nav2, ldlidar, rf2o, | ||
| robot_localization, depthai, twist_mux, joy, teleop_twist_joy). Several already come from apt. | ||
| - `beast_power` — the one carried package. | ||
| - `beast_hardware` — **new code**: a `ros2_control` `SystemInterface` speaking the T-code | ||
| protocol (parse inbound `T:1001` at 20 Hz → joint states; emit `T:13` on write). This is the |
There was a problem hiding this comment.
Phase B's exhaustive new-tree list has no robot-description/URDF artifact, even though Phase D deletes ugv_description. The current bringup loads that package to publish the base_footprint/base_link, LiDAR, camera, and wheel transforms, and a ros2_control SystemInterface also needs its joints and hardware declaration. The listed drivers, Nav2 parameters, and beast_hardware therefore cannot form a valid TF/controller graph after deletion, so C1 cannot reach SLAM or navigation. Add a deliberately rebuilt BEAST description and validate the required TF tree and controller interfaces before cutover.
Useful? React with 👍 / 👎.
| **`ugv_cockpit` (800) needs an owner decision, not a default.** It is the Hangar bridge, and the | ||
| Hangar app is a separately deployed surface. Either it moves to the app side or it is rebuilt as | ||
| a thin `rosbridge` config. It should not survive by inertia into a robot workspace. |
There was a problem hiding this comment.
This records an unresolved owner decision but never makes its resolution a phase gate or done condition; Phase A forbids copying unnamed code, while Phase D deletes ugv_cockpit with the rest of the workspace. The current Hangar browser and server clients both depend on this package's loopback rosbridge, topic allowlists, and motion service, so the plan can pass C1 by driving locally and still take the product's telemetry and controls offline. Require a deployed, end-to-end-verified replacement before deletion rather than leaving the bridge outside the execution contract.
AGENTS.md reference: AGENTS.md:L60-L68
Useful? React with 👍 / 👎.
| Switch the robot to the new tree. Then delete `robot/beast/ros2_ws` entirely — 51,361 lines, 13 | ||
| scripts, 17 units — in a single commit. **Deleted, not migrated, not parked.** Git history is the | ||
| archive; that is what `docs/plans/README.md` already says about plans and it applies here. |
There was a problem hiding this comment.
Phase D explicitly deletes the whole vendored workspace, including the never-launched packages named earlier in the plan. That conflicts with the repository's required treatment for vendor packages we do not run: retain them with COLCON_IGNORE and remove them from both build allowlists. Following this work order would therefore produce an unacceptable cleanup even if the replacement stack worked; restructure the cutover so those packages remain parked.
AGENTS.md reference: AGENTS.md:L78-L82
Useful? React with 👍 / 👎.
| 2. **ESP32 T-code protocol** — `T:13` drive, `T:131` startup enable (unverified), `T:132` LED, | ||
| `T:133` pan-tilt, `T:137`, `T:3` OLED, `T:900` model, inbound `T:1001` at 20 Hz. The input to | ||
| the `ros2_control` hardware interface. |
There was a problem hiding this comment.
The preserved protocol knowledge reduces inbound T:1001 to its type and frequency, but the current frame is also fanned out by beast_base as imu/data and odom/odom_raw, which feed the wheel odometry and EKF configuration that this plan deletes. Phase B only says to turn the frame into joint states and does not specify the remaining fields, conversions, covariances, or equivalent ROS outputs. The rebuilt robot can therefore pass the C1 driving check while silently losing wheel/IMU localization inputs and producing unusable maps or poses. Preserve the complete feedback contract and test the resulting odometry and IMU topics.
Useful? React with 👍 / 👎.
| **C2 — declaration completeness.** Run `provision.sh` somewhere that does *not* already have | ||
| everything: a container on the Jetson from the JetPack base image, or a fresh flash. Every | ||
| missing apt package, pip install and env assumption surfaces here, loudly. Note the limit | ||
| honestly: a container will **not** catch udev rules or group memberships, so those need a fresh | ||
| flash or explicit inspection. |
There was a problem hiding this comment.
When C2 uses the explicitly permitted JetPack container instead of a fresh flash, it cannot exercise host systemd installation, unit enablement, boot ordering, udev, groups, Tailscale, or the cold-boot clock behavior. C1 does not cover those either because its differently named units remain disabled on an already provisioned robot. The plan can thus declare C1/C2 complete without ever testing the primary failure mode it identifies—reconstructing the boot-enabled machine state from Git—and a fresh Orin may still fail the top-level done condition. Require provisioning and rebooting a fresh host, or an equivalent host-level image test, before Phase D.
Useful? React with 👍 / 👎.
| 4. The workspace builds from a pinned upstream manifest plus `beast_power`. | ||
| 5. `robot/beast/ros2_ws` is **deleted** — not parked, not ignored, deleted. | ||
| 6. `deploy/bin` no longer exists as a concept: no supervisor scripts, no verify script, no | ||
| privilege wrapper. If any survives, it carries a written reason a standard mechanism could |
There was a problem hiding this comment.
The current gated workflow advances refs/deploy/beast-01 for beast-pull.timer, but this plan deletes that pull agent and every other deploy script while Phase B provides only initial provisioning. No replacement consumes later approved commits, rebuilds the workspace, restarts it, or reports rollback state. After Phase D, the pin workflow can remain green while BEAST-01 stays on old code, immediately recreating the repository-versus-robot drift diagnosed by this plan. Add and verify a standard ongoing deployment mechanism before removing the existing consumer.
AGENTS.md reference: AGENTS.md:L65-L72
Useful? React with 👍 / 👎.
| 4. **Hardware paths** — ESP32 at `/dev/serial/by-id/usb-1a86_USB_Single_Serial_5B5E130201-if00` | ||
| (**not** `/dev/ttyTHS1`, which docs claimed for weeks), LiDAR by-id, INA219 on `i2c-7`, udev | ||
| `03e7` for the OAK-D, groups `dialout i2c video render docker`. |
There was a problem hiding this comment.
The preserve list records only “LiDAR by-id,” omitting the actual device path, model, fixed-bin count, direction/crop settings, and calibrated blind-band values currently carried by ugv.env.example and the launch configuration that Phase D deletes. C1 can still pass by inheriting the current robot's existing /etc/beast/ugv.env, while C2 cannot exercise the sensor, so a fresh host can start with the wrong device/default scan geometry or include chassis self-returns. Phase A should retrieve and identify the complete current LiDAR record in Hangar, then make those values and a scan-geometry check explicit rebuild inputs.
AGENTS.md reference: AGENTS.md:L5-L17
Useful? React with 👍 / 👎.
| 2. **ESP32 T-code protocol** — `T:13` drive, `T:131` startup enable (unverified), `T:132` LED, | ||
| `T:133` pan-tilt, `T:137`, `T:3` OLED, `T:900` model, inbound `T:1001` at 20 Hz. The input to | ||
| the `ros2_control` hardware interface. |
There was a problem hiding this comment.
Although the knowledge list names T:132, T:133, T:3, and T:900, it does not preserve their payload schemas, ROS topic/service contracts, or any Phase B implementation beyond the drive-only beast_hardware interface. Deleting beast_base therefore removes the LED controls, pan-tilt commands, OLED updates, and model-selection startup command, while C1's drive-only gate and the done conditions still pass. Specify replacement interfaces and end-to-end checks for these user-visible controls, or explicitly scope their removal through the product rather than silently dropping them.
AGENTS.md reference: AGENTS.md:L60-L63
Useful? React with 👍 / 👎.
| ### B — Build the new tree, clean, offline | ||
|
|
||
| New workspace root. Empty. Every file typed on purpose: | ||
|
|
||
| - `beast.repos` — pinned upstream manifest (slam_toolbox, nav2, ldlidar, rf2o, |
There was a problem hiding this comment.
Phase B says only “New workspace root” while Phase D deletes the repository's sole named robot workspace. The new systemd ExecStart paths, sparse checkout, provisioning, deployment, and operator documentation all require one stable repo-relative location; without it, an executing agent must invent a path and could even place the replacement beneath the directory Phase D removes. Name the destination explicitly and carry that path through every install and close-out deliverable.
AGENTS.md reference: AGENTS.md:L65-L68
Useful? React with 👍 / 👎.
…eview (#248) Co-authored-by: AI Assistant <ai@example.com>
Thirty-five days of deploy tooling has been treating symptoms. This is the
design pass the 2026-07-11 Pi->Orin port implied and nobody did.
Diagnosis, and it is not code volume: the repo is not the authority on the
robot, and no mechanism reports when it is wrong.
* Nothing declares what runs. beast-install-systemd-units copies all 17
units and never enables them; which 9 start at boot exists only as
symlinks on one NVMe.
* Nothing declares what the machine is. 17 facts live only on that disk,
including the one-line udev rule the OAK-D cannot open without.
* Mechanisms report success when they fail. Seven observed firing this
week, tiered honestly against two read-in-code and one from a prior
session.
Traced the history through git rather than assuming it: Waveshare 037dfca
shipped zero deploy/ and zero systemd files. Day one of our ownership
(2026-07-11) was a hardware port, and 3777a09 "Add disabled Jetson base
service" is the seed of the whole layer. The port silently transferred the
environment, the supervision, and the deploy to us; each was improvised on
the day it first drew blood.
Phases order recording before change: capture, declare enablement, declare
the machine, workspace from a manifest, supervision on nodes, ros2_control
last (it is the only phase writing new code against firmware we do not own).
Anti-goals are load-bearing here. No big-bang rewrite; the robot drove
autonomously on 2026-08-15. No vanity deletion -- the ~28,000 SLOC of
never-launched vendor packages are inert and removing them fixes nothing.
No config-management framework for one robot. No script #17.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The phase ordering was justified with "one dead NVMe away from being gone", which reads as a prediction that the disk is about to fail. There is no evidence of that -- no SMART warning, nothing. Single point of failure is a structural observation, not a forecast. The real justification needs no drama: the recording phases are cheap and cannot break anything, so there is no reason to sequence them later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The diagnosis said "1,870 lines of bash is the price of the missing human"
and then the plan retired none of it. A diagnosis wearing a plan's clothes.
Adds a per-script table: what it is, why it exists, and which phase kills it.
beast-mission dies at P5 (diff_drive_controller supplies the timeout it fakes).
beast-gamepad and install-operator-shortcuts die outright (joy and
teleop_twist_joy are upstream). The Wi-Fi trio leaves the repo entirely -- it
is UniFi forensics and lives here only because the symptom appeared here.
beast-install-systemd-units and install-beast-sudoers are absorbed into
provision.sh. beast-verify, beast-ctl and beast-pull shrink hard.
1,870 lines -> ~300-400. 17 units -> ~8. Survivor sizes are marked as
estimates, because they are.
Also fixes two things the first draft got wrong:
* "Do not delete beast-pull" contradicted the whole thesis. It is now
re-evaluated at P5, not preserved.
* The anti-goals read as brakes on culling. They now explicitly constrain
HOW the cull happens, not how much, and the inert-vendor-package point is
restated so it cannot be quoted as a reason to cull less.
Done condition gains a sixth item -- the only one that is a number rather
than a property.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous version was six migration phases, and it was wrong for the same
reason the robot is in this state: subtraction from a bad shape cannot reach
a good shape. Every migration phase has to reason about the existing system,
so the old structure constrains every step -- which is precisely how 1,870
lines of shell got built, thirteen locally-correct steps at a time.
The concrete tell: that draft wrote provision.sh by recording the current
robot, then validated it with --check against that same robot. It would have
passed trivially and enshrined every undeclared accident as a declaration.
Inverts the default. The new tree starts empty; nothing is carried by
inertia. The preserve list is the whole plan:
* Code: beast_power alone -- 1,168 of 51,361 lines. INA219, load-compensated
SoC, datasheet-vector tests, no upstream equivalent for this hardware.
* Knowledge: nav2 tuning rationale, the ESP32 T-code table, the twist_mux
ladder, hardware by-id paths, measured pack limits, the traps.
* ugv_cockpit is flagged for an owner decision, not defaulted -- it is the
Hangar bridge and the Hangar is a separate surface.
* Everything else is deleted, named explicitly so nobody has to guess.
Phases: extract -> build clean offline -> prove twice -> cut over and delete
robot/beast/ros2_ws in one commit.
C is deliberately two tests, because one cannot prove both things. C1 on the
current robot proves the stack works and CANNOT prove the declaration is
complete -- that machine already has everything. C2 runs provision.sh
somewhere that does not, and the limit is stated honestly: a container will
not catch udev rules or group memberships.
Risk profile is not worse than the migration -- the new tree is built offline
while the robot keeps running the old stack, and nothing is deleted before
its replacement runs on hardware. Only the end state differs: designed
rather than eroded.
New anti-goal, and it is the load-bearing one: the preserve list does not
grow during execution. "We found we still needed it" is the exact mechanism
that built the current system.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
41bbe8f to
2800165
Compare
GitHub Actions
Error
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2800165cfd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - `params/` — nav2, twist_mux, slam_toolbox, carrying the preserved tuning with rationale in | ||
| comments. `use_sim_time` explicitly `false`, in the params file, not a launch argument. |
There was a problem hiding this comment.
In the checked Phase B/D flow, the replacement carries SLAM parameters but deletes the only mechanism that serializes the live posegraph and occupancy grid: beast-slam.service invokes deploy/bin/beast-slam-save on stop, including the size guard and backup that prevent a bad live map from overwriting the last usable copy. Since C1 only has to drive, the plan can pass its gates and then discard every mapping session at shutdown, leaving no map for saved-map navigation. Add the save/resume/backup contract and an end-to-end persistence test to Phase B/C.
Useful? React with 👍 / 👎.
|
|
||
| - `beast.repos` — pinned upstream manifest (slam_toolbox, nav2, ldlidar, rf2o, | ||
| robot_localization, depthai, twist_mux, joy, teleop_twist_joy). Several already come from apt. | ||
| - `beast_power` — the one carried package. |
There was a problem hiding this comment.
On a fresh Orin, carrying beast_power alone does not preserve its advertised durable CSV logger: PowerLogger writes /data/beast/power/power-log.csv, while the current deploy/storage/install.sh is what creates /data and gives beast a writable subtree. Phase D deletes that installer, and C1 runs on the already-prepared robot, so the logger can pass unnoticed there but fail with PermissionError when DurableCsvWriter.__init__ tries to create the path on a clean host. Make the directory ownership, logger unit ordering, and a real write check explicit provisioning requirements.
Useful? React with 👍 / 👎.
| 1. A fresh Orin, flashed and given this repo, reaches a verified-running BEAST-01 with **no | ||
| undocumented step**. | ||
| 2. `git` states which units are enabled; changing that set is a reviewed diff, not an SSH session. | ||
| 3. A ROS node dying makes its systemd unit fail. `systemctl is-active` is admissible evidence. |
There was a problem hiding this comment.
For the direct-node design, systemctl is-active is not sufficient evidence for Nav2: the checked ugv_nav/launch/nav_bringup/navigation_launch.py explicitly manages controller, planner, behavior, smoother, navigator, and waypoint nodes through ROS lifecycle transitions, and a configuration or activation failure can leave those processes alive while inactive. C1 only requires driving, so the plan can declare supervision fixed while navigation remains unusable behind green systemd units. Require all expected lifecycle nodes to reach active and make lifecycle-manager/configuration failure fail the relevant unit.
Useful? React with 👍 / 👎.
| **C1 — functional.** Bring the new tree up on the current robot at a different workspace path, | ||
| with differently-named units, nothing enabled. Proves the stack works. **Cannot prove the |
There was a problem hiding this comment.
During C1, differently named systemd units do not isolate the replacement from the running old ROS graph: both stacks still target the same ESP32 serial device and command topics, so leaving beast-ros-base active can produce competing T-code readers/writers and make observed motion impossible to attribute to the new stack. The plan never requires stopping the old serial/controller owner before this test, despite otherwise promising that the old stack remains available until cutover. Add an explicit stop-and-verify-exclusive-ownership procedure with a bounded rollback before permitting any C1 motion.
Useful? React with 👍 / 👎.
| 1. **Nav2 tuning rationale** — RotationShim wrapping RegulatedPurePursuit, `allow_reversing: | ||
| false`, `use_rotate_to_heading: true`, effective speed cap living in the velocity smoother | ||
| (`[0.26, 0.0, 1.0]`) not RPP's `desired_linear_vel`. That shape is deliberate for a robot with | ||
| a 104° blind wedge astern. Regenerating defaults silently loses it. |
There was a problem hiding this comment.
The preserve entry names the controller wrapper, reversing behavior, and speed cap, but omits the active collision-monitor contract in ugv_nav/params/rpp.yaml: the cmd_vel_smoothed → cmd_vel_nav chain, stop/slow polygons, scan source, and stale-source timing. Under Phase A's rule that unnamed behavior cannot enter the new tree, Phase B can regenerate Nav2 parameters without this final obstacle stop layer, while C1 still passes because it only checks that the robot drives. Preserve the exact collision-monitor wiring and envelope and require obstacle plus stale-scan stop tests before cutover.
Useful? React with 👍 / 👎.
User description
Re-opened for review after reverting #242.
Summary
Proposes a clean-room rebuild of the BEAST-01 robot platform (
obot/beast/ros2_ws) to eliminate accumulated bash scripts, undeclared systemd unit enablement, and unmanaged vendor code.
CodeAnt-AI Description
Define a clean-room rebuild plan that makes the repository authoritative for BEAST-01
What Changed
beast_powerpackage and explicitly documented hardware, tuning, protocol, and operational knowledgeImpact
✅ Reproducible BEAST-01 setup from a fresh Orin✅ Fewer silent deployment and startup failures✅ Safer platform rebuild with hardware validation before deletion💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.