Thanks a lot! I'll look into that. Thanks again

Hi Steve,
Thank you so much for these links. They will help me.

@modaltb said in Get PX4 not to flag GPS error when none is connected/using VIO:

Hi @hmlow ,

Thanks for the feedback, which version of PX4 are you running? Trying to track this down.

Thanks!

Hi

Im using ModalAI 1.11.3-0.2.3.

As a workaround i disabled the overlaid message in QGC by rebuilding a custom version of QGC.

This is also something that we've done extensive testing with. In short, yawing can actually be one of the most reliable motions if the field of view of the camera is set up correctly. Our standard tracking sensor has a 166° diagonal/100° vertical field of view. We mount the camera at 45° down from the horizon, so the bottom of the image will be ~5° past straight down, and the corners of the frame will stretch farther into the backwards left/right swaths of area. The result of this is that yawing in place actually maintains a lot of features directly below the drone, where the bottom 10° arc will always be in view and the farther up features will stay in view for a long time. If there are a reasonable amount of features in the bottom say 20-25° below the drone it'll maintain a very robust position and yaw estimate.

However, the behavior that you're probably thinking of can also happen. We've experimented on some of our other cameras that have a wide (though not as wide as the fisheye (84° vertical)) field of view also mounted at 45° below level. The result here is that the bottom of the frame ends a couple of degrees above straight down, and so that super reliable zone of features always in view doesn't exist, and the pretty reliable zone is also much smaller. The yawing in this situation can be very unreliable, and the filter can often blow up rather quickly if not also moving during the yaw. Similarly, yawing in place with little to no features directly below you will show the same behavior, and the feature tracker will struggle to track the rapidly moving horizon-level features and can blow up.

We've also done tests with the fisheye sensor mounted straight forward which resulted in the same behavior as in the second paragraph, where the lack of downward features led to us being unable to yaw in place.

TL;DR: Yawing in place without translation as well needs to see features very close to the axis of rotation or else the filter will blow up. This can be achieved with a combination of wide fields of view and aiming the sensor not level with the horizon.

Thanks @Eloi for your suggestions.
We are actively working to improve our cables, cable design methods, customer communication on cables, and our image sensor flexes. It's a task we take seriously and want to improve upon.

However, it is doubtful we can use ZIF style connectors for our platforms or be able to use COTS ZIF/FFC ribbon cables. They are the least vibe/shock tolerant of any connector class which require a lot of mechanical backing support to stay latched and engaged (and it must be movable to allow insertion and removal), thus adding weight, complexity, and size to the drone.
All of our image sensor flexes are also high-tech flex circuit assemblies, with power routing, specific ground plane control, EMI shielding, and high-speed impedance control, neither of which can be obtained from COTS FFC parts.
Hope that partly explains why we do not normally use FFC/ZIF parts.

Hi Troi, thank you for the feedback. We will take this into account

@Samer-Jaradat What kind of a drone do you have?

@brinkap unfortunately, there is no CAN capability on VOXL 2. You would need to have an adapter PCB that supports CAN connects to one of the available interfaces, and then write a Linux driver that enumerates as can0

@tcg6000 It is possible, of course, for us to build without connectors, but it is expensive to do a custom build. There would be an MOQ of 200 units to get to similar pricing as found on our webpage.

since voxl-streamer can provide RTSP streaming from VOXL2, ffmpeg can be used on the host machine for recording outside of QGC.

You can find some helpful information by searching ffpmeg save rtsp stream to a file . for example : https://medium.com/@tom.humph/saving-rtsp-camera-streams-with-ffmpeg-baab7e80d767

@cfirth said in Update SDK docs on installing ROS2 on VOXL2:

they

Thanks for the comment @cfirth - this has been updated in the gitlab and is waiting to be merged for the document update!

@Aaky ,

Please check the following thread for more information: https://forum.modalai.com/topic/3459/masking-qvio/

My suggestion:

download the test mask from here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-qvio-server/-/blob/master/misc/mask_example_160x120.pgm . which has top half of image black (0), and bottom half white (255). values of 0 is where new features will be allowed to be detected You can use gimp, to modify the mask and before saving you can threshold it so that the values are all 0 and 255 (nothing in between, just in case). export from gimp as pgm (raw) do a test with the original mask example, make sure no features are picked up in the bottom image. This is the baseline test then try your new mask, you can also overlay the mask on top of the QVIO overlay, just like the other user did for checking.

Also please note (from the other thread) to pay attention to the fact that QVIO mask path is relative to where qvio server starts. So if you start it as a service, it's working directory will be / but if you run it manually, the working directory will be your current directory in the terminal - the other thread explains that issue.

Alex

@Eric-Katzfey Thank you for the clarification!

@blue
OK thanks for the beta feedback.
We will keep that in mind. I'm sure what we did was to mimic an existing OTS product at first, and that used a backplate. I'll get with our production team to ensure we have a backplate in future kits for this version.
Thanks!

@Zachary-Lowell-0 Perfect, thanks! I'll try it when I get some time next week.

@JP-Drone said in Support Photo/Video Capture via RC Switch:

MAV_CMD_IMAGE_START_CAPTURE

How are you handling the mavlink camera protocol exchange within voxl-px4? I know that there is the ability to forward commands to the GCS if using mission commands (but not manually flipping an RC switch).

Alternatively when using a joystick you can map a button to image capture: https://docs.px4.io/v1.15/en/camera/mavlink_v2_camera.html#manual-controllers

Currently the mavcam manager fully implements the camera protocol to send the ack for the incoming mavlink commands. It also handles the capture and video stream status (satisfies the mavlink camera protocol).

My only issue with implementing this is that the upstream voxl-px4 will not be camera protocol compliant and thus we are bypassing the entire protocol just to get camera image capture from the autopilot instead of the GCS (which also implements the same camera protocol). If you have a way to implement the protocol (even a stripped down version of it) please send a link so I can look at the code.

@Eric-Katzfey Yes. This is regarding the Starling 2 Max GPS-denied Development Drone.