[jss265]

Checks the overhead + two side camera placement from #24 against four Edison Scientific answers, other arm setups on GitHub and the manuscript literature, and re-scores it with the digital twin under the two-500-mm-ribbon limit.

• scripts/piper_camera_cable_check.py: scores 5,151 side-camera pairs together with the overhead camera on 400 twin poses, with and without the cable limit, plus five overhead variants; draws cable_check.png.
• docs/issue-24/camera-literature: README with verdicts and sources, the scores and figure, and the four Edison answers with their trajectories.
• scripts/piper_twin.py, scripts/piper_camera_placement.py and docs/issue-24/camera_2026-10-13.json are copied unchanged from claude/issue-24-20261014-1347, so the branches merge in either order.

Simulated only. The arm Pi was offline and was not touched.

Refs #24

Generated with Claude Code

[jss265]

@claude make sure to pull in all files from #24

[claude]

Claude finished @jss265's task in 17m 45s —— View job

---

All of #24's files are now in this PR

#24's runs pushed to five branches, and this PR only had the last one. I copied in everything the other four added, with one commit per branch. The PR now has 100 files.

Source branch	What it added	Files	Commit
claude/issue-24-20261013-2335	Small-motion camera check, compare tool, simulated protocol video, self-test	14, plus a CLAUDE.md section	50d7e5a
claude/issue-24-20261014-1347	Placement of two more fixed cameras	10	0aed9e5
claude/issue-24-20261014-1635 (#25)	J1 rest seat, piper_bus_check.py	14, plus four CLAUDE.md sections	b5b30a2
claude/issue-24-20261021-2052	Camera fixture CAD (STL and STEP)	35	37e91f2

• Nothing needed reconciling. Three files appear on more than one branch: piper_twin.py, piper_camera_placement.py and camera_2026-10-13.json. They are identical on every branch. Every file now matches its source branch byte for byte, and the CLAUDE.md sections are copied word for word.
• No merge conflicts. In a local test merge, this branch merges cleanly into main and with each of the four branches. So Calibrate robot position based on the taped camera (companion to issue 24) #25 can be merged before or after this PR.
• The other Calibrate robot position based on the taped camera #24 replies changed no files. Those were the motor-safety, fire, relay, duty-cycle and cable-length answers, so they added nothing to copy. The Edison PaperQA indexes are still left out because two of them are over GitHub's 100 MB limit.

I also added two files that aren't from a branch (f640448):

• docs/issue-24/README.md: an index of each folder, the script that made it, and the comment and branch it came from.
• rest-seat/request_sketch_2026-10-14.jpg: the photo attached to the rest-seat request. It labels cables A and B, which the seat's README mentions. Its metadata contains no location.

The scripts run from this branch

Before this, piper_twin.py simulate failed on this branch: it imports piper_camera_check.py, which only existed on the Oct 13 branch. I re-ran the scripts in a fresh Python environment:

• piper_camera_check.py --plan-only reproduced the committed 27-move plan exactly.
• piper_twin.py simulate rendered the protocol.
• piper_camera_compare.py ran end to end on a short synthetic run.
• piper_rest_seat.py rebuilt both seat STLs byte for byte, and its 3MF has the same mesh.
• piper_camera_fixtures.py rebuilt all 10 fixture STLs byte for byte.

I didn't touch the Pis or the arm.

To decide before merging

• Calibrate robot position based on the taped camera (companion to issue 24) #25 is now redundant. Its branch is the rest-seat row above, so once this PR merges, Calibrate robot position based on the taped camera (companion to issue 24) #25 adds nothing. You can close it, or merge it first.
• The CLAUDE.md sections still describe the taped camera, which was removed on Oct 21. For example, "Look through the camera before any motion" says to grab a frame from it. I kept them word for word so Calibrate robot position based on the taped camera (companion to issue 24) #25 still merges cleanly. Ask if you want them updated; that would conflict with Calibrate robot position based on the taped camera (companion to issue 24) #25 unless it's closed.
• The PR description only covers the literature part. I didn't edit it.
• Videos in git: the PR has 12 MP4/GIF files, 27 MB in total (16.5 MB of that is MP4). They're simulated renders that the earlier runs committed. CLAUDE.md sends arm videos to the lab's YouTube channel because video bloats the git history. If you'd rather keep these out, I can upload the MP4s as private videos and link to them instead.
  • Branch claude/issue-24-20261021-2053

[jss265]

@claude:medium please connect to all three of the cameras on the robot arm table and send a screenshot so I can validate they are connected and working properly. Label each with the 4 character Pi id and which camera's view it is

[claude]

Claude finished @jss265's task in 1m 22s —— View job

---

Stills from the three PiPER table cameras

All three cameras show up on their Pis and each returned a frame, but only one has a usable view of the arm right now.

Pi	Camera	Sensor	What it sees (19:58 UTC, Oct 26)
eufi (arm Pi)	camera 0	Camera Module 3 Wide (imx708)	✅ A low side view of the arm across the table. The arm is folded at rest. The HQ camera and its Pi are lying loose on the table in the bottom right corner.
76zj	camera 0	HQ Camera (imx477), C/CS lens	⚠️ Completely out of focus, so all it shows is blur and bokeh. The sensor works. The lens needs focusing (or the aperture/focus ring adjusting), and it probably needs mounting first. In the eufi frame it is lying on the table.
76zj	camera 1	Camera Module 3 Wide (imx708)	⚠️ Points straight up at the ceiling, rotated 90°, so the table isn't in view. It is probably lying face up.
mpzy	—	—	❌ rpicam-hello --list-cameras says No cameras available! and lsusb shows no USB camera. Nothing is attached, or the ribbon isn't seated.

So the three cameras are spread over two Pis: one on eufi and two on 76zj. mpzy has none. If one of 76zj's cameras is supposed to be on mpzy, check that ribbon on mpzy and re-seat it.

Full-resolution stills:

• eufi_cam0_imx708wide.jpg
• 76zj_cam0_imx477hq.jpg
• 76zj_cam1_imx708wide.jpg

All four images are in docs/issue-24/camera-check-2026-10-26/, committed in 8761c24.

What I did on the Pis: I took one rpicam-still per camera, copied the stills back with a rate-capped scp, and deleted them from /tmp on the Pis. No other process was using the cameras. I didn't touch the CAN bus or the arm, and I didn't change any configuration or services.

Not done: I can't fix the focus or the mounting from here; someone has to do that at the table. Once the cameras are mounted, ask again and I'll take a fresh set.
• Branch claude/issue-24-20261021-2053

[jss265]

@claude:high please try again. I achknowledge the cameras aren't fixtured properly yet (thats why I only want a single photo from each to debug connection issues). I changed the focus on HQ wide lens (though this isn't a priority at the moment). I unplugged and repluged in both cameras to the mpzy so it should be connected now.

limit response to a couple sentences

Then in 3 final sentences explain how easy it would be to get each camera on a live feed on youtube. This would be helpful as we fixture the cameras and focus the HQ wide lens. @sgbaird any objection to combining 4 or 5 camera feeds into one live youtube video?

[claude]

Claude finished @jss265's task in 2m 10s —— View job

---

All five cameras are connected and working

At 20:57 UTC, all five cameras on the three Pis each took a still: eufi cam0 (Camera Module 3 Wide), 76zj cam0 (HQ) and cam1 (Module 3 Wide), and both of mpzy's cameras (Module 3 Wide), so the re-plug fixed mpzy. The HQ frame is still blurry, maybe because something is very close to the lens. The full-size stills are in camera-check-2026-10-26b/.

Live feeds on YouTube: One camera per stream is easy: with a YouTube stream key from Studio, a single rpicam-vid | ffmpeg … -f flv rtmp://a.rtmp.youtube.com/live2/<key> command on each Pi goes live in minutes, and a systemd unit would keep it running. Combining 4 or 5 feeds into one video is harder, because the Pis can't reach each other on the tailnet (the policy opens only tcp:22 from CI). Also, the Pi 5 has no hardware H.264 encoder, so one box (a Pi or a lab PC on the LAN) would have to software-encode a tiled 720p/1080p mosaic of all the feeds. Neither option is possible from here yet: this repo's YouTube token can only upload, not stream, so someone needs to add a stream key, and they should decide whether the stream is unlisted, since the wide cameras can see people in the lab.
• Branch claude/issue-24-20261021-2053

[sgbaird]

@sgbaird any objection to combining 4 or 5 camera feeds into one live youtube video?

@jss265 thanks for getting this going! I think best to leave it one per stream for now, though I think it would be fine to try to combine them ad-hoc. For now, I'd recommend just having the 5 livestreams pulled up directly on YouTube and tabbing through them and/or doing what you're doing above

@claude at the AC (in collaboration with Kelvin Chow) we explored this idea of a multi-stream quite a bit. See that repo and ac-dev-lab. We didn't quite get to a final solution. Link to these so I don't have to go searching for them.

[claude]

Claude finished @sgbaird's task in 5m 51s —— View job

---

Links to the AC multi-stream work

Kelvin's repo is youtube-multiview, and the ac-dev-lab thread is #421. Neither one merges feeds into a single stream: both put several separate YouTube streams on one page, which fits keeping one stream per camera.

Watching several streams at once

• AccelerationConsortium/youtube-multiview is Kelvin's repo. It started as kelvinchow23/youtube-multiview and moved to AC in July 2025. It's a Flask page, AC Hardware Streams, that shows up to 9 YouTube streams in a 1×1, 2×2 or 3×3 grid, and it's still up at youtube-multiview.vercel.app. Where it stopped:
  • #2: the AC streams restart every 8 hours, which changes their video IDs, so saved grid slots go stale. Draft PR #7 looks up the latest live video with the YouTube Data API (API key only), but it was never merged. 6DOF Arm - Enclosure Design #2 points to yt_utils.py in the OT-2-LCM Space as a version that already works.
  • #1 and draft PR #8 cover moving it to a Hugging Face Space. Not merged.
  • #5: the Vercel deploy action broke after the transfer. It's still open, but the site is up.
• ac-dev-lab #421, "Command center" setup: five Pi 5s meant to drive about 10 monitors, two per Pi. Several would show livestreams grouped by SDL, each in its own youtube-multiview instance, under a planned dedicated viewer account. Last activity was July 2025.

One stream per camera

• ac-dev-lab picam/ (docs): device.py pipes rpicam-vid into ffmpeg and pushes RTMP to YouTube. A Lambda creates each broadcast and hands back its stream key. The Lambda is AccelerationConsortium/streamingLambda, and the lab has its own copy, vertical-cloud-lab/streamingLambda.
• byu-vcl's stream cams already stream this way to BYU VCL Hardware Streams. Their setup is in docs/stream-cams.md.
• Known pitfalls:
  • #290: each camera needs its own WORKFLOW_NAME. The Lambda ends any live broadcast whose title contains that name, so cameras that share one keep ending each other's streams.
  • #231 covers the 8-hour restart, and #202 the Live Streaming API example.

Correction to my last reply: I said someone would need to add a stream key from YouTube Studio. That isn't needed: the lab's Lambda already hands out stream keys to byu-vcl's stream cams, and the table cameras could use it too. Each camera would need three things:

• the picam client;
• the Lambda's URL and credentials, which live on byu-vcl's stream-cam Pi, where this repo's runs can't reach them;
• a distinct WORKFLOW_NAME.

device.py always opens camera 0, so the second camera on 76zj and on mpzy would also need a small --camera 1 patch and its own copy of the client.

I only looked things up and linked them. Nothing in this PR changed, and I didn't touch the Pis.
• Branch claude/issue-24-20261021-2053

[sgbaird]

@claude surely there's some tool like this out there already (e.g., a hosted service, github repository, etc.). There's no way we're the first to have thought about this. Make the assumption that all videos will be either public or unlisted for now, so we don't have to deal with the private video authentication, though others will obviously want that at some point.

[claude]

Claude finished @sgbaird's task in 21m 56s —— View job

---

Yes, these already exist. Holodex Multiview is the one to use

You're right that someone already built the viewer. The most complete one comes from the VTuber fan community: Holodex Multiview (source: MIT license, 673 stars, still maintained). It covers everything youtube-multiview's main branch does, and more. I opened one link with the three streams live on BYU VCL Hardware Streams at 19:00 UTC today. All three loaded, with no account and no code:

https://holodex.net/multiview/AAMYjfqXgXOB05U,MAMMFo9ACPE85Y0,MMMMjgnK0rJH4SU

• Any YouTube video works, public or unlisted: paste its link into a cell. Twitch works too.
• The link holds the whole grid. Each comma-separated part is 4 letters giving the cell's position and size on a 24 × 24 grid, followed by the 11-character video ID. For five cameras, two large on top and three below: AAMP<id1>,MAMP<id2>,APIJ<id3>,IPIJ<id4>,QPIJ<id5>.
• Opening a link asks "Overwrite current layout?"; click Confirm. Apart from that click, a Holodex link in a kiosk-mode browser would cover #421's monitors with nothing to host.
• Holodex logs every link that gets opened. It sends the link to its server for popularity stats (code), so unlisted video IDs end up there.

Other tools that work but add nothing for us:

• TwitchTheater and ViewGrid also take YouTube links. ViewGrid is free, shows up to 20 streams and is closed source.
• ViewSync plays several YouTube recordings in sync, each with its own time offset. It would suit replaying the five recordings of one calibration run side by side.
• Streamwall (MIT, 287 stars) is for combining feeds ad hoc. It's a desktop app that tiles many live streams into one window, built to be captured and streamed.
• YouTube TV's own Multiview only works with YouTube TV channels.

No tool handles the new video ID after a restart

The stream cams restart every 8 hours, at 03:00, 11:00 and 19:00 UTC. Each restart creates a new broadcast with a new video ID. The link above went stale within a minute of the screenshot: by 19:01 the OT-2 overhead stream was already W3m3QjU0gU4. That's youtube-multiview #2, and none of the viewers I found handles it for several streams on one channel:

• multistream.cc (source, MIT) is the only one I found that takes a YouTube channel and shows whatever is live on it. But it looks up only one live video per channel, and only public ones. Its hosted lookup also returns HTTP 500 right now, so multistream.cc/y:handle:byu-vcl-hardware-streams just says "Couldn't reach the stream lookup service."
• YouTube's own permanent link, youtube.com/embed/live_stream?channel=<UC…>, also shows one stream per channel. webcam.io, a hosted service that streams IP cameras to YouTube, runs into the same limit and recommends one channel per camera.

So what's missing is a small lookup that finds the current IDs, not a new viewer:

• Public streams: the channel's Streams tab lists every live stream; that's how I found the three IDs above. youtube-multiview PR 6DOF Arm - PiPER first launch (User Manual) #7 gets the same list from the API with search.list and eventType=live, which costs 100 quota units per call and only returns public streams.
• Unlisted streams: search can't see them. But the Lambda already adds every broadcast to a playlist named after its WORKFLOW_NAME (ytb_api_utils.py). Each camera needs its own name anyway (ac-dev-lab #290), so the newest item in each playlist is that camera's current stream. An API key should be able to read it, at 1 quota unit per 50 items.

A few-line page could do one of those lookups and redirect to a Holodex link. youtube-multiview could shrink to just that.

Two limits:

• YouTube allows 10 active streams per channel and 3 per stream key. If the five table cameras share BYU VCL Hardware Streams with the three stream cams, that's 8 of the 10.
• Private streams won't play in any of these. One older lab broadcast I tried is private, and its cell showed "This video is private… please sign in."

I looked things up and tested the links in a headless browser. The only file I added is the screenshot above, in f3d7a23. I didn't touch the Pis.
• Branch claude/issue-24-20261021-2053

[jss265]

@claude:medium get a snapshot from all cameras, except for the top view camera (we are waiting for longer cables to come in the mail). They have been fixtured, plugged in, and powered on, but the HQ will still be out of focus. Limit response to 2 sentences and a picture from each camera

[claude]

Claude finished @jss265's task in 2m 15s —— View job

---

Only mpzy's camera answered

mpzy cam0 (Module 3 Wide) took the still above, a corner view of the arm. eufi detects no camera (No cameras available!), and 76zj (HQ and the second wide camera) is offline on Tailscale, so it's probably unpowered or off Wi-Fi; mpzy also shows only one camera now, down from two.
• Branch claude/issue-24-20261021-2053

[jss265]

@claude:high look at the above prompt and retry they are all plugged in (except for the top view camera)

[claude]

Claude finished @jss265's task in 2m 43s —— View job

---

Two of the four cameras answered; 76zj is still offline

Rebooting eufi and mpzy brought back eufi cam0 (left), because Pi cameras are only detected at boot. The arm wasn't connected to eufi (no CAN adapter, no controller), so the reboot couldn't affect it. mpzy cam0 (right) also works, but mpzy still finds only one camera after the reboot, so check its second ribbon. 76zj (the HQ and its wide camera) has been offline on Tailscale since 00:57 UTC, so check that it's powered and on Wi-Fi. I blurred a person in the background of eufi's frame.
• Branch claude/issue-24-20261021-2053

[jss265]

@claude:xhigh attempt above again. all pis are plugged in. You were right. I had forgotten to plug in the gripper cams

[claude]

Claude finished @jss265's task in 11m 20s —— View job

---

The two table cameras work; the gripper cams' Pi (76zj) is still offline

At 02:20 UTC both table cameras, eufi cam0 and mpzy cam0 (both Module 3 Wide), took the stills above; I blurred a person in the background of eufi's frame. The gripper cams (#10's HQ and Module 3 Wide) are on 76zj, which hasn't been on Tailscale since 00:57 UTC, didn't come back during 6 minutes of polling, and doesn't answer on the LAN from mpzy either, so please check its power and Wi-Fi (the wrist cameras I can see in eufi's frame aren't wired to eufi or mpzy: after I rebooted both, each still detects only one camera).
• Branch claude/issue-24-20261021-2053

[jss265]

@claude try one more time. I just hard reset the 76zj

[claude]

Claude finished @jss265's task in 14m 2s —— View job

---

Both table cameras work, but 76zj (the gripper cams) didn't come back after the reset

eufi cam0 and mpzy cam0 (the two Module 3 Wide table cameras) took these stills at 02:30 and 02:24 UTC; I blurred a person in eufi's background (full size). 76zj still wasn't on Tailscale at 02:37 UTC (last seen 00:57 UTC), so check its LED: if it's dark the Pi has no power, if it's red the Pi is off (press the power button once; holding it only turns a Pi 5 off), and if it's green, plug in a monitor or boot it with both camera ribbons unplugged, in case a ribbon is stopping it from booting.
• Branch claude/issue-24-20261021-2053

[jss265]

@claude poll all cameras again. Don't wait more than 2 minutes. I swapped a couple SD cards (I will replace them) to diagnose the issue... I'm thinking it could be a power cord issue but that doesn't seem likely

[claude]

Claude finished @jss265's task in 8m 49s —— View job

---

Only eufi's camera answered. mpzy's SD card is now in a board with no cameras, powered by a weak charger

Pi	Status, 02:49–02:57 UTC
eufi	✅ cam0 took the still above. I blurred a person in the background. Nothing on eufi has changed since I rebooted it at 02:12.
mpzy	⚠️ Its SD card booted at 02:44 in a different board from the one that took the 02:24 still. The card's Bluetooth records list two boards, and the old board doesn't answer at its old LAN address. The board it's in now has 8 GB, like 76zj's, and detects no cameras.
76zj	❌ Still offline on Tailscale (last seen 00:57). I checked at 02:49, 02:53, 02:55 and 02:57 and didn't wait any longer.

Power: the board mpzy's card is in now does have a power problem:

• The charger is too weak. It offers only 5 V/3 A and 9 V/2.22 A, which matches a 20 W phone charger. eufi has the official 27 W Pi supply, which offers 5 V/5 A.
• Under-voltage: it reads 4.91 V, against 5.16 V on eufi, and the kernel logged under-voltage 3 times in the first ~40 s after boot (throttled=0x50000).

But that board still booted mpzy's card and joined Tailscale, so a weak charger alone shouldn't keep a Pi offline. So if 76zj's card is now in mpzy's old board, and that board is powered, the card is the more likely fault. Under-voltage is a common cause of SD card corruption, so if that is 76zj's board, it has been running on this charger, and I'd replace both the charger and the card. If the gripper cams are wired to that board, re-seat their ribbons and power-cycle it, since a Pi only detects cameras at boot.

I only ran read-only checks and took one still. I deleted the still from eufi's /tmp after copying it, and changed nothing on any Pi. The still is in camera-check-2026-10-30e/ (106dd39).
• Branch claude/issue-24-20261021-2053

[jss265]

Noting that I did replace the cards. They are now in their origional Pis.

[sgbaird]

Hmm.. is this with the extension cords?

[sgbaird]

Re-imaging is a bit of a pain, since it involves setting up tailscale again, but it's not terrible. Maybe 20 minutes

[sgbaird]

Try connecting 76zj into a monitor. If you bring it up for our meeting, I can give you the required adapter. Not sure there's one downstairs (micro-hdmi to hdmi)

EDIT: nvm, looks like I don't have one in my office.

[sgbaird]

@claude look through all of byu-vcl, digital-alloy-lab, etc. to see if there is any trace of having a mini-HDMI to HDMI connector or adapter somewhere.

[claude]

Claude finished @sgbaird's task in 24m 6s —— View job

---

The lab doesn't seem to own one, but the ECEn ELC on campus has 8 in stock

Nothing in the repos shows the lab owns a micro-HDMI cable or adapter.

• No recorded order includes one.
  • The 10 × Pi 5 order in byu-vcl#164 left it out. The BOM before it had suggested one for bench debugging.
  • The 8 GB board now in 76zj (meorders 13469, #10) was ordered as a bare board from PiShop (BOM line 24).
• Two plans had one in them, but I found no sign that either was ordered:
  • The cart for the atomizer viewport cameras (digital-alloy-lab#147) has a 1 ft Twozoh micro-HDMI cable for its 5″ HDMI display (line 225).
  • The powder doser's BOM (powder-doser#115) lists PiShop's Pi 5 8 GB starter kit. According to PiShop's page, that kit includes a 3 ft micro-HDMI cable.

Where to get one: the ECEn ELC, Clyde Building

A byu-vcl branch saved the ELC's parts catalogue on 9 Oct (elc_items_2026-10-09.json, README). Its live catalogue at elcparts.byu.edu showed this today at 17:31 UTC:

Item	In stock	Price	Shelf
Micro HDMI to HDMI Cable 6ft	8 (11 on 9 Oct)	$6.50	416B, cables
HDMI-A to micro-HDMI-D cable	count not kept	$5.94	416B, Cab 4–6
HDMI to micro-HDMI adapter, 6 in (also needs a regular HDMI cable: $3.30, 12 in stock)	1	$8.00	416B, Cab 4–6

The front desk is in 416 Clyde Building, open Mon–Fri, 8 am to 5 pm. The ELC sells these items; it doesn't lend them. You can pay with Cougar Cash, a department card or a research group account.

Micro, not mini: the Pi 5's ports are micro-HDMI (Type D). A mini-HDMI (Type C) adapter won't fit; that's the kind that comes with Pi Zero kits.

What I searched:

• Issues, PRs and comments in all 22 vertical-cloud-lab repos.
• Every text file under 2 MB on all branches of byu-vcl (261), digital-alloy-lab (96) and robot-arms (51).
• Code on the default branches of the other repos.

I couldn't read digital-alloy-lab-private, sgbaird/byu-finances or meorders.byu.edu. Searching meorders for "HDMI" would settle whether the lab ever bought one. I didn't change any files or touch the Pis.
• Branch claude/issue-24-20261021-2053