@jonathankampia Just to respond to my own post here in case anyone else has the same question: It does work! We hooked up a VL53L0X rangefinder to the QUP3 i2c ports in the J19 connector and were able to start the driver with no issues by adding the start command to the voxl-px4.conf file. Interestingly, you have to modify both the EKF2_HGT_REF parameter and a specific rangefinder priority parameter that controls whether rangefinder sensor fusion is enabled at all times or just conditionally. If it's just enabled conditionally, the rangefinder data does not fuse into the EKF2 local position estimator.

@aashry Follow this link: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros. Catkin_ws -> src -> msg and you will find AiDetection.msg, which you can use to build a ros custom message package (ROS has a tutorial on it I believe). You can do that in whatever workspace you are working in in your docker container. Once that is built and you source devel/setup.bash, you should be able to echo the topic and if you want to subscribe to it in a node you will need to import the message header similarly to any other message type

I am trying to find the best solution for minimizing altitude drift during low altitude outdoor VIO navigation. I have read this documentation about VL53L1X rangefinders, but I really would prefer not having to set this up as it would require modifying our drones to accommodate the tracking & hires cameras specific to the kits that come with the M0173 board.

Is it possible to connect a VL53L1X rangefinder to port J19 and interact with the sensor through the px4 firmware? Looking through the voxl branched 1.14 firmware there seems to be drivers for the VL53L1X sensor. I know it's not possible to use voxl-rangefinder-server through J19 as the page I linked says, but I see no reason I can't use the port through px4 itself.

Also, would the process (if possible) simply be:

1. Connect the VL53L1X sensor
2. Assuming the sensor connects properly, modify EKF2_HGT_REF to prioritize rangefinder

Or are there any intermediate steps? I am not really sure if these drivers run automatically or if you have to enable them via certain parameters. For example, SENS_EN_VL53L1X, which should enable the driver on boot, is not visible by default.

Thanks!

@Gary-Holmgren Haha your way is a little more robust than mine. I just manually added the qshell start command to the extra commands section of the voxl-px4.conf file.

@Yoshimaru-Tanaka Hey idk if this will solve your problem but to setup my starling I used the parameters from (I believe) the indoor_vio.params file here. You just go to the parameters section of QGroundControl and click upload from file, then select that file - it will show you exactly which parameters are going to change. They are also helpful if you are flip flopping between flying indoors and outside.

Looking at the documentation it seems to not be possible (both would have to occupy the j7 camera group but the Boson+ adapter steals the entire thing). I was wondering if you guys could provide any ideas for a workaround (or if it's actually possible to connect the imx412 hires camera to the j6 group).

Thank you!

We need access to an apps proc i2c on the voxl 2 mini, which I can see are exposed on camera group J7. We also need to have a flir boson+ hooked up, which reading the documentation appears to only connect to group J7. Due to the nature of i2c (expandable as long as devices don't share an address) would it be possible to just make a custom interposer board that breaks out one of the i2c bus with the camera simultaneously hooked up?

We are looking to hook up a VectorNAV VN300 external INS and an MS5525DSO airspeed sensor to a VOXL 2 mini. The INS data needs to be sent to the FCU. Both sensors have drivers in px4 - however, I don't think the VectorNAV driver will function on the SLPI proc, so it can't be as simple as hooking it up to the GNSS uart & mag i2c pins in J19 (correct me if I'm wrong?).

I just wanted to ask if this configuration is at all possible, and what might need to be done on the apps proc to get it working. I understand there's an exposed uart port in J10 that I can probably use, but I'm worried about potential latency issues & not sure how the data should be piped over to the FCU.

Thank you!

@Beniamino-Pozzan I am still not 100% sure, it's more likely I will be commanding attitude / body rate which are already available. I just wanted to get a clear overview of what the information dds client / agent can give me access to in the modalai version of px4.

How do you know what types of control / input & output data are not directly supported in px4 voxl version, as you said?

Thanks for the help!

I have a question about the custom version of the microdds client running within voxl-px4. When I run px4's Micro-XRCE agent to connect to a client running in mainline px4, I get a long list of topics & telemetry info:

/fmu/in/actuator_servos
/fmu/in/arming_check_reply
/fmu/in/aux_global_position
/fmu/in/config_control_setpoints
/fmu/in/config_overrides_request
/fmu/in/distance_sensor
/fmu/in/goto_setpoint
/fmu/in/manual_control_input
/fmu/in/message_format_request
/fmu/in/mode_completed
/fmu/in/obstacle_distance
/fmu/in/offboard_control_mode
/fmu/in/onboard_computer_status
/fmu/in/register_ext_component_request
/fmu/in/sensor_optical_flow
/fmu/in/telemetry_status
/fmu/in/trajectory_setpoint
/fmu/in/unregister_ext_component
/fmu/in/vehicle_attitude_setpoint
/fmu/in/vehicle_command
/fmu/in/vehicle_command_mode_executor
/fmu/in/vehicle_mocap_odometry
/fmu/in/vehicle_rates_setpoint
/fmu/in/vehicle_thrust_setpoint
/fmu/in/vehicle_torque_setpoint
/fmu/in/vehicle_visual_odometry
/fmu/out/battery_status
/fmu/out/estimator_status_flags
/fmu/out/failsafe_flags
/fmu/out/manual_control_setpoint
/fmu/out/position_setpoint_triplet
/fmu/out/sensor_combined
/fmu/out/timesync_status
/fmu/out/vehicle_attitude
/fmu/out/vehicle_control_mode
/fmu/out/vehicle_global_position
/fmu/out/vehicle_gps_position
/fmu/out/vehicle_land_detected
/fmu/out/vehicle_local_position
/fmu/out/vehicle_odometry
/fmu/out/vehicle_status_v1

However, a lot of those topics seem to be omitted when you run voxl-microdds-agent on an actual VOXL2. I know you can configure which topics are shown by editing a json? file in the voxl-px4 package & recompiling it, but I remember reading somewhere on this forum that the custom branched px4 firmware version may not support/provide some of the data. Is this true?

I am working on a project that will involve a VOXL 2 and may need to do direct actuator control (a topic that is made available by the client in mainline PX4 but not modalai's custom branch), and am debating between using MAVROS and the DDS bridge. I may need access to other topics that are also not provided but I'm not sure yet. There seem to be a lot of advantages to going with the latter, but if it's going to be a major pain / impossible to modify in the way I need, I would like to know.

Thank you!

@Yoshimaru-Tanaka Hey idk if this will solve your problem but to setup my starling I used the parameters from (I believe) the indoor_vio.params file here. You just go to the parameters section of QGroundControl and click upload from file, then select that file - it will show you exactly which parameters are going to change. They are also helpful if you are flip flopping between flying indoors and outside.

@Eric-Katzfey Thank you! I'm assuming I just follow the build instructions here, right?

Hi, we need to use a garmin lidar-lite v3 with a VOXL 2 and need to add that driver into the build. The driver itself is included in the modalai branch, I guess it's just not built with the rest of the firmware? How do I add it to the build?

Thanks!

@Gary-Holmgren Haha your way is a little more robust than mine. I just manually added the qshell start command to the extra commands section of the voxl-px4.conf file.

@jonathankampia Just to respond to my own post here in case anyone else has the same question: It does work! We hooked up a VL53L0X rangefinder to the QUP3 i2c ports in the J19 connector and were able to start the driver with no issues by adding the start command to the voxl-px4.conf file. Interestingly, you have to modify both the EKF2_HGT_REF parameter and a specific rangefinder priority parameter that controls whether rangefinder sensor fusion is enabled at all times or just conditionally. If it's just enabled conditionally, the rangefinder data does not fuse into the EKF2 local position estimator.