@DillonAllen Without WiFi, the only way you'll be able to debug VOXL related things is via. ADB so I would follow this guide: https://docs.modalai.com/setup-adb/ in order to setup ADB on your host computer.
Like Chad said, this depends on many factors. I just wanted to add a bit more details. TOF is not pushing nearly as much data as, say, 4K30 camera, so it is using CSI speeds vs 4K camera. There is a chance it may work with double extender. You should try it!
Regarding Raspberry pi (and corresponding discussions), I have personally tried a few of those cables and found that some long cables (~50cm) with raspberry pi and pi camera and saw that long cables result in pixel noise in the image. But it looks kind of strange, since the raspberry pi ISP tries to de-noise the noise and image ends up being kind of noisy and more blurry at the same time and the colors are off. I don't remember exactly what the picture looks like, but the failure mode of long cables may not always be "no image" (no image in the worst case).
On VOXL, I have seen some bad cables (occasionally) and I was seeing frame sync issues (image rolling up/down) or sometimes no image at all.
I don't think you can damage the camera or VOXL by using too long of a cable, but at some length you will get corruptions and that length depends on the camera and its operating mode.
Although we aren't VPN experts (yet), this is something I've seen myself. There are parameters that can be configured by VPN server/clients that may affect bandwidth (e.g. MTU).
There are various types of client/servers out there so it varies how these could be setup.
Also, depending on where the VPN server is located, you might be going to a server far away, and depending on the VPN server quality, they may or may be sharing resources with you.
The segfault error is an error that occurs when closing camera server, not while it's running. This is happening immediately after running camera server because systemctl detected the segfault and tried to rerun camera server (thus closing yours since only one instance of camera server can be running at a time). If you want to run camera server manually, make sure to run systemctl stop(or kill) voxl-camera-server first to make sure there's no background conflict.
The generic hal3 error codes can be found here, the -19 is a qualcomm specific one that we've found to be equivalent to ERROR_DEVICE (though we have been unable to find its proper definition), and has indicated that there is an error with the device and it will be unable to process any more requests.
@Vinny no worries, I ended up just going to industrial hardware in SD and trying out a bunch of machine screws until I got one that fit nicely, cant recall the exact size. Here are the dimensions for mounting the M0026 in a part I made. Figured I would post it if it helps someone else out since I personally couldn't find a STEP file for this part. Dimensions are in mm, the camera is ~24.1mm from base to the tip of the lens from my caliper measurements.
A few things to check..
make sure the voxl-camera-server is not running, since it cannot be used concurrently with voxl-rtsp (you can check what services are enabled using voxl-inspect-services
when connecting via VLC, you should not use 0.0.0.0 address. 0.0.0.0 is an invalid address
it is strange that voxl-rtsp reports that it's listening on 0.0.0.0. It looks like you have VOXL in AP mode (based on the IP address). Run ifconfig and see if it shows anything strange. The fact that you are able to ssh into VOXL using 192.168.8.1 means wifi AP is working fine..
just in case, try using it's actual ip address in the rtsp:// field - it looks like you already tried it in VLC?
if you are able, please try compiling and using the latest version of voxl-rtsp here : https://gitlab.com/voxl-public/utilities/voxl-rtsp/-/tree/dev - it will also print some stats after you exit, just making sure the camera frames are actually coming in. There is a script build_in_docker.sh that makes it easier to compile voxl-rtsp, as long as you already have the voxl-emulator docker image
I just updated libmodal_pipe to 2.0.8 with a fix to cleanup the trailing characters from echoing a pipe name to the request pipe. Now you can run modal-hello-server in one window and see the output in another:
yocto:/run/mpa/hello$ echo "test" > request && cat test
Let me know if this is along the right path. I have no immediate intention for making a python library.
Can you please be more specific with your question?
Are you just referring to hardware connections or are you asking for software device detection?
I'm not familiar with the Jetson systems, but from what I can tell, purely from a hardware viewpoint, there are a bunch of UARTs and I2C ports exposed on a Nano 40-pin header that can be connected to Voxl directly since Voxl is also at 3.3V logic levels for our external interfaces.
Now, how you expect to use the combined system is a more complicated SW systems question, so this is why I asked if you can elaborate more.
How do you want the Voxl to interact with the Jetson? This will tell us if the bandwidth of the common interfaces (I2C, UART, SPI) are even suitable for your application(s). If a USB interface is more suited to your application for higher throughput, then it can get a bit harder. The Nano appears to have a variety of USB ports, as do our systems, but you'd need to understand who is the USB Host and USB Client/Device and connect them accordingly.
Do you have a GPS/Mag plugged in? If not please try plugging in a GPS/Mag and set the PX4 parameter SYS_HAS_MAG to 1. There is a PX4 bug that prevents VIO-only operation if a magnetometer is missing, even if the magnetometer is not in use.
We've been trying to get the bugfix approved and merged into PX4 master for over a year now but it seems to be a lost cause. For now our own branch of PX4 has the bugfix along with some custom tools for our ESCs. If your system starts working again with the magnetometer then we know somehow a standard PX4 image got onto your flight core instead of one of our own.