newsletters:2026-08
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| newsletters:2026-08 [2026/09/22 14:16] – [Localization] osnr | newsletters:2026-08 [2026/09/22 14:20] (current) – [Object tracking] osnr | ||
|---|---|---|---|
| Line 130: | Line 130: | ||
| * Raw centroid of contour | * Raw centroid of contour | ||
| * Compute centroid transform by registering centers at a few different points | * Compute centroid transform by registering centers at a few different points | ||
| - | * Same-side arc contour | + | * Same-side arc contour |
| - | * Opposite-side arc contour | + | * {{.: |
| + | * This was most promising for a while and felt most principled | ||
| Interpolation (SAM2 is pretty slow, 60-100ms per frame)? | Interpolation (SAM2 is pretty slow, 60-100ms per frame)? | ||
| Line 183: | Line 184: | ||
| I found a few issues this month: | 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. We sync every round, not just at reset time, because there is drift | * 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: 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 | + | * 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. |
| Line 190: | Line 191: | ||
| === Localization === | === 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: | {{newsletters: | ||
| Line 208: | Line 209: | ||
| - Successful RN16 response from tag, we decode it correctly, send the correct RN16 back, then get an EPC from tag, then decode it incorrectly and fail checksum | - Successful RN16 response from tag, we decode it correctly, send the correct RN16 back, then get an EPC from tag, then decode it incorrectly and fail checksum | ||
| - Successful RN16, decode correctly, send correct RN16 back, get EPC from tag, decode correctly, checksum succeeds. We have a valid EPC from the tag! | - Successful RN16, decode correctly, send correct RN16 back, get EPC from tag, decode correctly, checksum succeeds. We have a valid EPC from the tag! | ||
| + | |||
| + | (These are tiers for an individual hop. There' | ||
| We're starting to break these tiers out into the PC UI. | We're starting to break these tiers out into the PC UI. | ||
newsletters/2026-08.1790086607.txt.gz · Last modified: by osnr
