Feature Request: Enable navigator-rs usage with vanilla Raspberry Pi OS/non-BlueOS systems #101
Description
At the moment, the Builder methods that are available for constructing a new Navigator instance, which tends to panic (per #57) when hardware is not located at the paths that it expects. As an example, I received panics recently while trying this with default Raspberry Pi OS Lite due to it only have /dev/spi0.1 available in the device tree for the ICM20689 initialization, not the /dev/spidev1.2 that the library currently looks for.
The boxed AnyHardware trait that the Navigator uses is really cool for dynamically managing various pieces of hardware, and I'd love to see a more transparent Builder pattern for each piece of hardware that might allow end users to selectively choose and configure the appropriate sensor modules available on the board, which would also enable them to modify interfaces for various upstream operating system versions that might not line up with BlueOS's expectations.
I believe this would line up well with the Navigator's stated goals, per the Discuss forum announcement at https://discuss.bluerobotics.com/t/navigator-library/14838, where
The Navigator board has huge potential, and we want to unlock the hardware capabilities for a new range of users. Whether you’re developing a new solution, interacting with your ROV hardware, or just experimenting, this library paves the way for endless possibilities. Now, you can create your own application without dealing with MAVLink messages or ArduSub firmware - your code can access the hardware directly!
This would support users who want to stick primarily with upstream, without necessarily wanting to manage MAVLink, ArduSub, or potentially even the extended BlueOS container set-up and focus primarily on direct use of the awesome hardware interfaces available on the board.