Hi again, From investigating the voxl-vision-hub code with added prints for debug, I see that the setpoint SETPOINT_POSITION_MAGIC_NUMBER is sent to mavlink-server from two functions - (1) _send_current_position() sending the current position, and type-mask ignoring vx,vy,vz,ax,ay,az,yaw_rate // fetch latest position and attitude from px4 itself so the setpoint // we are about to send is a close as possible to where we currently are (2) execute_setpoint_position_command() sending the setpoint as recieved from voxl-planner The implemented behaviour of (1) suits the situation of position+yaw command. However for vx+vy+z+yaw_rate command I think something is missing. Any help will be appreciated. Thank you, Meytal

@James-Strawson hmmm, by any chance are you failing to link against symbols from libgmb.so? That is a new library dependency of libmodal_pipe. Most of our packages use the following linker flags to avoid recursive linking, I think this would be a better solution than specifying the libmodal_pipe version in install_build_deps.sh set(CMAKE_C_FLAGS "-Wl,--unresolved-symbols=ignore-in-shared-libs ${CMAKE_C_FLAGS}") set(CMAKE_CXX_FLAGS "-Wl,--unresolved-symbols=ignore-in-shared-libs ${CMAKE_CXX_FLAGS}")

@KnightHawk06 That is the source, yes.

@Jskim Finally, I tried a test. I tried changing the video player and the Streamer died immediately. The conclusion is that the Streamer died even when it was in the foreground. [image: 1744965805106-%ED%94%8C%EB%A0%88%EC%9D%B4%EC%96%B4-%EB%B3%80%EA%B2%BD%ED%95%98%EB%A9%B4-%EB%B0%94%EB%A1%9C-%EC%A3%BD%EC%9D%8C.jpg] Thanks, JS, Kim

@Rowan-Dempster No problem! Kind of primitive but effective

@teddy-zaremba Temporary fix by just installing missing package: apt-get install -y libwayland-server0:arm64 libwayland-dev:arm64 Also have to install this for voxl-portal apt-get install -y libglib2.0-0:arm64

@Samuel-Lehman In this case you are setting up the voxl-streamer outputs. voxl-mavcam-manager simply informs QGC about which outputs are available to it. You don't need to do anything manually. Just set up a systemd service file for each instance of voxl-streamer. (for example: /etc/systemd/system/voxl-streamer.service)

@brahim Thanks for this advice! I'm working on Windows with WSL and it is impossible for me to build the docker image by following the instructions on the voxl-docker-mavsdk README. I'm still unsure why the image build on the VOXL and not on my WSL Ubuntu, but at least I got it to work.

@mkriesel , there is no way to turn off power to just the IMU. It seems your IMU is "broken" and it may not be safe to use it for any application that might involve moving parts You can try to restart voxl-imu-server, which will perform a complete re-init of the sensor, but this will probably not fix the actual issue even if it helps with temporarily recovering the sensor from the latched state. Alex

@Alex-Kushleyev I understand. Thanks for the quick reply. Thanks, JS, Kim

@MikeD Docker is not installed by default, but you can follow the ubuntu install instructions on VOXL2:https://docs.docker.com/engine/install/ubuntu/

@griffin , this seems like an network issue. So please try the following: open a terminal and just run the following command to "inspect" the hires stream so that it is always going and you can check if it's running any time : voxl-inspect-cam hires_down_small_encoded start a continuous ping test from your host that is trying to receive the video feed keep testing the video feed until you see the issue occur and check if ping is dropping out and double check voxl-inspect-cam output to make sure the data is flowing. What i expect is the output of voxl-inspect-cam should be continuously updating and you may see ping having trouble. Please let me know what you observe. Regarding the voxl2 heating up, i will check with the team. open-vins-server is running (VIO) and it has been recently updated to use GPU for feature detection, so a slight increase in voxl2 temperature may be possible. Alex

Hi @m1baldwin , are you using VOXL1 and VOXL2 ?

@Moderator Have you gone through this document here: https://docs.modalai.com/qgc-wifi/ ?

Hi @LucaVertiq , this is cool stuff. I am curious if you were able to do any direct comparisons of qvio performance using unfiltered vs low pass (rpm-based) vs notch (rpm based)? In order to replicate the same conditions for each test, this would have to be done using mpa playback after collecting mpa logs of just imu data and images. since the rpm data is not coming from mpa, it cannot be logged / played back using our logger. However, one idea is to process the IMU data logs using RPM logs using a separate script and then run the playback + qvio to generate new results. The IMU data processing can have different options like the rpm-based notch filter and it would obviously also need to have a px4 log that contains the ESC status. This also leads to a question, whether the IMU data should be filtered in the imu server or the application that uses the imu, since the requirements for the IMU data may differ for different applications, so it may be best to leave the IMU server publishing the original data. But also, there could be a separate output pipe from the imu sever with the notch filtered imu data.. Anyway, just wanted to check if you happened to get any quantitative results from your testing that show how the filtering helps with QVIO performance. My understanding from working with QVIO in the past was that the best thing to do was to feed unfiltered imu data into QVIO and let it integrate the noisy data. low pass filtering the IMU data too much would actually remove some of the actual components of motion that are important for motion tracking. So i am curious what exactly has improved in your case when you added notch filtering - is the drift vs distance improved or the number of VIO "blow-ups" has reduced? Lots of questions, but I am happy to discuss this further and see how we can improve performance of our VIO stack Alex

@LR I would recommend upgrading to the newly released SDK 1.4.1 from downloads.modalai.com Simply, download, untar, and run ./install.sh It'll retain any important calibration files and will re-configure the drone based off the SKU

@brahim after looking at this some more I think it is valid to have multiple streams per camera. I guess the use case would be to have a high res stream and a low res stream that's separate or something like that. However I think people would still like to setup multiple cameras. I haven't tried this yet, but I think it could also be valid to spawn a manager per camera, and then stagger the component ids for each app. I think this might also fix the threading issue since each application would initialize separate pipe reads and wouldn't be blocked by each other? @Eric-Katzfey I'm using a different mavlink GCS that's not QGC, so I need to make voxl-mavcam-manager conform to the standard.