Navigator - navigator-lib with no containers

Blue Robotics Products
1

Hello,

I purchased a Navigator after seeing the navigator-lib was available, assuming I could run a vanilla setup with no containers or extraneous backend software, and just leverage the hardware. I have experimented with different operating systems trying to get the overlays working, and settled on using the default image, and was going to strip out things I don’t want running. On this image, I had the navigator board working just fine, and I followed the instructions to setup the SITL configuration to run the library. Everything was working. I then went to remove the docker containers, and now nothing in the navigator-lib works. Previously, I would kill the docker containers while I was in the Raspberry Pi, and I was able to run the same programs just fine, where I thought it was okay to remove them.

I can interface with i2c devices, but now I cannot even initialize the board (i.e. navigator.init()). Is navigator-lib dependent on a docker container setup or something else that it configures at runtime? I’ve rebooted several times, and every time I run the Python examples or C++ examples (which compile fine), it says that a resource is busy/unavailable. Can someone explain what is going on under the hood? I purchased this board and wanted to employ it on several custom vehicles, but it doesn’t seem very reliable so far. After I would turn on SITL / turn off ArduPilot, it was randomly turning on sometime later and after reboot. There were several other forum posts relating to similar topics, but it doesn’t seem like the core questions have been answered.

The error is on lib.rs 313 during CS2 export. I can manually flip the registers with raspi-gpio, but I cannot change GPIO 16 by exporting the pins via “echo 16 > /sys/class/gpio/export”. With this, I get a “device or resource busy error”

➜  python git:(master) ✗ python3 rainbow.py
thread '<unnamed>' panicked at 'Error: Error during CS2 export: Io(Os { code: 16, kind: ResourceBusy, message: "Device or resource busy" })', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/navigator-rs-0.3.1/src/lib.rs:313:23
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Traceback (most recent call last):
  File "/home/pi/navigator-lib/examples/python/rainbow.py", line 33, in <module>
    main()
  File "/home/pi/navigator-lib/examples/python/rainbow.py", line 21, in main
    navigator.init()
pyo3_runtime.PanicException: Error: Error during CS2 export: Io(Os { code: 16, kind: ResourceBusy, message: "Device or resource busy" })

I would like to use just the board as a pi-hat with as little overhead as possible - I do not want containers running, BlueOS running, and I would like for it to boot up reliably without any unpredictable behavior. Once more, the only difference was before and after I deleted the docker containers locally and rebooted.

2

Hi @rturrisi,

Have you executed apt-get upgrade on BlueOS?

I’m facing these issues with kernel 6.x.x. Could you please check the current kernel?
You can check running uname -a.
If it’s the case, you can recover access by executing a downgrade as follows:
Downgrade to BlueOS’s default kernel.

Another possibility is to use the Raspbian-Lite image directly:
Raspbian Lite + Navigator.
Then you’ll be able to code directly on raspbian without any container or automations, just need to run the overlay setup provided on instructions.

Regarding the kernel 6.x.x, a possible workaround is to change dtoverlay=spi1-3cs to dtoverlay=spi1-1cs. Somehow, the newer kernel isn’t allowing navigator-lib to use the pins assigned to SPI’s CSs.

2 Likes
3

Hello @RaulTrombin,

[Fixed]

Thanks for getting back to me - I saw one of your other responses about downgrading the kernel with sudo SKIP_WARNING=1 rpi-update 1340be4 and it did not work.

  • Output from $ uname -a
$ uname -a
Linux seascout-00 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux
  • I did try the Raspbian image recommended on the navigator-lib website (at the bottom), and it did not work after applying the overlays, so I reverted to using the original image and stripping things down.
  • Changing dtoverlay=spi1-3cs to dtoverlay=spi1-1cs , and then rebooting, fixed this issue, so thank you, since I would not have caught this. I have ran both the python and cpp example programs and they work when I run them with sudo.

Questions

  • Will I be unable to upgrade the system with the typical “sudo apt upgrade”, or does this introduce problems when using the navigator?
  • Do you have any idea why this change occurred after removing the containers and rebooting? In the time between I do not believe I updated/upgraded anything. I removed them and then rebooted to see whether or not any artifacts from docker would persist upon reboot.

Again, than, you - modifying that line in “/boot/config.txt” fixed the issue.

1 Like
4

Hey @rturrisi,

The default BlueOS kernel’s:

uname -a
Linux blueos 5.10.33-v7l+ #1415 SMP Fri Apr 30 15:50:57 BST 2021 armv7l GNU/Linux

With downgraded kernel, does it gets exactly the same error/behavior?

BlueOS do not execute upgrades on kernel, but can modify the overlays during it’s execution.
If you want to stop BlueOS containers, you can:

nano /etc/rc.local

and comment out blueos-bootstrap.

#docker start blueos-bootstrap

The kernel upgrades apparently just raise these issues with the CS pins, which breaks the device initialization. So if you use the ‘1cs’ workaround, it should work fine.

I will check the raspbian-lite images, the last I’ve used was the aarch64 one.

2 Likes