@Eric-Katzfey That works, thanks!

@K-Stute here is the directory in voxl-dev px4-firmware: https://github.com/modalai/px4-firmware/blob/voxl-dev/src/modules/microdds_client/dds_topics.yaml

Thank you - I was able to make it work for one camera with the following changes. etc/modalai/voxl-camera-server.conf changed "camera_id_second": to -1 to get just one camera, changed "en_preview": to false, Added:"en_small_video": true, "small_video_width": 1280, "small_video_height": 800, restart voxl-camera-server service etc/modalai/voxl-streamer.conf "input-pipe": "stereo_small_encoded" etc/modalai/voxl-mavcam-manager.conf "video_record_pipe_name": "stereo_small_encoded",

@jacob-yaacubov , FYI, this fix will be in 1.2.0 release which is in testing now

@wilkinsaf Yeah you're absolutely right! Happy to help you out if you have any more questions about that process. -Thomas

Also, if you are using very old SDK on VOXL2, the uart bridge may not be working 100% properly. When in doubt, the best thing to do is to connect to the ESC using a serial to usb adapter going directly to a Linux PC (and run voxl-esc tools on the PC). do you have that available?

@AndriiHlyvko On VOXL 2, the snapshot pipe from voxl-camera-server will use the latest gps data and update the exif data of the jpg image with the latitude and longitude voxl-camera-server receives GPS data here voxl-mavlink-server publishes GPS data here You can use the voxl-inspect-gps tool to verify the GPS data is being published correctly

@AndriiHlyvko The issue is with dependencies. The emulator is built using the actual filesystem used on the VOXL platform so you get all of the correct dependencies. With voxl-cross it is sometimes very difficult to setup the dependencies properly.

@Rowan-Dempster, i looked through the changelog of our project (https://gitlab.com/voxl-public/voxl-sdk/third-party/voxl-eigen3/) and it does not look that there are any changes done to eigen3 itself, i think it is just a package we inherited from VOXL1, which did not use apt. If you are willing to try it, remove voxl-eigen3 package (which may temporarily break something - note which packages require it). We could potentially update whatever gets broken to be happy with either voxl-eigen3 or eigen3 installed using apt.

@jenyeom , i am not sure, can you please try setting cpu mode to performance: voxl-set-cpu-mode perf This will prevent cpu from sleeping excessively in low power mode. Perhaps the dt is so low that the cpu oversleeps and does not handle all the imu messages.

@Eric-Katzfey This is working great, been playing around with it for the last week or so. The next thing I'll be working on will be the order in which the cameras streams are displayed to QGC. It seems right now on boot the initial stream that comes up in randomized over the various camera being fed into QGC.

@tyorb It would be a massive undertaking and we would only be able to provide very minimal support. I'd definitely recommend against it.

@Zachary-Lowell-0 Thanks Zach, this does answer. I have been used to ROS1/MAVROS where sending position targets was completely ignored unless in offboard mode so my node would typically blast setpoint_raw messages whether in offboard or not (in part to keep the option of switching to 'offboard' mode "alive"). I will proceed from now on in ROS2/MicroXRCE assuming I should constantly send offboard control mode messages, but send traj setpoints only when offboard mode is confirmed. I appreciate the clarification on why this is. -Joe

@Jeffrey-Mao I am assuming you are asking about VOXL2 with ov7251 stereo in combo mode (using a single 4-lane camera port) Please check in /usr/lib/camera, you should see two com.qti.sensormodule.ov7251_combo* files. you should remove them and replace them with ones from /usr/share/modalai/chi-cdk/ov7251-combo-flip, making sure you copy the files with the same camera slot index (the number at the end before .bin). Then simply restart voxl-camera-server and the cameras should be rotated 180 (this happens by reversing the direction the images are read from the camera itself, not rotated in software)

@Moderator Thank you

@michi Yeah, I'd be curious to know what your results are like using a custom YOLOv5 model. If things are still slow, the issue might be in your quantization process. However if it speeds up, it may just be that the model architecture is too big. I have it on my to-do list at some point in the next few weeks to add YOLOv8 to our list of default models so when/if I do that I'll keep you posted with the results of that as well. Keep me posted on how I can be of assistance! Thomas Patton