This is the entry point for all work logs on the Prandium / OpenArm project. Each working day has its own log file, named by date (YYYY-MM-DD). This page lets you find anything in them in two ways:
- By day: see Days.
- By type of problem or topic (GPU, Docker, CAN, ROS controllers, mistakes to avoid, …): see Browse by topic.
Other useful starting points:
- Open issues: things that are broken or unresolved right now.
- Pitfalls and common mistakes: the short list of “don’t do this” lessons, collected from every day.
- Reference documents: the OpenArm guides these logs refer to.
- How these logs are organised: the conventions, if you’re adding to the logs or want to know what the tags mean.
Plugin used on this page: Dataview
The sections marked (auto) use the community plugin Dataview (Settings → Community plugins → Browse → “Dataview”), which builds lists automatically from the tags and properties in the day files. Without the plugin, those blocks show as plain code, but every section also has a hand-maintained list of links underneath, so the page is fully usable either way.
Days
| Date | Main topics | Status at end of day | Summary |
|---|---|---|---|
| 2026-10-10 | Joint tests on the real robot | 🟡 In progress | Testing every joint of both arms with a safety-checked helper script. |
| 2026-10-09 | Docs, Docker, sim tests, CAN, real-robot bring-up | 🟡 In progress (paused for the night) | Added Docker command explanations to the guide (V2.1); started ROS 2 setup testing; the NVIDIA GPU crashed after a charger change, fixed by a reboot; test steps 0–2 passed (sim bringup working); step 3 found that the trajectory controllers jump instead of moving smoothly; switched to splines and fixed (Guide V2.2). Evening: hardware stage up to the first slow real moves (zero fix, start-up patches, real-time container, direction map). Next: 2026-10-09 > 7. Next session. |
Browse by topic
Each topic lists the exact sections in the day logs where it comes up. Underneath each one, a Dataview block (auto) lists every day file carrying that tag, so new days show up even if the hand-maintained list hasn’t been updated yet.
🖥️ GPU / graphics / RViz display
#issue/gpu
- 2026-10-09 > 3. Issue: NVIDIA GPU crashed (Xid 154): NVIDIA driver crashed after a power-source change; fix is a reboot.
- 2026-10-09 > 5.1 Test step 1: GPU and display: how to check that RViz really runs on the NVIDIA card.
🐳 Docker and the container
#topic/docker
- 2026-10-09 > 1.1 What changed: what
docker run/start/execeach do. - 2026-10-09 > 2. Test step 0: environment check: container flags and workspace verified.
- 2026-10-09 > 4.2 Two Docker images exist:
:latestvs:built, not yet explained. - 2026-10-09 > 4.4 Container not created with real-time or CAN-admin flags: needed later for hardware.
- 2026-10-09 > 5.6 H4: new container with real-time permissions: why real-time matters, why Docker blocks it by default, how the new container was made.
🦾 Robot motion and controllers
#issue/ros
- 2026-10-09 > 5.3 Trajectory controller snaps instead of moving smoothly (issue): goals jump instead of moving smoothly.
🔌 CAN bus and hardware
#topic/can · #topic/hardware
- 2026-10-09 > 4.1 The CAN adapters are PEAK, not CANable/gs_usb: the guide’s CAN setup may need adjusting.
- 2026-10-09 > 5.4 Hardware stage: plan, and H1 host checks: adapter confirmed (PCAN-USB Pro FD), hardware-stage plan.
- 2026-10-09 > 5.5 H0 answers, and what really moves the robot (findings): what
discover/monitorreally do; the ROS start-up move.
🧪 Testing progress
#log/testing
- 2026-10-09 > 2. Test step 0: environment check: step 0 done.
- 2026-10-09 > 5.1 Test step 1: GPU and display: step 1 done.
- 2026-10-09 > 5.2 Test step 2: simulation bringup: step 2 done.
- 2026-10-09 > 5.3 Trajectory controller snaps instead of moving smoothly (issue): step 3 part 1 done; found the interpolation issue.
- 2026-10-09 > 5.4 Hardware stage: plan, and H1 host checks: hardware stage, H1 done.
- 2026-10-09 > 5.7 H5: first ROS launch on the real robot (left arm only): first real launch (left arm, right on
vcan1). Left arm turned out to be unpowered. - 2026-10-09 > 5.8 H5 (for real): both arms powered, both patches: real start-up of both arms, slow ramp verified; joints stop ~0.01–0.02 rad short (friction vs PD).
- 2026-10-09 > 5.9 H6: first commanded moves, and the joint direction map: which way ”+” moves each joint, per arm; the real joint limits.
- 2026-10-09 > 5. Test plan and where we stopped: the full test plan, with checkboxes.
📝 Documentation changes
#log/documentation
- 2026-10-09 > 1. Documentation changes: Guide V2.1, versioning convention.
- 2026-10-09 > 1.4 Obsidian link conversion (all versions, in place): all guides now use Obsidian links, and
§references are clickable. - 2026-10-09 > 5.3 Trajectory controller snaps instead of moving smoothly (issue): Guide V2.2 corrects the interpolation claim and the §12.1 CAN mapping.
⚙️ ROS 2 control and launching
#topic/ros2-control
- 2026-10-09 > 5.2 Test step 2: simulation bringup: sim bringup checks; what the 5 controllers are and where control runs.
- 2026-10-09 > 5.3 Trajectory controller snaps instead of moving smoothly (issue):
interpolation_method: nonemakes goals jump; switching tosplines.
🔎 Follow-ups (noticed, not yet acted on)
#log/follow-up
Open issues
Hand-maintained. When an issue is solved, move it to Resolved issues with a link to the day it was fixed.
| Issue | First seen | Blocks | Next action |
|---|---|---|---|
ROS start-up drives the arms to 0 in 2 s at full stiffness, with a kick (OpenArmHW::return_to_zero) | 2026-10-09 | Hardware stage | Option B chosen: apply and build the patch (openarm_patches/0001-…); verify the zero (H3); clamp the base |
openarm-can-cli monitor enables the motors (Guide §10.5 says they’re disabled) | 2026-10-09 | Hardware stage | Hold the arm on the first monitor; correct Guide §10.5 |
| CAN guide assumes gs_usb, but adapters are PEAK | 2026-10-09 | Hardware stage only | §22 already covers PEAK naming; check §10.4 bit-rate options for PEAK |
Resolved issues
| Issue | First seen | Fixed | How |
|---|---|---|---|
| Container lacks real-time flags | 2026-10-09 | 2026-10-09 | docker commit → openarm-jazzy:rt, new container with SYS_NICE/rtprio/memlock; FIFO priority 50 confirmed |
| Right arm joint 5 motor zero off by 1.394 rad (≈80°) | 2026-10-09 | 2026-10-09 | set_zero --no-arm --id 5 on can1; ≈0.00 after a power cycle |
Trajectory controllers jump to targets (interpolation_method: none) | 2026-10-09 | 2026-10-09 | Config switched to splines; smooth motion confirmed in sim |
| NVIDIA GPU in error state (Xid 154) | 2026-10-09 | 2026-10-09 | Reboot with the charger left plugged in |
Pitfalls and common mistakes
The short, cumulative “don’t do this” list. Each entry links to the day where the full story is told.
| Pitfall | What to do instead | Source |
|---|---|---|
| Plugging/unplugging the charger while the NVIDIA GPU is in use can crash the driver until a reboot. | Plug the charger in before starting and leave it. | 2026-10-09 |
Using docker run to “get back into” the container creates a new, empty container. | docker start openarm, then docker exec -it openarm bash. | 2026-10-09 |
Trusting a long time_from_start to make a move slow. With interpolation_method: none the joint waits, then jumps at full speed. | Check ros2 param get /<controller> interpolation_method is splines before commanding real motors. | 2026-10-09 |
openarm-can-cli set_zero without --id re-zeroes all 8 motors on that bus. | Always --no-arm --id N for a single motor. | 2026-10-09 |
| Powering an arm while ROS is already running: the motors stay disabled while ROS believes it controls them. | Power the arms first, then launch. | 2026-10-09 |
| Trusting a start-up check that reads positions without confirming the motors replied (an unanswered motor reads 0.0). | Patch 0002: every motor must report enabled, no error. | 2026-10-09 |
ros2 launch … | tee file: Ctrl+C kills tee first, hiding (and possibly cutting short) the shutdown. | | tee -i file. | 2026-10-09 |
| Using the joint-limit table in Guide §3 for hand-written goals: it’s wrong for left joint1 and both joint2s (per-arm offsets and mirroring). | Use the per-arm table in the log. | 2026-10-09 |
Pressing Ctrl+C several times on ros2 launch escalates to killing it; the motor driver’s shutdown (torque off) may never run. | Ctrl+C once, wait for the shutdown messages. | 2026-10-09 |
| Starting a second launch while one is already running gives two controller managers that conflict. | Check ps inside the container first; only ros2cli.daemon may be there. | 2026-10-09 |
| Editing a guide file in place loses the version that others may be reading. | Save as the next minor version (V2 → V2.1). | 2026-10-09 |
Reference documents
- OpenArm_ROS2_and_teleop_Guide_V2.2: current ROS 2 + LeRobot guide (interpolation and CAN-mapping corrections).
- OpenArm_ROS2_and_teleop_Guide_V2.1: previous version (says interpolation
none“ramps”: wrong). - OpenArm_ROS2_and_teleop_Guide_V2: previous version (no Docker command explanations).
- OpenArm_ROS2_and_teleop_Guide_V1: first version.
How these logs are organised
Files
- One file per working day in this
Logsfolder, namedYYYY-MM-DD.md, so they sort chronologically. - This page,
Log Index.md, is the only non-dated file. Every day file links back here at the top.
Structure of a day file
- Properties (the block at the very top, which Obsidian shows as a table):
date,topics,status(ok/blocked/in-progress) and tags. Dataview reads these. - A summary callout with the key outcomes of the day.
- Numbered sections, one per piece of work or issue. Each issue section follows the same pattern: Symptom → Why it matters → Diagnosis → Fix → Prevention → Status.
- A Lessons and pitfalls section at the end, whose entries are also copied into Pitfalls and common mistakes.
Tags
| Tag | Meaning |
|---|---|
#log/daily | Marks a file as a day log (used by Dataview to build Days). |
#log/testing | Test steps and results. |
#log/documentation | Changes to the guides or other documents. |
#log/follow-up | Something noticed that needs doing later. |
#issue/<area> | A problem in a given area, e.g. #issue/gpu, #issue/can, #issue/ros. |
#topic/<area> | A topic discussed without necessarily being a problem, e.g. #topic/docker, #topic/ros2-control. |
#status/open | An issue that isn’t resolved yet. Removed (or changed to #status/resolved) when fixed. |
#pitfall | A lesson or mistake worth remembering. |
Callouts used
Summary: key outcomes of a day.
Warning or pitfall: something that went wrong or easily could.
Fix: the solution to an issue.
Tip: a useful shortcut or clarification.
Rule or convention that we agreed on.