newsletters:2023-12
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| newsletters:2023-12 [2023/12/30 00:51] – [Calibration] osnr | newsletters:2023-12 [2023/12/30 23:20] (current) – [What we'll be up to in January] osnr | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== December 2023 newsletter ====== | ====== December 2023 newsletter ====== | ||
| + | |||
| + | It's been a big year. Hard to believe that a year ago, there was exactly 1 Folk system in the world (the original one, folk0 at Hex House) & it ran about ten times slower than what we have now and could barely do anything besides display text and outlines. But there' | ||
| If you're in New York next month, we'd love to have you visit us at **[[https:// | If you're in New York next month, we'd love to have you visit us at **[[https:// | ||
| Line 16: | Line 18: | ||
| * Andrés made a [[https:// | * Andrés made a [[https:// | ||
| * {{newsletters: | * {{newsletters: | ||
| - | * Andrés and Charles collaborated on a Folk program that extends this to a ball that bounces around the table | + | * Andrés and Charles collaborated on a Folk program that extends this to a ball that bounces around the table. |
| * During the open house, a visitor asked Cristóbal if he could change the frame rate of his animation tool. It works splendidly: | * During the open house, a visitor asked Cristóbal if he could change the frame rate of his animation tool. It works splendidly: | ||
| Line 33: | Line 35: | ||
| * We're still pretty pre-release and liable to break things, but we have a [[https:// | * We're still pretty pre-release and liable to break things, but we have a [[https:// | ||
| - | * Merged | + | * Merged |
| * {{newsletters: | * {{newsletters: | ||
| + | |||
| + | * Cris has been working on [[https:// | ||
| + | * {{: | ||
| * Omar has been continuing to do a small amount of messing with an independent parallel Folk trie/ | * Omar has been continuing to do a small amount of messing with an independent parallel Folk trie/ | ||
| Line 40: | Line 45: | ||
| ==== Tabletop / in-system editor ==== | ==== Tabletop / in-system editor ==== | ||
| - | * Andrés has continued work on the editor. There' | + | * Andrés has continued work on the in-system |
| * {{newsletters: | * {{newsletters: | ||
| + | * Charles visited the studio this month and gave Andrés some great ideas for the editor for future releases. | ||
| ==== Calibration ==== | ==== Calibration ==== | ||
| Line 88: | Line 94: | ||
| Cristóbal and I spent a day trying some tactics to reduce jitter, which I think might be the single biggest impediment to getting this thing merged and usable. The jitter is really noticeable in person. | Cristóbal and I spent a day trying some tactics to reduce jitter, which I think might be the single biggest impediment to getting this thing merged and usable. The jitter is really noticeable in person. | ||
| - | The actual 2D AprilTag detection of corners in the camera image is actually very stable and reliable, and the images are clear, so that's not a source of jitter in our view. | + | The actual 2D AprilTag detection of corners in the camera image is actually very stable and reliable, and the images are clear, so that's not a source of jitter in our view. (We tried some moving-average smoothing stuff on the detected tag corners, but it didn't work that well, even if we made it really aggressive. We concluded that it has to be further on in the pipeline, not the input corners.) |
| So you have a stable input (locations of the corners in the camera image) and a pure function (camera corners -> 3D pose estimate -> reprojection corners), but somehow the output projection has jitter. So where is the jitter in the function? | So you have a stable input (locations of the corners in the camera image) and a pure function (camera corners -> 3D pose estimate -> reprojection corners), but somehow the output projection has jitter. So where is the jitter in the function? | ||
| Line 110: | Line 116: | ||
| ==== RFID refactor ==== | ==== RFID refactor ==== | ||
| - | Omar: the long-awaited RFID refactor is finally underway: I've made a lot of progress on it and have kind of broken through the previous point where I was stuck. | + | Omar: the long-awaited RFID refactor is finally underway: |
| {{newsletters: | {{newsletters: | ||
| - | I wouldn' | + | I haven't caught up with our original |
| - | {{newsletters: | + | {{newsletters: |
| And here we query the tag a few times in a row and get a valid, checksum-passing ID response each time (although we're not printing the ID itself here, only the expected+received checksums): | And here we query the tag a few times in a row and get a valid, checksum-passing ID response each time (although we're not printing the ID itself here, only the expected+received checksums): | ||
| Line 128: | Line 134: | ||
| * we have an end-to-end way to check channel estimate validity! we've always derived channel estimate from a tag reply packet, but we had no way to check that 1. that packet was legitimate and 2. our decoding of that packet was correct until now; now we can check that it got us a tag ID and that the tag ID passed checksum. this should help keep us from going off the rails with invalid data feeding into location estimate | * we have an end-to-end way to check channel estimate validity! we've always derived channel estimate from a tag reply packet, but we had no way to check that 1. that packet was legitimate and 2. our decoding of that packet was correct until now; now we can check that it got us a tag ID and that the tag ID passed checksum. this should help keep us from going off the rails with invalid data feeding into location estimate | ||
| - | and of course, you ultimately need tag identities to do any interesting application with RFID tags -- that's the point of them -- so we knew we needed to do this sooner or later. It's also the hardest part of implementing an RFID reader on software-defined radio, because it's highly latency-sensitive (you need to decode entire tag packet and respond within 500 microseconds or so to get the tag ID), so it's a huge relief that we are able to do it and won't have to change approach to get it to work. | + | and of course, you ultimately need tag identities to do any interesting application with RFID tags -- that's the point of them -- so we knew we needed to do this sooner or later. It's also the [[https:// |
| Line 164: | Line 170: | ||
| The cart uses a cheap utility cart from Amazon and some two-foot quick clamps to keep the ultra-short-throw projector from falling over (and some blocks of wood we had lying around Hex House to raise the projector to table height while letting the HDMI and power cords jut down underneath). It's not the most stable thing ever -- you have to hold the projector while rolling it -- but it works well enough, and it's so nice that it's finally a self-contained unit. | The cart uses a cheap utility cart from Amazon and some two-foot quick clamps to keep the ultra-short-throw projector from falling over (and some blocks of wood we had lying around Hex House to raise the projector to table height while letting the HDMI and power cords jut down underneath). It's not the most stable thing ever -- you have to hold the projector while rolling it -- but it works well enough, and it's so nice that it's finally a self-contained unit. | ||
| - | (We probably also want it to have a longer power cable. Ten feet is too short, I think.) | + | (We probably also want it to have a longer power cable so we can wheel it around the space without unplugging and replugging. Ten feet is too short, I think.) |
| === Folk User Group === | === Folk User Group === | ||
| - | We had a "user group" meeting in Discord on the evening of the 19th, where we got on a call with people in the community (mostly people with running Folk systems). It was fun to see everyone again (the last one we did was a few months ago); we explained some recent and upcoming improvements to the system & we did some Q&A: | + | We had a "user group" meeting in Discord on the evening of December 19, where we got on a call with people in the community (mostly people with running Folk systems). It was fun to see everyone again (the last one we did was a few months ago); we explained some recent and upcoming improvements to the system & we did some Q&A: |
| - | * TODO: Improvement A | + | * Andrés discussed editor, cart, CNC system, open-source |
| - | * Improvement B | + | * Naveen asked about system federation, wall-table (manipulation surface + larger display surface) |
| + | * New calibration: We walked through the 3D calibration process live on camera (waving the calibration board around and watching it rewarp tags) | ||
| + | * Omar gave a quick primer about how the evaluator works | ||
| + | * Printed out and showed the key data structures (statements, | ||
| + | * {{newsletters: | ||
| + | * Daniel asked about events and event statements, so we talked a little about the semantic details there | ||
| + | * Cris asked for a walk through a single evaluator step, so we did a whiteboard talk about the operations that go into the priority queue (Assert, Retract, Say, Unmatch, Collect) and how that queue gets drained each step | ||
| + | * {{: | ||
| + | * Naveen asked about scaling properties: would it scale to thousands/ | ||
| + | * (it should.. or at least adding a new statement shouldn' | ||
| + | * Discussion of integrating Box2D or other engines/ | ||
| + | * Cris talked about tableshots | ||
| + | * Omar: "I remember talking to Jacob about this -- how much every little weird capability addition actually opens up, where it's like, oh, we can crop images, or we can display images rotated, or we made a button, and each little thing opens up an entirely new class of applications and demo interactions. That's really exciting, especially as we have more of these things." | ||
| + | * Ian asked about hand tracking, OCR, and other inputs besides AprilTags, how hard they would be to integrate | ||
| + | * Andrés talked about the One Fact object recognizer model | ||
| + | * Ian also asked about X11 or some other way to contain existing graphical applications in a page | ||
| + | * Talked about next steps, board game format, documentation | ||
| - | Omar gave a quick primer about how the evaluator works. TODO | + | We'll do another one in a few months, most likely. |
| ===== What we'll be up to in January ===== | ===== What we'll be up to in January ===== | ||
| Line 181: | Line 203: | ||
| * improving the RFID error recovery / state machine; starting on sync and OOB | * improving the RFID error recovery / state machine; starting on sync and OOB | ||
| * calibration accuracy improvement, | * calibration accuracy improvement, | ||
| - | * maybe hacking on a parallel Folk? | + | * maybe hacking on pure evaluator/ |
| * Finishing up the tabletop editor and getting it merged, then follow-up to make virtual programs table-editable, | * Finishing up the tabletop editor and getting it merged, then follow-up to make virtual programs table-editable, | ||
newsletters/2023-12.1703897477.txt.gz · Last modified: 2023/12/30 00:51 by osnr