Posts made by jonathankampia

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.

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!

Hi, my setup is as follows:

Nvidia jetson orin communicates with VOXL 2 over ethernet onboard drone, drone communicates with GCS via doodle labs radio. All components are properly set up (i.e. I can ping the orin & VOXL2 from the gcs and vice versa).

I have some ros nodes that need the orin compute, so they run external to the VOXL. I can see/echo relevant topic information published on the VOXL (like microdds agent fmu topics) on the orin and GCS. However, I can't see anything published by nodes on the orin, even though it's on the same network as the VOXL, same domain ID, so the topics should be shared via fastdds multicast.

I've messed around with hosting a discovery server on the VOXL and seeing if that would fix the problem, but it doesn't seem to. Maybe I'm doing something wrong though.

I understand if this isnt you guys' area of expertise, but there isn't much documentation relevant to my particular setup, and most people say that it's a DDS middleware issue, but I've verified middleware compatibility and it seems to be capable of multicasting FROM the voxl. Any help / advice would be appreciated.

Trying to integrate a Flir Boson IR camera with the VOXL2. Ideally this would be done through MIPI CSI, which is listed as a compatible interface on the VOXL 2 feature matrix webpage. Does the camera have driver support in voxl-camera-server? As far as I know voxl-lepton-server is only compatible with the Flir Lepton camera aswell.

Please let me know if this sensor is actually compatible, and through what route?

Thanks!

@Kiazoa-Joao I haven't worked with the voxl flight but if there's no other way probably just reflash the board? Here's a link to the modalai developer downloads: https://developer.modalai.com/

You (shouldn't?) need ROS indigo natively if you are just going to dockerize your onboard ROS stuff. All the dependencies needed by whatever code you run in the container should be satisfied within the container; what is/isn't installed outside the container shouldn't matter. But it sounds like you are running a pretty old board with possibly not the most updated firmware, so reflashing with the latest for the VOXL Flight from that website I sent might be a good idea

@Kiazoa-Joao

Docker is basically a tool that lets you create 'images' and run 'containers' that emulate certain environments in other foreign environments. So, you can have a container with ubuntu 18 running ROS melodic on a machine with an outdated version of ROS running kinetic or indigo or something old.

This is how I did it:

1. Install docker on your base machine
2. VOXL is an arm based processor as opposed to amd64, so you will need to run this: https://github.com/multiarch/qemu-user-static which will let you build containers for different system architectures
3. To build a docker image, you can either pull a prebuilt base image, run it as a container, install any dependencies and copy over your ROS stuff, then docker commit it to a new image, or list all that out in a dockerfile. I prefer the first way, even though it is pretty scuffed
   In your case you would want arm64v8 ubuntu 18.04 ROS melodic
   Here's a list of the official docker ROS prebuilts: https://hub.docker.com/r/arm64v8/ros/
4. Compress the image into a tar.gz archive, adb push it onto the VOXL and unpack it there. Then you can launch a container from the image (make sure to run it with --net=host argument), and run your ROS nodes inside the container.

There's documentation online for all four steps, and LLMs like chatgpt give pretty good general pointers on command syntax.

@Zachary-Lowell-0 Hi, thanks for the reply. Based on what I have read, I think MAV_CMD_DO_SET_SERVO (183) from the MAVLINK common message set would be the correct one to send? With the fields set to channel=5 and PWM=pwm value.

import asyncio
from mavsdk import System
from mavsdk.mission import MissionItem, MissionPlan

async def set_servo_pwm(channel, pwm_value):
    drone = System()
    await drone.connect(system_address="udp://:14540")

    # Wait for the drone to connect
    async for state in drone.core.connection_state():
        if state.is_connected:
            print("Drone connected")
            break

    # Send the MAV_CMD_DO_SET_SERVO command
    await drone.action.do_set_servo(channel, pwm_value)
    print(f"Set servo on channel {channel} to PWM {pwm_value}")

asyncio.run(set_servo_pwm(channel=5, pwm_value=1500))

I asked chatgpt for a quick example and it came up with this.

I mostly just want to avoid overriding a PWM value that the mixer is sending to channels 1-4 to actually fly the drone... Not completely sure if he pwm channel mappings make logical sense or are flipped or something weird.

Hi, I am trying to control a gimbal from onboard a VOXL 2 connected through the m0065 expander board. PWM channels 5-8 are apparently usable but I have no idea how to actually control them onboard the drone (i.e. I have no clue what QGC is doing under the hood in the actuators tab). Ideally the gimbal control script would fit cleanly into the set of ROS2 nodes I already have running on the drone, but it doesn't seem like the microdds agent advertises / subscribes to any of the uOrb messages related to servo control. If it's possible with MAVLINK directly I'll look to do it that way, but I wanted to ask for input first.

I was wondering if you guys could suggest a working approach to go about this, or provide some documentation I may have missed. Thanks!

@Zachary-Lowell-0 Hi, sorry for the late reply. This was the issue (lol)

@jonathankampia Edit: managed to fix it by disabling voxl-configure-modem and manually setting the IP of the eth0 interface. I guess 'eth1' is the J11 connector then.

Hi,

We are trying to connect an external companion computer (nvidia jetson ORIN) to a VOXL 2 via the ethernet / usb hub. We have a doodle labs radio successfully connected to the VOXL on the J11 connector. voxl-configure-modem correctly sets the eth0 network interface to the doodle IP; however the eth1 network interface (which I assume is the J13 ethernet jack on the expansion board?) seems to get automatically assigned an IP on the doodle network aswell, unrelated to voxl-configure-modem.

I can't get the external companion computer to connect to this interface. Setting a static IP on the Jetson that matches the subnet & netmask of the eth1 network interface on the VOXL2 doesn't connect. I'm not too familiar with networking, or what is going on with voxl-configure-modem. I was hoping you guys could provide some insight with regards to which network interface is which, and why the doodle is creating its own network interface in addition to the one created by voxl-configure-modem.

Thanks!

@brahim
After doing some testing on a Starling 2 Max, I've observed that in offboard mode the drone has an incredibly hard time holding its position. I am using the same code I posted on this thread earlier, that sets a waypoint via the trajectory_setpoint topic virtually identically to how this example does it. It flies extremely well in position hold mode (when trajectorysetpoint commands are not being sent, and has an extremely accurate local position, but starts jerking around and generally having a very hard time when I switch it to offboard mode and allow my node to start publishing TrajectorySetpoint position commands.

I am using the latest version of the SDK, (1.3.3), and have tried multiple version of px4_msgs, including the one gets built when you install voxl-mpa-to-ros2 and the 1.14 foxy version that can be found in the px4_msgs repository. There just has to be some communication issue going on, as the drone should fly the same in both position and offboard mode.

There appear to be no errors with the microdds agent as far as I can tell.

The only thing that makes sense is that the offboard commands are being sent in some wrong format that is messing up the drone. The fact that just them being sent messes up position mode flight (which they should have no impact on), combined with the fact that the drone flies awfully in offboard mode but seems tuned very well in position mode, suggests to me some sort of communication formatting error.