@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.

Hi, what is the order of the pins for the i2c passthrough on the M0201 board? Assuming something like 5V - SCL - SDA - X - X - GND, but would just like to ask to make sure. I don't believe it's documented anywhere either

@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.

@Colby-Howell You can save camera data onboard using voxl-logger, but it will take up a lot of storage very quickly and the voxl2 has < 64gb so be careful with that. If you're not trying to save raw frames and are okay with compression & artifacts you can stream it to a ground computer with voxl-streamer and save it there

For connecting to the drone the easiest (especially cause you don't have a ground radio) is wifi, you can just connect your drone to a somewhat powerful router, set a static IP and ssh in.

For autonomous navigation, the best way in my opinion is to talk to voxl-px4 through the uxrce-dds bridge (implemented on the voxl2 as voxl-microdds-agent) https://docs.px4.io/main/en/middleware/uxrce_dds

@Colby-Howell You can save camera data onboard using voxl-logger, but it will take up a lot of storage very quickly and the voxl2 has < 64gb so be careful with that. If you're not trying to save raw frames and are okay with compression & artifacts you can stream it to a ground computer with voxl-streamer and save it there

For connecting to the drone the easiest (especially cause you don't have a ground radio) is wifi, you can just connect your drone to a somewhat powerful router, set a static IP and ssh in.

For autonomous navigation, the best way in my opinion is to talk to voxl-px4 through the uxrce-dds bridge (implemented on the voxl2 as voxl-microdds-agent) https://docs.px4.io/main/en/middleware/uxrce_dds

@Alex-Kushleyev Hey thanks for the quick reply,

It's kind of hard to explain but eventually this system will be flown, and I'll need pretty extensive control over what's happening on the px4 side so I'm kind of using this as an exercise to understand how things work. Also trying to keep the hardware consistent with what will fly.

I do want to run voxl-px4 so I can pipe data into EKF2 and see how it responds under certain conditions. Right now we have a standard voxl2 with the ethernet expansion board, and are using the J9 uart for connecting an external sensor, and the J11 superspeed USB for datalogging. Unfortunately I believe this leaves us with no apps proc uarts available, so interacting with it on the SLPI side is the only option.

I'll mess around with other VehicleCommand messages and see if I can get something to show up on the px4 side

@Alex-Kushleyev

• I am not using a modalai ESC. I am directly connecting channel 5 of J1 on the m0065 board to the PWM pin of the servo, and providing power externally. Right now the system is not being flown (it's more of a sensor package) so channels 1-4 are unused, but I tried every method I tried with channel 5 on channel 1 and they didn't work.

• I am able to actuate the servo on channel 5 with the QGC slider. With the command 'listener vehicle_command' in the px4 shell, I can see that the slider is sending MAV_CMD_ACTUATOR_TEST. However my commands (also sent to vehicle_command over the microdds bridge) do not seem to be interpreted.

• That is not a viable option, I need to communicate with the VOXL2 over an existing long-range network (similar to doodle labs). I could add the uOrb inputRc message to the voxl-px4 microdds client and try to spoof an RC pwm, but I'm hesitant to believe that will work with everything I've tried already.

I think the problem is the particular VehicleCommand msg I'm sending not making it through as you said. It's just strange though because I've had no issue arming or mode switching vehicles through the same msg on other voxl2 platforms

I'll take it there's no direct way to just write a constant PWM output to the voxl2_io board on the voxl2?

Thanks!

Hi, I've been having trouble trying to set up a pitch gimbal on a voxl2 via channel 5 of the m0065 board. The control is pretty simple, I just need to update the pitch of the gimbal to a static angle once or twice during a mission. I could drive it with a tiny mcu over usb but I kind of want to avoid that as the m0065 board is already necessary in our build

Some things I already tried:

• Adding some uOrb control messages to the voxl-px4 build (ActuatorMotors, ActuatorServos, GimbalCommand), and sending the corresponding messages to command pitch on channel 5 via microdds bridge

• Sending a VehicleCommand message with the supposedly correct params isn't even received on the px4 side (output of a listener echo in the mavlink console). This is really weird as I've used vehicle_command to arm / mode switch vehicles before

• The failure of those methods made me think it's something to do with the gimbal module getting left out of the voxl-px4 SLPI build, so I added it and retried the GimbalCommand and VehicleCommand messages, but to no avail

I have yet to try mavsdk but the failure of all that other stuff doesn't make me too hopeful it's going to work.

Is there a way to directly command a pwm with the voxl2_io module (Either on the slpi side or apps side)? Like "voxl2_io set -c <channel> -v <value>" or something

Thank you!

I'm in the process of building an apps proc mpa server sensor package for the vectornav vn300 external INS, and looking through the currently supported interfaces in libmodal pipe there appears to be no GNSS interface. It seems pretty simple to add a header, but taking the imu_data_t interface as an example I can't find where the pipe_validate_imu_data_t() function is defined, so it's unclear to me how it actually validates a pipe read, and how I would do it for a gnss data stream with different fields.

Maybe I'm just not looking in the right place? Please let me know where I can find an example of pipe data validation, and also of any other requirements when adding an interface to libmodal pipe.

Thanks!

@Alex-Kushleyev Gotcha, thanks!

Trying to get a vectornav VN300 external INS to work with our voxl2 setup. It has a sensor module in px4 firmware: https://docs.px4.io/main/en/sensor/vectornav.

Looking at the voxl-px4-start script here: https://github.com/modalai/px4-firmware/blob/main/boards/modalai/voxl2/target/voxl-px4-start it seems like you should be able to start a module / driver and target QUP6 this way:

if [ "$GPS" != "NONE" ]; then
    # On M0052 the GPS driver runs on the apps processor
    if [ $PLATFORM = "M0052" ]; then
        gps start -d /dev/ttyHS2
    # On M0054 and M0104 the GPS driver runs on SLPI DSP
    else
        qshell gps start -d 6
    fi
fi

So I assumed I could just modify voxl-px4 to include the vectornav sensor module, reload the package and add the appropriate start command

qshell vectornav start -d 6

Even with the firmware properly rebuilt & deployed and the vectornav module visible as a target on the px4 side, it fails to run from the VOXL2 side:

starling-px4-dev-kit (D0011):/usr/bin$ px4-qshell vectornav start -d 6
INFO  [qshell] Send cmd: 'vectornav start -d 6'
INFO  [qshell] cmd returned with: 1
INFO  [qshell] qshell return value timestamp: 1453125775, local time: 1453127808
ERROR [qshell] Command failed

Also, the output isn't really verbose so I can't see why the command failed. I've tried running it on the px4 side (in the mavlink console in QGroundControl), and the verbose error I get is that '6' is not a proper serial device. How can I start the driver and properly target QUP6? Also, how can I get more verbose output when running px4-qshell commands on the VOXL2 side?

Right now I'm using this bash script to set a static ip:

ETHERNET_IP=192.168.1.100
eth_dongle_interface=eth0

while true
do  
   if [[ -e "/sys/class/net/$eth_dongle_interface" ]]; then
         eth_dongle_ip=$(ip -4 addr show $eth_dongle_interface | grep -oP '(?<=inet\s)\d+(\.\d+){3}' | head -1)
   else
         eth_dongle_ip=""
   fi

   if [[ "$eth_dongle_ip" != *"$ETHERNET_IP"* &&  -e "/sys/class/net/$eth_dongle_interface" ]]; then
                echo "setting IP address to: $ETHERNET_IP"
                ip addr flush dev $eth_dongle_interface
                sleep 1
                ip link set dev $eth_dongle_interface up
                sleep 1
                ip addr add $ETHERNET_IP/255.255.255.0 dev $eth_dongle_interface
    fi
    sleep 1
done

It's pretty reliable, but we have seen it fail and the default 169.254.4.1 address takes over the eth0 interface. I believe this the Qualcomm DHCP manager? Is there any way to edit the network manager directly? We have tried deleting it but it seems to regenerate on boot.

Hi, I am trying to hook up an external FCU for a sensors test over uart to the standard m0054 VOXL2 (with ethernet hub addon M0062). Looking at the pinouts, I'm seeing references to a lot of QUP uart ports - are any of those accessible to the applications processor (i.e. at /dev/ttyXX)? If so, how will I know which physical port corresponds to which uart?

@Vinny Powering the drive externally didn't change anything, seems like it's a data rate issue.

I am having super weird IO problems with the ssd, like sometimes the partition doesn't show up when running 'lsblk' so I can't mount it. Data rate tests using dd are not consistent at all, and sometimes mid write the drive will become read only and dd will hang infinitely, following which I have to reformat the drive. I had the same partition issues trying a microsd card in the ethernet hub addon microsd slot - the sdcard showed up as mmcblk0 with no partitions available to mount.

I've had much more consistent performance using a microsd + reader over usb3. This post was helpful for setting some standards: https://forum.modalai.com/topic/3855/question-about-the-usb3-uart-add-on-versus-the-voxl-2-ethernet-and-usb-hub-add-on/2. With my setup (UHS-1 microssd + reader) I'm getting about 50MBps write to ext4 and ~75MBps write to exFAT formatted microsd card.

However, those tests with dd seem to be really unreliable and not representative of the rate I'll get using voxl-logger. I'm guessing I need a benchmark data rate of much higher than what we actually need (93MBps) in order to consistently write frames.