We’re on the cusp of restarting Yukon development and I was reminded of some lessons I’ve learned that I haven’t applied to this project. @lorenz.meier recently remarked on the importance of full and realtime logging for this tool and the performance problems we’ve had trying to read, deserialize, and present logs using Python for very busy systems with lots of traffic. Lorenz has seen this problem with the v0 tools and I’ve seen this problem on my systems with the v0 tools (CAN-FD makes it much worse). One school of thought is that we should expect beefy development boxes are used for such things but in reality it’s crufty, old maintenance systems or specialized embedded devices that will run the Yukon backend. This suggests that using Python as the backend technology for Yukon may be a fundamental mistake? Perhaps we should be writing this in C++ to maximize efficiency and portability? Perhaps we should use Rust because all the cool kids are doing it and it’s way more fun…and we’ll get the performance we need if not the portability to embedded devices (yet)? Perhaps even (dare I say it) go?
The problem with this is we have pyuavcan so we can start on a python backend immediately. To choose C++ we need libuavcan and to choose rust we need uavcan.rs (anyone working on uavcan.go-or-whatever-convention-that-language-uses)? Even so, this may be important enough to sequence things differently.
Additionally, allowing the Yukon backend to run on an embedded target opens up the possibility of creating purpose-built UAVCAN debugging appliances that are portable or even integrated with the vehicle system itself.