Nice, looks reasonably capable, hope it works well for you 
It should still auto-detect even in air, although it does sometimes take a little while to do so. Normally if the System page of the companion web-interface shows an active service of Ping360-... then PingViewer should also be able to detect it. If it doesnât show that service then youâve most likely got a connection problem, or need to power-cycle the system (ideally the companion computer and Ping360 should turn on at the same time, so that the Ping360 device is available when the RPi starts looking for it, and so that thereâs no risk of a previous dropped connection being maintained by the Ping360 at the cost of refusing new connections).
When using it in the past I tended to have QGC (with controls and primary video stream) on half of the screen, and a vertical split between PingViewer and OBS (showing a secondary video stream) in the other half of the screen. Unfortunately QGC isnât particularly modification friendly (the code base is quite interconnected, and thereâs lamentably no support for external widgets that can just be displayed in the window). This topic might be of interest, but the software presented there isnât free.
It depends how itâs connected. Youâve mentioned youâre connecting it through the companion computer, so for that the companion computer will automatically detect and connect to the Ping device, then provide an interface to it over UDP at port 9090 which PingViewer picks up on. Iâm assuming the two Serial options are still there from you plugging the Ping360 directly into your computer, although Iâm not sure why theyâre still showing up as green.
There isnât such a diagram thatâs readily available, but the code is effectively treated as as a bunch of separate functionalities, which are run on startup is through .companion.rc, which is a bash script. Each functionality is run as a linux screen session, which is basically a persistent terminal that runs in its own thread, and can be reconnected to later. In companion those sessions are given meaningful names (just after the -S flag), and the currently active sessions are whatâs displayed as the âActive Servicesâ section of the web interfaceâs System page. If you create your own named screen sessions, they will also show up there.
You mentioned previously that your PICs communicate via I2C. You can use I2C with the Raspberry Pi, so you can make a Python script that communicates with I2C to your PIC, and then uses Pymavlink to send mavlink messages to the top side.
Mavlink uses generated APIs, of which thereâs one for Python (pymavlink), and one for C, and more for other languages. You shouldnât need to learn the protocol itself, but will instead need to be able to make a connection, and send the relevant mavlink messages. I suggested Pymavlink because itâs already installed on the companion computer, and because Python tends to make things easy to develop quickly (which is helped in this case by the ArduSub pymavlink examples and the guide/post I linked you to earlier). C should still work, itâs just harder and comes with likely little gain.
Depends on the system, and user preferences. QGroundControl allows specifying a desired data rate, and you can also turn different indicators on or off depending on what you want to see (/what you have access to) while operating.
As mentioned, the RPi can use I2C, you donât need to make a USB connection or send mavlink messages to it from your PIC, but to see the values in QGC youâll need to use the RPi to send mavlink messages that include your sensor data.
This would likely simplify things, but as youâve mentioned uses extra power to replace functionality you already have, which seems a shame. Power sense at at least estimates battery percentage, and from memory might provide a remaining time estimate, but I canât check right now unfortunately.
The Pixhawk 1 is actually past end of life, so isnât manufactured anymore and is generally only sold in existing kits that make use of it. Our engineers are hard at work making an alternative thatâs future proof and provides significant other benefits, but until thatâs available we can only really recommend that you try a pixhawk model thatâs known to work - unfortunately we havenât tested any extensively and canât support them as a result. From what I understand the Pixhawk 4 is the closest match, but ArduSub might not support some of its extra features that were introduced since the Pixhawk 1.
Programming the Pixhawk can be done through both QGroundControl (as in your photo) or the companion web-interface. If youâre not modifying ArduSub itâs generally as simple as clicking the update button. If you are building a custom version then you basically just upload your custom firmware once youâve built it.
These are the instructions for enabling QGC to auto-connecting to videos, and is unrelated to the Ping devices (which QGC knows nothing about).
Pixhawk still sends sensor readings without needing to be armed or to control anything, so that side of things shouldnât be an issue. Yes the gyro, accelerometer, and compass are built in. ArduSub is designed to communicate with the Bar30 over I2C (using the I2C port of a Pixhawk board), so yes, it auto-connects and sends its data.
If you did decide to get a Pixhawk, you may wish to get something like an I2C bus splitter and read in all your PIC data through I2C there instead of directly from the companion. To do that youâd need to create a modified build of ArduSub so that it can communicate with and understand your PICs, which I imagine wouldnât be any easier than using the companion computer to do the same, but it might mean that you wouldnât need to work with the mavlink side of things (Iâm not intimate with how ArduSub is set up). Thatâs unfortunately not very helpful if the Pixhawk is there specifically to replace the PIC and corresponding sensors.
From a google, TF Card is a MicroSD card, so youâd need to buy that separately. Those IMU sensors should still be there - I donât believe they can be detached.