Support for Rust flight software modules #262
Replies: 7 comments 17 replies
|
As an update, I shared Basilisk with the AeroRust forum and found several people interested in collaborating on bringing Rust to Basilisk. @schaubh do you have any resources or thoughts on how this could be done? Is there documentation on how basilisk integrates C modules that the Rust collaborators could look to for integrating Rust.modules? |
|
The first challenge is does the SWIG language support Rust? I don't think it does. Then the build system would have to be updated to support compiling such modules. Generally speaking I like the BSK supports simulations with components written C, C++ and Python. It would be interesting to explore what it would take to include BSK modules written in other languages. @patkenneally, do you have any thoughts on this? |
|
SWIG doesn't have built-in support for Rust. I found a thread discussing it here: swig/swig#1468 |
|
We love Basilisk and are especially excited about the possibility of maintaining software equivalence between simulation and flight, but we're hoping to use rust for flight software to take advantage of it's greater safety. In my opinion, the question doesn't need to be about supporting other languages generally. Rust stands out as the next-generation of C and is well underway in adoption. For example, Rust is the only other language to receive support in the Linux kernel (starting with Linux 6.1): https://www.infoq.com/news/2022/12/linux-6-1-rust/ |
|
The key is creating a Python interface to the compiled code. There might be other tools out there that could be used for Rust BSK modules to create python bindings. However, just to be clear, this is not something we are currently working on. |
|
Right, I understand you're not working on this, but it sounds like there's interest in the aerospace rust community in working on this. My question was more of where should we start? |
|
This PR added support for using non-swig modules inside basilisk : #652 |
|
@spiggottCO , please see comment above about your PR helping support Rust. Any thoughts on this? |
|
Hi @schaubh, I've looked into the Rust/Swig support. It looks like there is a PR open for Rust on the swig repository, but it is not clear how soon support for that will land in Swig or if it will at all. In the meantime it isn't that hard to reuse a similar solution to the C++->C wrapping that Basilisk already does, since most languages have a C compatible FFI. @patrickwalton is having me look into this, and I've already got a working implementation. The questions I have are not really technical (its possible and not too hard), but more around the user experience (both from typical Rust users learning Basilisk, as well as Basilisk users learning or adopting Rust). I'm excited to share our branch and progress soon, but before opening a PR I want to start discussion on what it would take to get such an experience upstreamed, so that I don't spend too much time headed down the wrong direction, particularly when it comes to user experience expectations. As someone coming from Rust, and just learning Basilisk, I've heavily leaned into idiomatic Rust, type safety, and the macro / build-time code-generation that Rust provides. For example, using the Basilisk/CMake build system for plugins, I call out to Cargo to build the Rust module, including generating C wrapper interfaces that are needed for SWIG. Additionally, separately I generate Rust wrappers for some of the standard messages and utility libraries basilisk provides. This can seem like "magic" sometimes, but reduces the setup complexity and overhead, keeps things more reliably in sync, and preventing user errors and reduces the maintenance burden. I believe this amount of code-generation provides a baseline experience that means users can switch to Rust without feeling like it being too much of a second class citizen. A few maybe more controversial changes include automatically handling some of the messaging boilerplate: generating the is_linked calls in the reset function based on whether an input to update has an optional type, and automatically reading the input messages and writing the output messages at the beginning and end of the update function - the update function in Rust just takes a tuple of the inputs and expects a tuple of the outputs. In particular this prevents accidentally forgetting to write an output. I plan on having good documentation for getting started with Rust modules. Before pushing to hard into finalizing the design and polishing documentation I'd like to get your input. Does this seem like a good direction to you? What are your concerns? We can dig into details on particulars in a PR, just would like high level feedback now. |
|
As is, the PRs are targeting support for just the extension use case, so I started with adding it in the bsk_sdk directory (for extensions). But I'm happy to look into what it would be like to support modules in general. It does make sense to me to colocate the generation of Rust message wrappers and basilisk utility wrappers with the basilisk SDK itself. Then bsk_sdk can be in charge of just python wheel packaging, and synchronization scripts like you say. Still learning my way around these codebases, thanks for the pointer and pushback. I don't think that it should be too hard to migrate to this approach. However, it does mean that we need to gate Rust support behind some flag (and be okay with some modules not compiling), or require basilisk developers to have a Rust toolchain installed. I can set up Github CI to have rust installed as well. |
|
Just updated #1483 with support for Rust modules in BSK not just extensions in BSK-SDK. The BSK-SDK changes can land afterwards. I'm sure there is more refinement to do, but I did add CI checks for both. |
|
We are working on a rust translation of all basilisk modules, messages and simulation base class.The project is at the early stages and we have a few examples working already. Since, you are well versed in the language, we would love to hear your feedback/suggestions. You can refer to this post for more info. |
|
Howdy @themouli , thanks for the update. With your implementation, you will have Rust specific messages, modules and simulation base class? Or, would you now have 4 languages supported in BSK (C, C++, Python and Rust)? We are aiming for the latter. I was able to get @TimWhiting's concept branch to compile on my system, and we are working on some refinements. My goal is to have Rust modules be included as 1st class citizens in BSK. Rust will be for now an optional build component, but will be tested on CI PR requests. We also want to ensure Rust modules can be developed for the BSK-SDK extension wheels. Regarding messaging, we are using the C-msg definitions as the common msg definition between the languages. C++ specific messages can't be used in C modules or Rust modules in this version. |
|
Hello @schaubh, apologies for the delayed response. Yes, the idea is to have everything in rust (messages, modules, simulation base class, etc) and provide support to other languages via FFI. AWe are also considering plugins to integrate with commonly used FSW frameworks such as F Prime. This would allow us to benefit from Rust’s features, such as memory safety, throughout the simulation framework. We are still iterating on the framework design and deciding which approach to follow. We would love to hear your feedback. |
|
Ok, I'll start with that. Thanks for making this switch. I see extensions providing the ability to make stand-alone BSK wheels, but core functionality should originate in core BSK. That said, have several other PRs, tasks, and some papers to finish up. Might be next week before I get to this. |
|
No worries. I've been working on improving the documentation and porting one of our custom modules to flush out any problems with the api and implementation. |
Uh oh!
There was an error while loading. Please reload this page.
The Rust Programming language is designed as a more reliable alternative to C. Has anyone thought about what it would take to implement support for flight software modules written in Rust?
There's a great AeroRust community for aerospace projects written in Rust. They'd probably be really excited about collaborating on basilisk Rust support.
All reactions