Differences

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

--- newsletters:2026-08 [2026/09/22 14:04] – [Visitors] osnr
+++ newsletters:2026-08 [2026/09/22 14:20] (current) – [Object tracking] osnr
@@ Line 130: / Line 130: @@
         * Raw centroid of contour
         * Compute centroid transform by registering centers at a few different points
-        * Same-side arc contour
+        * Same-side arc contour or opposite-side arc contour: if you just take the side either near the camera or away from the camera, you know it's consistently the arc of the top or bottom of the object
-        * Opposite-side arc contour
+          * {{.:pasted:20260922-141914.png?200px}}
+          * This was most promising for a while and felt most principled
 Interpolation (SAM2 is pretty slow, 60-100ms per frame)?
@@ Line 139: / Line 140: @@
-=== Object registration persistence ===
+=== Object registration persistence on SAM2 ===
 One thing we've wanted is for object registrations ("track this cup", "track this ball") to persist across system crashes/reboots. Then we would feel more confident playing around with it even if the system crashes, and it would feel more like a basis for a permanent game or rulebook instead of an ephemeral tech demo. (it'd be more like a peer of AprilTag recognition, I guess, which similarly works immediately after you restart the system, so you can take it as a solid primitive)
-https://github.com/FolkComputer/folk/commit/56ddc2f00c16ca44eaa8bed5b352efcf0b2b0260
+Implemented by [[https://github.com/FolkComputer/folk/commit/56ddc2f00c16ca44eaa8bed5b352efcf0b2b0260
+|saving all this random Python state from SAM2]], which does work to some extent if the scene continues similarly enough after restart, but has re-ID problems, and (inelegantly) has to save to a separate file instead of being in a persisted statement.
 === Fix Expect! use-after-free of camera slices ===
-Registration code
+Registration code has you put the object at 3 poses, so it needs to save the camera slice at each pose (the camera slice's lifetime has to be extended beyond normal).
-https://github.com/FolkComputer/folk/commit/cd2049e72e9ed741e225e9539fa8b8a803d7ef42
-Garbage in registration image due to use-after-free
+Problem: registration uses Expect! to get the pose, which wasn't inheriting (keeping-alive) the destructor for the camera slice, unlike a When would. So you get random use-after-free where your registration poses are garbage. Garbage in registration poses due to use-after-free:
 {{newsletters:img_7873.jpeg?0x200px}} {{newsletters:img_7621.jpeg?0x200px}} {{newsletters:img_7872.jpeg?0x200px}}
@@ Line 157: / Line 156: @@
 {{newsletters:img_7890.jpeg?0x300px}} {{newsletters:img_7892.jpeg?0x300px}}
-Another use-after-free
+Another use-after-free, seen from the web ui:
 {{newsletters:screenshot-2026-08-11-at-4.59.14-pm.png?0x300px}}
+[[https://github.com/FolkComputer/folk/commit/cd2049e72e9ed741e225e9539fa8b8a803d7ef42|Solution for now: Expect! inherits destructors into current match.]] It's actually not that clear that this is the right long-term design choice, since it'll now leak if you use Expect! in an infinite loop or something, but seems ok for now. (You also have to be careful to use Expect! inside the Hold -- so it's in same block as the statement claim -- and not separately before the Hold, since the Hold also won't inherit the destructors. Still lots of pitfalls with destructors/Hold/Expect.)
 ==== RFID localization ====
@@ Line 181: / Line 183: @@
 I found a few issues this month:
-  * Bad sync pattern: the single pulse I was using (from IB to itself and to OOB) was not distinguishable enough from actual RFID protocol communications. I probably could have tuned the thresholds and detection algorithm, or just have OOB decode IB RFID messages directly, but instead using a longer / more unique pattern for now
+  * Bad sync pattern: the single pulse I was using (from IB to itself and to OOB) was not distinguishable enough from actual RFID protocol communications. I probably could have tuned the thresholds and detection algorithm, or just have OOB decode IB RFID messages directly, but instead using a longer / more unique pattern for now. We sync every round, not just at reset time, because there is drift
-  * Tearing
+  * Tearing: rounds would stomp previous rounds in RAM on the radio mid-copy, so even if they were fine on the OOB radio, we were getting torn data on the PC which was totally wrong, so you'd get apparent desync in the middle of the round. Need to lock the slots on the circular buffer on the radio.
-  *
-Here's a successful alignment:
@@ Line 194: / Line 191: @@
 === Localization ===
-I've started doing localization. It feels more valid than last time -- less garbage and random flickering, and when it works it works.
+I've started doing localization. It feels more valid than a couple of years ago -- less garbage and random flickering, and when it works it works.
 {{newsletters:img_8474.jpeg?400px}}
+A big limitation right now is just pickup range. I made a decoding improvement, to use phase and not just amplitude, which helped a lot, but still more to do next month.
+We can definitely pick up on the tag at 1ft -- 3ft is when it gets sketchier. (way below the advertised 10m range of UHF RFID...) And if we can't pick up on the tag, we definitely can't localize:
 == Problem tiers ==
@@ Line 209: / Line 210: @@
   - Successful RN16, decode correctly, send correct RN16 back, get EPC from tag, decode correctly, checksum succeeds. We have a valid EPC from the tag!
-We're starting to break these out into the PC UI. Note that we can only localize with data where we know we've decoded the tag response correctly, since only then do you have verified-good bit timing boundaries and reflective/non-reflective distinction! For now, we've been using only tier 6 data, but I guess you could use lower tiers if you have a known-good RN16 but not EPC? But in practice, I don't know if there's a way to establish that. The checksum is really reassuring compared to anything else where you might literally be decoding noise (our decode is often 'maximum likelihood' style where you assume meaning is there and find the most likely place for it to be, rather than yes/no).
+(These are tiers for an individual hop. There's a further sequence of tiers that is about the whole round of hops, where we're hopping every 20MHz to cover 800MHz to 1080MHz to get the wideband channel estimate.)
+We're starting to break these tiers out into the PC UI.
+{{.:pasted:20260922-141500.png?600px}}
+Note that we can only localize with data where we know we've decoded the tag response correctly, since only then do you have verified-good bit timing boundaries and reflective/non-reflective distinction! For now, we've been using only tier 6 data, but I guess you could use lower tiers if you have a known-good RN16 but not EPC? But in practice, I don't know if there's a way to establish that. The checksum is really reassuring compared to anything else where you might literally be decoding noise (our decode is often 'maximum likelihood' style where you assume meaning is there and find the most likely place for it to be, rather than yes/no).
 == Picking up the tag at distance ==
@@ Line 253: / Line 260: @@
 === Visitors ===
-  * JP Posma, Louis Potok, Han Seoul-Oh (friends of JP's, who we know from SF and [[https://paperprograms.org/|Paper Programs]] came by)
+  * [[https://janpaulposma.nl/|JP Posma]], [[https://www.louispotok.com/|Louis Potok]], Han Seoul-Oh (friends of JP's, who we know from SF and [[https://paperprograms.org/|Paper Programs]] came by)
     * {{newsletters:img_7921.jpeg?150px}}
   * Omar's friend [[https://www.mooshell.com/|Michelle Park]] visited in late August