Posts made by jon

Hi, in order to log a lot of different configurable data & cleanly parse the output, I wrote a python wrapper that calls voxl-logger as a subprocess and terminates it by sending a SIGINT (emulating user ctrl+c).

This issue only happens sometimes, maybe 30% of the time or something. I don't recall ever seeing it when starting voxl-logger natively in the terminal.

Running: stdbuf -oL -eL voxl-logger -c hires_small_color -i imu_apps -i imu_vectornav -B baro_vectornav -g gnss1_vectornav -I ins_vectornav
Welcome to voxl-logger
58127 MB left in /data/voxl-logger/
starting new log: /data/voxl-logger/log0044/

connected to ch 0 /run/mpa/hires_small_color/
connected to ch 1 /run/mpa/imu_apps/
^C
Stopping...

received SIGINT Ctrl-C
WARNING, _stop_helper_and_remove_pipe timed out joining read thread

Segmentation fault:
Fault thread: voxl-logger(tid: 26766)
Fault address: 0x7f9d719010
Address not mapped.

The main issue is that when this happens it fails to print the logger summary (channels & messages logged) which is important for me to quickly analyze the validity of the logged data. Also we've had issues with the logger not shutting down gracefully and only partially populating the final row of the csv it was writing to.

Do you guys have any idea why this might be happening? I would much prefer the logger to exit consistently and gracefully.

Thanks!

Do the apps and slpi processors share the same clock? I intend to publish external vio data to voxl-px4, and I'm wondering how it should be timestamped to properly ingest into the EKF2 module. Right now I am timestamping things on the apps side using the monotonic clock (same as voxl-camera-server and voxl-imu-server).

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

@Vinny We have the M0204, good to know that the usb3 SS lines are fixed. As I am just doing bench testing, the only other device I have plugged in is the IMX214 hires camera (which I am trying to log frames of).

Spec wise I have been testing with a Samsung T7 shield connected over USBC, their docs weren't super clear but it seems like it consumes maximum 7.5W at 5V, so that could be the issue. With USB3.2 connection they claim it can reach 1GBps writespeed, and we are under 1/10th of that in requirement (we require about 93MBps).

I could splice in auxiliary 5V power to see if that helps.

@jonathankampia Another strange issue! On a standard VOXL2 with the USB3 expansion board, same SDK version (1.5.0), the VOXL is unable to detect the external SSD's partitions so I can't even mount it. Same SSD plugs into a VOXL2 mini and partitions are detected.

@jonathankampia Oh yeah, also, we tried modding the cable like the documentation I linked said to. All we had on hand were some tiny 220nF caps, not the caps linked in the docs. The modded cable wouldn't even allow the USB slave device to show up on lsusb.

I am trying to log camera data to an external SSD using the voxl-logger utility, with the SSD hooked up to the J3 port of the VOXL2 mini. According to voxl-inspect-cam, the frames I'm trying to save are ~3.11MB, so at 30FPS would require around 93MBps write speed. The external ssd we have hooked up (temporarily) is a 2TB samsung T7 shield, which has an advertised write speed of up to 1000MBps, well over what we need.

The main problem is voxl-logger's output:

voxl-logger -c hires_small_color -d /mnt/ssd
Welcome to voxl-logger
1906214 MB left in /mnt/ssd/
starting new log: /mnt/ssd/log0001/

connected to ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/

ERROR: invalid metadata, magic number=-2055633543, expected 1448040524
most likely client fell behind and pipe overflowed
flushing backed up pipe ch 0 /run/mpa/hires_small_color/
flushing backed up pipe ch 0 /run/mpa/hires_small_color/

It works for a while, then eventually something backs up and the logger prints this debug message infinitely. It becomes unresponsive and I can't kill it with Ctrl+C. It seems like there's some bottleneck preventing the client (voxl-logger?) from receiving frames at the correct rate from the mpa pipe.

I am aware of the potential issues with the superspeed lines of the connector, but I get this output when taking the diagnostic steps that page details:

voxl2:/$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 10000M
    |__ Port 1: Dev 23, If 0, Class=Mass Storage, Driver=usb-storage, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

So I don't think datarates on the port/cable are the issue, and unless samsung is lying on their documentation by over 10x, I dont know how the ssd itself could be the issue either.

I was also able to test the data rate to this SSD with dd (linux utility) and saw some weird stuff. When trying to push lumps of data ~2GB, it would push the first 80% extremely fast (like 900MBps) and then lock up on the remaining data and take over 40s to transfer the rest. Seeing that made me think it could also be browning out.

Is there anything I am doing wrong / falsely expecting the VOXL2 to be able to perform? I can try a regular VOXL2 with the USB3 expansion and see if that works better for now, but in the end we need to use the mini anyway so I would like to get this issue figured out.

Thank you!

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

@Alex-Kushleyev Just gonna bump this

@Alex-Kushleyev Hey, thanks for the response! It fixed the crashing issue, and I can see frames being processed by running 'voxl-inspect-cam -a', but viewing the boson feed on the web portal shows a blank (black) video feed. I copied the config snippet into my file (swapping out the camera for the correct one). Something interesting to note is that even though I configured the camera for 30fps in FLIR software and on VOXL end, it seems to only be streaming about 11-12 fps. Maybe something is wrong on the camera side?

Just to update with some extra information, this is the exact camera: https://www.oemcameras.com/product/22640a032-htm/