This is an old revision of the document!
Table of Contents
November 2024 newsletter (WIP)
(Our next Folk open house is at noon on Sunday, December 15, at our studio in East Williamsburg, Brooklyn.)
What we've been up to
Small system improvements
- TODO: Print notice when you hit Print, both on web and tabletop editor
- TODO: New /programs design with categories; much easier to read
New Folk evaluator
Omar: I've spent most of this month working on the new evaluator (folk2). I've made a huge amount of progress; it honestly feels like I spent months stuck on blinking/flickering/ghosting bugs and then solved them all last week.
(Remember, the goal of folk2 is to have 60fps under bigger workloads, so we can use multiple tabletop editors at once & do other demanding stuff natively in the system. I think it's just important that the system feel really good and smooth, anyway. Need to be running programs in parallel, avoiding queueing, also just general evaluator optimization. Another goal is to make the system hard to crash or freeze just because one program misbehaves, as in any other operating system.)
There's still a lot of blinking under the new evaluator, but no ghosting, and I think the blinking all now emerges from genuine failures to meet timing (the label blinks out because the program region wasn't regenerated in time for the current frame).
What were the bugs?
TODO
Other improvements
When (serially)
- tail trace
- atomic gen+rc+alive
- timestamp work items, figure out elapsed, schedule based on that
- fully separate match/statement 'removal' (which removes descendants) from memory freeing (which happens when rc = 0 and not alive)
- fix locking of destructor list
- fix locking of child match/statement lists
- steal-half
- fix lsorts in infinite loops (not using now that we have serial When though)
- show each statement's match children & statement grandchildren in web UI (makes debugging much nicer!)
- ports from folk1:
- dashed-line (want it for gadget marching ants)
- camera-rpi throughput improvement using YUV420 format
- implemented clock time (also want it for marching ants, and any kind of animation really)
- now runs on an independent clock from the frames! every 2ms
Profiling
Performance profiling
TODO: Performance profiling remaining.
I'm surprised at how much of the flamegraphs are just threading stuff, not CPU. Maybe I'm misreading and need different graphs.
Heap profiling
There are still persistent and pretty bad memory leaks on folk2.
TODO: Memory profiling remaining.
Various unsuccessful quests
- Heap profiling with gperftools
- mimalloc arenas
- Sealed Tcl objects
- CPU-oriented scheduling
- Spinlocks
RFID localization
Omar: Didn't have time to do much this month, but I did figure out how to make the IB program not crash in its new connection-dependent style. We now just drop samples from the radio until a PC connects and we set up a FIFO and RFID protocol parser then. (The current goal is to get IB and OOB both running and synced up to a reset signal over TCP from a PC, then stream info from IB and OOB to the PC.)
Portable gadget
Omar: Minor improvements:
- Ad-hoc Wi-Fi procedure, so you can boot the gadget and connect to its ad-hoc network from a laptop (to ssh, see web UI, edit programs, debug) without needing to get it on whatever the local Wi-Fi is
- tried to use NetworkManager, totally failed and gave up
- (there are downsides to ad-hoc Wi-Fi as a default, like it can't sync with other Folk systems. BLE still feels more correct… or maybe multiple Wi-Fi adapters)
-
- (this is really the only change I made to actual mainline Folk source code this month)
Right now, the biggest issues with the gadget in practice are:
- decalibration because the camera is attached to the front panel, not the gadget chassis, and the front panel flexes
- solution: attach the camera to the gadget chassis! been meaning to do this for a while
- working on it, but haven't re-assembled and tested the gadget with the new case (I haven't figured out what to do with the front panel now):
- (notice how the camera attach point – the four holes – is now on the case itself, so it should be fixed with respect to the projector which would also be rigidly attached to the case)
- manual exposure not reliable (especially with a lot of sunlight/ambient light), tags often get washed out & don't detect when you just pull the gadget out somewhere
- idea: autoexposure?
- idea: self-autocalibration button/card that tunes exposure until it can see itself?
Trigger button, speaker, battery
These are all 'minor' additions to the gadget that I want to throw into future revisions (and have ordered parts for).
I've been talking about a trigger button for a while. Realized that some commercially available camera grips just use an audio jack. This seems good. Threw it into part orders and will probably throw it into next design rev.
(I also threw a speaker into part orders.)
I'm thinking about the Super Mario Galaxy Wii remote interactions and sounds for some reason.
New off-the-shelf revision
I've been working on a new revision that uses the new off-the-shelf commercially available AnyBeam projector (you can just buy it on Amazon), so we'd actually be able to make them in quantity and give them to people. Trying to use as easy-to-get parts as possible.
The main (surprisingly big) issue is that this new AnyBeam only has a single USB-C port – no more HDMI in – which means it is incompatible with the standard Raspberry Pi 5, which can only do HDMI out.
(On the other hand, this'll be nice if we can get it to work, because it means one USB-C cable for everything, no more weird adapters and separate HDMI and power cables to fit inside the device. And it means probably more reliable power delivery to the projector through the standard USB-C cable, not running off a random USB-A port on the Pi anymore.)
So I spent a while looking at Pi alternatives.
- The Orange Pi 5 would be good if it worked (I already have at least one or two lying around, and it's easy to get), but there's almost no way to connect a decent camera to it without an additional board/adapter. And it's a different form factor than the Raspberry Pi, so we couldn't use a battery hat.
- It does work (but, again, the lack of a decent camera solution is a dealbreaker):
- The Radxa Rock 5B (or 5B+ if it comes back into stock) is probably what I'll try for the time being. (waiting for it to ship right now.) Annoyingly hard to get / expensive / long-term support might not be great (and it's a big board compared to the others, 100 mm x 75 mm), but it has an okay camera story, it's similar to the Raspberry Pi form factor, and it has USB-C video out.
(Both of these use Rockchip chipsets, and I have some concerns about Vulkan support on those, too..)
Anyway, I realized this week that the right thing to do might be to use the new Pi Compute Module 5 and design a new PCB carrier board for it (which would have a HDMI or MIPI-DSI to USB-C converter that could feed the projector, and proper MIPI-CSI ports for 1-2 cameras, and could fit onto a battery). Then we'd have full Pi camera and software and long-term support, plus the right outputs for the projector, plus we could probably shrink the hardware down a bit. But I'd need to learn how to do that
Friends and outreach
- Had our monthly open house:
- Nice to see people playing around with the cube, the portable gadget (now that we have two, we can have one arm-mounted and one handheld), and editing programs on the table
- Special guests: Paul from Greenville, SC where they've set up a Folk system, and Jessie who set up the Folk system at Recurse Center in downtown Brooklyn. Was nice to be able to talk through specific details/questions about people's Folk setups
What we'll be up to in December
- Our next Folk open house is at noon on Sunday, December 15, at our studio in East Williamsburg, Brooklyn.
- Fix blinking in new evaluator (that is, performance optimization so the programs resolve under 16ms)
- Create a pull request for the new evaluator
- Port the remaining virtual programs/features
- Initial new gadget revision that uses the AnyBeam & Rock 5B
- Finish assembling new-old gadget that has fixed camera
- Gadget trigger button
- Gadget autoadjust exposure maybe?
- RFID