ELO-273: feat(basilisk): add initial basilisk wrapper #429
Conversation
libs/basilisk-rs/Cargo.lock
Outdated
libs/basilisk-rs/src/queue.rs
Outdated
| vehicle_config, | ||
| ); | ||
| mrp_feedback.reset(0); | ||
| mrp_feedback.update(1); |
There was a problem hiding this comment.
I expect that a single FSW process would compose a set of basilisk modules and then run update() on them sequentially. Is that accurate? If so, could we use a simpler message passing solution like a mailbox?
I'm a bit skeptical of using flume in such a critical path. It has had a bunch of nasty bugs in the past, and the codebase is hard to audit because it's so expansive in scope. For running modules in parallel, we'd still use iceoryx.
There was a problem hiding this comment.
To clarify, this isn't be blocker. I just think we should reconsider this as part of the hardening process.
There was a problem hiding this comment.
TBH I just reached for it out of habit more than anything. I think this is actually a perfect place to use https://docs.rs/thingbuf/latest/thingbuf/mpsc/index.html
There was a problem hiding this comment.
https://docs.rs/thingbuf/latest/thingbuf/struct.StaticThingBuf.html seems ideal if we can get away with not blocking.
There was a problem hiding this comment.
Yeah StaticThingBuf makes sense to me, we could keep it bounded with a very small capacity. Basilisk expects us not to block, so we can just use try_recv
There was a problem hiding this comment.
Also has the nice added side-effect of making this code no_std compatible right of the bat
There was a problem hiding this comment.
Replaced flume with the non-static thingbuf in this PR. The static thingbuf has a slightly annoying property in that it basically needs to be defined in static var. That might be ok, but. I'm not sure so I'm going with the more flexible option for now
| let channel: *mut BskChannel<$payload_name> = | ||
| unsafe { std::mem::transmute(channel) }; | ||
| let channel: &mut BskChannel<$payload_name> = unsafe { &mut *channel }; | ||
| channel.read().unwrap_or_default() |
There was a problem hiding this comment.
Just curious what basilisk expects from the read/write calls. Is it ok to block or fail?
There was a problem hiding this comment.
The modules expect that you always return a value without blocking, even if it's stale. That makes the most since for their model since the modules are run in a single threaded loop, and so you wouldn't want them to block each other. The current impl mimics that behavior using that last_msg we store
This PR adds a simple wrapper around basilisk flight software modules. It replaces the basilisk message passing interface with one based on flume. The goal is to allow us to build wrappers around basilisk FSW algorithms, leaving them unchanged.