Differences

This shows you the differences between two versions of the page.

--- newsletters:2024-10 [2024/10/31 07:44] – [RFID localization] osnr
+++ newsletters:2024-10 [2024/10/31 10:04] (current) – [System improvements] osnr
@@ Line 1: / Line 1: @@
-====== October 2024 newsletter (WIP) ======
+====== October 2024 newsletter ======
 (Our next Folk open house is on **[[https://partiful.com/e/rKpJ32TqUZkNSLWrygyu|the evening of Wednesday, November 20]]**, at our studio in East Williamsburg, Brooklyn.)
@@ Line 17: / Line 17: @@
     * {{:newsletters:pasted:20241029-111557.jpeg?0x200px}} {{:newsletters:pasted:20241029-111712.jpeg?0x200px}} {{:newsletters:pasted:20241029-111740.jpeg?0x200px}}
     * Some issues with the recording, but here's the video:
-      * [[https://x.com/GopalKRaman/status/1844135235128262934|{{newsletters:fa648de6-d872-4299-af31-d4ae1f759f2f-3841-000001a4bc2b8e5f.png?300px}}]]
+      * [[https://x.com/GopalKRaman/status/1844135235128262934|{{newsletters:fa648de6-d872-4299-af31-d4ae1f759f2f-3841-000001a4bc2b8e5f.png?350px}}]]
   * Omar [[https://x.com/rsnous/status/1847321061261484107|talked about]] his background & the motivation and ideas behind Folk on [[https://podcasts.apple.com/us/podcast/the-orthogonal-bet-from-online-communities-to-in/id1615629580?i=1000670683552|the Lux Riskgaming podcast with Sam Arbesman]].
+    * [[https://x.com/rsnous/status/1847321061261484107|{{:newsletters:pasted:20241031-075205.png?350px}}]]
 ==== Applications and demos ====
@@ Line 34: / Line 35: @@
 {{:newsletters:pasted:20241030-221705.jpeg?0x300px}}
-==== System improvements ====
+==== Gadget/system improvements ====
-Andrés and Omar have been showing the gadget a lot lately, both at outside presentations and at open houses, so we've made a lot of small gadget-related fixes.
+Andrés and Omar have been showing the gadget a lot lately, both at outside presentations and at open houses, so Omar has made a lot of small gadget-related fixes.
-(these all apply to the system more generally -- so the gadget is paying off for the normal ceiling systems as well -- but have been particularly acute or frequent with the gadget, because it has more tags at the fringe, it moves more, it has less RAM, etc)
+These all come together to make the gadget feel much more like the computational flashlight we want it to be:
+{{youtube>SHHPDiTw8jo?}}
+(these improvements all apply to the system more generally -- so the gadget is paying off for the normal ceiling systems as well -- but have been particularly acute or frequent with the gadget, because it has more tags at the fringe, it moves more, it has less RAM, etc)
   * [[https://github.com/FolkComputer/folk/commit/e19372bccb796d7bd3827fe71ca660dec4a0665a|Fixed crash where number of Gauss-Newton iters gets really high]] when tag is near edge of camera space, which was causing segfault in those cases
-    * Omar: I guess that we were just blowing out the stack with tens of thousands of iterations (and associated stack-allocated matrices) when tags are too off-camera since it just may never converge in that case
+    * I guess that we were just blowing out the stack with tens of thousands of iterations (and associated stack-allocated matrices) when tags are too off-camera since it just may never converge in that case
     * (normally you can get pretty good in 10-20 iterations, in my experience, so we could maybe reduce this cap further)
   * evaluator: Did some heap profiling and [[https://github.com/FolkComputer/folk/commit/1d82d222e2f8e593b4e1ff18f6199f32134ede8d|fixed several memory leaks]]
@@ Line 51: / Line 57: @@
     * It still leaks, but way slower (the 2GB Pi 5 used to crash in 12 minutes or so, now //at least// 20-30 minutes uptime, could be much more). More to do here!
-=== camera-rpi improvements ===
+=== Gadget-specific improvements ===
 These apply only to the gadget camera (or to any other system that uses Pi cameras instead of USB webcams) -- they're improvements to the camera-rpi.folk driver:
@@ Line 63: / Line 69: @@
   * Noticed that the Pi wide-angle camera has focus control, unlike the normal camera module, and we hadn't set the focus, so it was at [[https://libcamera.org/api-html/namespacelibcamera_1_1controls.html#acfb623408035e51db904a0f3928a863e|the default of 2m away]], which is way too far; locked focus closer, to ~30cm away from the camera which seems like a good start and seems to help with recognition stability a bit
+== EDID fix ==
+The combination of the Pi 5, ribbon-type micro-HDMI to HDMI cable, and pico projector (Ultimems HD305D1-C1) seems to sometimes (maybe only at the Linux fbcon level? outside when Folk controls Vulkan) produce garbled output. I figured out this is because the EDID data doesn't get through properly to provide a reasonable default resolution?
+[[https://forums.raspberrypi.com/viewtopic.php?t=362124|Solution]]: [[https://github.com/FolkComputer/gadget/commit/20d0208a8f6cd8225db63bb6cfb9b176d5a50bc3#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R115|hard-code the EDID to 720p in /boot/firmware/cmdline.txt.]]
+== Vulkan fix ==
+Sometimes you only see llvmpipe (the not-useful software renderer) and not the actual Pi 5 GPU on ''vulkaninfo --summary''. I've found that this gets fixed by doing ''sudo rpi-update'' (brings back a good Pi kernel with good GPU support?)
 ==== Cat printer printing ====
@@ Line 101: / Line 116: @@
 Omar: I've been picking this up again in October because I want to get it to work.
-And I have good news: I fixed the bug that had me stuck in [[https://folk.computer/newsletters/2024-05#small-system-improvements|May]] and June, where the in-band reader would crash after the first round completed. It turned out that the problem was that I was using the ''%'' (mod) operator in the hot transmit loop (to decide the index of the sample to send out), millions of time per second, and that operator is actually pretty slow. I added another counter and if statement instead, and that works great:
+And I have good news: I fixed the bug that had me stuck in [[https://folk.computer/newsletters/2024-05#small-system-improvements|May]] and June, where the in-band reader would crash after the first round completed. It turned out that the problem was that I was using the ''%'' (mod) operator in the hot transmit loop (to decide the index of the sample to send out), millions of times per second, and that operator is actually pretty slow. I added another counter and if statement instead, and that works great:
 {{:newsletters:pasted:20241031-061559.png?500px}}
@@ Line 117: / Line 132: @@
 === Unreliability of IB reader ===
-one issue has been that reading the tags is finicky (sometimes you have to move it, or it doesn't work as well on my home system, etc) because the new fast decoder is so much less robust
+One issue has been that reading the tags is finicky (sometimes you have to move it, or it doesn't work as well on my home system, etc) because the new fast decoder is so much less robust. (maybe continuous reading instead of one-round will help with this once we get it?)
-(it's live & on a deadline, so it's just using a binary threshold on amplitude, and it only uses the first few samples to compute that threshold; the old decoder looked at the whole stream and tried to decode it in the optimal way).
+(the reader is live & on a deadline now, so it's just using a binary threshold on amplitude, and it only uses the first few samples to compute that threshold; the old decoder looked at the whole stream and tried to decode it in the optimal way).
 How to threshold something like this? So much stuff that's in the middle even on visual inspection.
 {{:newsletters:pasted:20241029-182100.png?500px}}
+You often get read failures when the tag responses are sketchy like that right now.
 ==== Friends and outreach ====
@@ Line 146: / Line 163: @@
 ==== Some demo lessons ====
-Hard-won experience from what things we needed (& what things broke down) at mobile demos over the last couple of months:
+Hard-won experience from what things we needed (& what things broke down) (and what questions we got) at mobile demos over the last couple of months:
 (at Hex House or at home, we have a little more scope to just restart things, we have laptops and other tools around, the Wi-Fi is known-good, etc, so these problems are not as acute)
-  * Grayed-out printing of receipts -- not reliable?
+  * Sometimes printing of tags on receipts is a bit faded -- makes detection less reliable
-  * Calibration gets knocked around, is often off
+  * Calibration gets knocked around if the front panel moves (which it will, it's only attached at 2 screw points) or the camera wiggles off its PCB (the glue seems weak? is it the heat?)
-    * Solution (not implemented yet): Need to make camera attachment to gadget more rigid
+    * Solution 0 (done): superglue the camera back to the PCB
-    * Another solution: Need to make calibration fast and reliable on the go
+    * Solution 1: make camera attachment to gadget more rigid; put the threaded holes on the gadget chassis instead of on the separate panel
+    * Solution A: make calibration fast and reliable on the go
       * or have a fast, quick calibration refinement we can do, rather than the full calibration
-  * Printer status not clear
+  * Printer status not clear, pressing Ctrl-P can be uncertain
-    * Solution 1: Printer control cards
+    * Solution 1 (done): Printer control cards
-  * Wi-Fi is questionable
+    * Solution 2: Ambiently show printer status, print job status once you hit Ctrl-P?
-  * TODO: EDID fix
+  * Wi-Fi is questionable as a way to talk to Folk -- you need to manually get it on the network SSID and password & sometimes [[https://x.com/rsnous/status/1849252167053721945|local connections are blocked]]
+    * Solution 1: use Bluetooth Low Energy
+    * Solution 2 (achieved): carry portable wireless USB keyboard that can always go to a Linux terminal, enter Wi-Fi options, do other stuff
+    * Solution 3: some kind of wired serial terminal that you can drive from laptop?
+    * Solution 4: run an ad-hoc Wi-Fi always? haven't figured this out yet
   * Reliance on power outlets is very annoying -- what if you have a meeting at a cafe? what if you just want to carry the thing around the warehouse and point it at walls?
     * Solution: Waveshare makes a [[https://www.waveshare.com/ups-module-3s.htm|standalone battery unit for the Pi 5]] that is perfect -- it's not a hat, so it works with our existing design -- Velcro it to the top of the gadget for now
       * {{:newsletters:pasted:20241029-090746.jpeg?150px}} {{newsletters:img_8468.jpg?150px}}
       * (maybe do a respin with a built-in battery hat? unit would get significantly bigger)
+      * does this break the projector?
   * Calibration not reliable?
-  * Would be good to pre-print:
+    * -> "camera occlusion seems to be a big problem (i don't really feel this but it could be the position from which I was presenting)"
+    * -> "My arms kept getting in the way. I think more than occlusion, the tag masking wasn't working great for some of the programs I had out and that was getting misinterpreted as being an occlusion problem."
+    * -> "yeah, if you're leaning hard on tag masking I think you need 1mm accuracy -- often I would say that tweaking exposure is the key thing (and there's a lot we could do in the UI to support making better calibration, too)"
+  * Daniel: Would be good to pre-print:
     * Recalibrate card
-    * Display camera frame on table card (to help adjust exposure)
+    * Display camera frame on table card (to help adjust exposure while calibrating, debug tag detection failures)
-Escape hatches: bring a laptop, bring a mobile hotspot, ssh, web ui
+Daniel's escape hatches: bring a laptop, bring a mobile hotspot, ssh, use the web ui
 ===== What we'll be up to in November =====