@Aidan-Dempster You are correct on the mavlink console. This is not currently supported on VOXL2. You would have to log into the VOXL2 directly using adb (on the benchtop) or ssh (while flying) in order to interact directly with px4 shell.
Hi @Abdullah01
I can try to help you with the hardware side.
The FrSky RC receivers are a little confusing.
They have several SBUS denoted ports on the module.
This diagram shows which pins are utilized for our setup with the Voxl2 I/O board: https://docs.modalai.com/cable-datasheets/#mcbl-00065
Apologies we do not have the MCBL-00065 for sale yet (it had an error we have yet to address), but if you are handy with a set of tweezers, and are willing to try these steps here to make your own, it's not that hard to pin the side needed for Voxl2 I/O with a 4-pin JST GH shroud. https://docs.modalai.com/cable-userguides/
Jun 23 18:12:02 m0054 dnsmasq[3420]: failed to create listening socket for port 53: Address already in use
Jun 23 18:12:02 m0054 dnsmasq[3420]: FAILED to start up
Jun 23 18:12:02 m0054 systemd[1]: dnsmasq.service: Control process exited, code=exited status=2
Jun 23 18:12:02 m0054 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Jun 23 18:12:02 m0054 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.
says the following -
Software Features
PX4, ROS 1 / 2, Ubuntu 18.04, Open CV, MAVROS, MAVSDK
Open Source Linux kernel, cross-compilers
Docker build environment for CPU, GPU (OpenCL) and DSP (Hexagon SDK) heterogeneous computer vision and deep learning processing
@tom Yes, thanks! That is a good idea. I will do that.
I was looking at the release page of the system image and saw this line with 1.5.3 internal release:
HLOS
Added service file that changes SLPI restart level to avoid board crash when SLPI crashes
What is SLPI and could you describe a little bit more what kind of issues you saw when SLPI crashed?
I also sometimes saw px4io io_reg_get(4,0,15): data error -5 in the logging so maybe that could be related?
@I_Dwyer I have been down the rabbit hole here. It seems that qualcomm has not used any of the standard network management tools like Netplan. They use a hybrid of Systemd-Networkd and a wide range of complex scripts to manage all the interfaces. None of the scripts are standard. I am at the point of possibly stripping all of that out, and replacing it with either Ifupdown or Netplan and creating a firmware build that works better for our use case. There are a number of problems with the older Qualcomm network scripts, such as the DHCP management you are encountering. For example I have noticed that if WWAN0 has an IP, then WLAN0 will NOT get an IP from the DHCP server, even thought the wifi is connected to the local AP! To get around that I added an ifconfig statement issuing a static IP to wlan0 every time the drone boots, but this is a hacky solution.
Would like to see ModalAI replace the entire Network Management stack with something better and easier to maintain.