Some background: I quit my job to go fill a need I saw in the robotics industry. The current industry standard for robotics frameworks is lacking in a lot of ways, especially around testing and simulation. Over the past few months I've worked my ass off to get the basics of the framework up and running, and now finally I can show off the determinism features.
The code that back this isn't (yet) available for others to play with, but hoping to get there soon (not looking to be perfect before release, but I want the robot I'm building a demo on to be usable). Even if the code isn't runnable for others, hopefully it will give some food for thought.
This post also coincides with moving to an actual website (Jekyll is cool), but given I already handed out the link to the blog post to HN and a few friends, I'll have to hold off on taking down the old site and reconfiguring GH pages to use the domain.
Always exciting to see more innovation in the robotics middleware space!
Do you have a zero copy/serialization way that nodes can output messages back to their own input?
For example I have always thought that full determinism would be much easier to achieve if all nodes were purely functional/stateless, and if they want to accumulate data over multiple messages they must do so by explicitly outputting that state back to themselves.
This would mean that all state can be logged (if necessary), and therefore resimulation tests could start with a single tick, rather than needing to play back several seconds of data because there is no way to reason about what local state nodes might be maintaining.
Yes, though I'd want to add special detection for this case - to ensure that there are no runtime race conditions for having or not having a state from last frame. No serialization occurs unless the message goes over a non-inproc transport (unserializable inproc only messages are possible, too!).
I've considered this kind of idea before - I'd likely try to make it a first class citizen of the framework, in that case. Declare it in the definition for your node what kind of state it keeps, rather than try and shoehorn it into the pubsub system.
I'd have some worry about the performance cost of it, though, for large states.
Determinism in testing, replay,, etc. is indeed a generally important problem in many areas of software dev - but too much cmake, protobufs, gtest obfuscation in this Readme for your contribution
Some background: I quit my job to go fill a need I saw in the robotics industry. The current industry standard for robotics frameworks is lacking in a lot of ways, especially around testing and simulation. Over the past few months I've worked my ass off to get the basics of the framework up and running, and now finally I can show off the determinism features.
The code that back this isn't (yet) available for others to play with, but hoping to get there soon (not looking to be perfect before release, but I want the robot I'm building a demo on to be usable). Even if the code isn't runnable for others, hopefully it will give some food for thought.
If you're interested in seeing a bit more we have our "Hello World" tutorial here: https://github.com/basis-robotics/basis-examples/blob/main/c...
This post also coincides with moving to an actual website (Jekyll is cool), but given I already handed out the link to the blog post to HN and a few friends, I'll have to hold off on taking down the old site and reconfiguring GH pages to use the domain.