@Moderator Apologies for the lack of clarity. It's mentioned in an earlier version of the SDK (pre SDK 0.9.5), here in fact: https://docs.modalai.com/voxl-camera-server-0_9/ (search for "flip"). I added "flip" to the .conf file, but it didn't have an effect it seems. I haven't checked out 1.0 or 1.1 yet (I'm holding off on going past 0.9.5 until VOXL IO board is supported) but I'm hoping such basic image manipulation is available in those versions as well.

Hello! Is the VOXL2 flight deck interchangeable with the VOXL1 flight deck? That is, will the VOXL2 flight decks fit on the m500 frame without modification? Thanks!

@Alex-Kushleyev Hi Alex, Thanks! Yes, that was exactly the problem. I switched to the dev branch using 'voxl-configure-pkg-config', downloaded the latest voxl-portal ('apt get update && apt install voxl-portal'), and then switched back to the 1.4.0 pkg. Voxl-Portal works just fine now.

Hello, Bottom Line: I was unable to access cameras in voxl-portal after a fresh flashing of SDK 1.4.0 on a new Starling 2 Max V2; required for intrinsics calibration. Further digging showed errors related to the "server disconnecting" regularly appear with 'voxl-inspect-cameras -a'. Errors are:
"
ERROR in pipe_client_open opening request pipe: No such device or address
Most likely the server stopped without cleaning up
Client is cleaning up pipes for the server
ERROR in pipe_client_open opening request pipe: No such device or address
Most likely the server stopped without cleaning up
Client is cleaning up pipes for the server
<similar lines...>
"
SKU setting is:
family code: MRB-D0012 (starling-2-max)
compute board: 4 (voxl2)
hw version: 2
cam config: 29
modem config: 11 (Microhard v2, pMDDL2450(M0048))
tx config: 9 (ghost)
extras config: 0 (none)
SKU: MRB-D0012-4-V2-C29-T9-M11-X0

I note that using 'voxl-inspect-cam tracking_down' or other camera requests appear to work; I went up to listing 4 cameras at once. Could it be that the bus is saturated with too many cameras?

Are there other diagnostics that can be run to nail down what's going on? The physical configuration is unchanged from a stock vehicle.

@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

Hello, I see on the downloads section there are CAD files for several VOXL1-era PCBs, etc. Any chance you might consider making the VOXL2 flight deck .stl 3D printable files available? I'm kludging together a drone from ModalAI boards and parts and 3D printing the same VOXL2 flight deck parts would save a little design time. Thanks!

-Joe

@Eric-Katzfey I have not, but I can do that.

Re: VOXL2 mavlink topic streaming modifications

@Eric-Katzfey Hi Eric, would you mind advising on the current location for the startup script with the newer SDK 1.1.X setup? I believe the above topic applies to the SDK 0.9.5.

Thanks!

-Joe

Hello, I've noticed with PX4 1.14 that sending TrajectorySetpoint messages causes "jittery", nearly unstable, behavior unless vehicle is in "offboard" mode. For background, consider there are two flight modes set to choose from: "Position" and "Offboard"; a custom modification of the px4_ros_com example has been created that removes programmatic arming and programmatic flight mode changes and only continually publishes TrajectorySetpoint and OffboardControlMode messages at 20 Hz. The "offboard_mode" field in voxl-vision-hub.conf has been set to "off" so there shouldn't be a conflict there.

Expected behavior: PX4 stack should ignore TrajectorySetpoint and OffboardControlMode messages while vehicle flight mode is in "position" control, then should start following the trajectory setpoints according to the offboardcontrolmode settings when flipped into "offboard"mode.

Observed behavior: When sending TrajectorySetpoint messages in "position" mode, vehicle becomes extremely jittery with reduced controllability, as if it's trying to implement these setpoints. Sending OffboardControlMode messages does NOT affect behavior whether in "position" or "offboard" mode and hence can be used as the "offboard heartbeat signal" to keep offboard mode active. Sending TrajectorySetpoint messages in offboard mode works as expected. This has been observed using both the VOXL2+VOXL2IO+m500 frame as well as the Starling.

Question: Are we to expect in PX4 1.14 that this behavior is correct and we need to only send TrajectorySetpoint messages as soon as offboard mode is switched on or is this a bug in the firmware?

Thanks!

-Joe

@Eric-Katzfey Thanks for your help. I've confirmed that I was able to use J19 with the "RC=M0065_SBUS" option successfully. Hence, if no VOXL_ESC, one should use J18 for the VOXL2 IO board and if there IS a VOXL_ESC board, one should use the J19 for the VOXL2 IO board. The firmware seems to be "smart" enough to figure out as long as /etc/modalai/voxl-px4.conf is set as you suggested.

-Joe

@Eric-Katzfey Thanks Eric, Apologies, I needed to also indicate that I've got a VOXL2 IO board in this as well. Hence, I should ask, "Can J19 be used as a UART that goes to a VOXL2 IO board?"

-Joe

Hello, I'm trying to retrofit an early Sentinel design with an S.BUS receiver. The Sentinel has been upgraded to the most recent SDK 1.1.3. In this model, J18 is taken by the VOXL ESC board. A Spektrum receiver cable is split between J10 and J19 and going to the older Sentinel Spektrum bind board. If I could utilize the J19 as an S.BUS input, that might be the way to go? I'm not sure how to ensure the PX4 stack is looking for the RC S.BUS signal on J19 rather than J18 like usual. Any thoughts appreciated, thanks!

-Joe