Posts made by jonathankampia

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.

@Zachary-Lowell-0 What you are saying definitely is expected behavior; my problem was the opposite. When the drone was in position mode, it seemed to be reacting to / fighting the commands my offboard node was passively sending. (i.e. when I disabled the offboard node, the drone flew fine in position mode).

@brahim
I am using SDK version 1.3.3

After some further testing it seems like the issue is that I was treating the px4 uOrb messaging platform (which the microdds agent just bridges to ROS) as if it were a MAVROS node. It seems like constantly pushing messages to the trajectory_setpoint topic makes the drone fight itself in position hold mode, whereas using MAVROS as the bridge allowed that. This is just a theory though, I have yet to test it in real life.

Here's a snippet of the code in question:

(QoS and publisher creation)

        // QoS profile for publishers
        rclcpp::QoS qos_profile_pub(rclcpp::QoSInitialization::from_rmw(rmw_qos_profile_sensor_data));
	qos_profile_pub.keep_last(1);
	qos_profile_pub.best_effort(); 
	qos_profile_pub.durability_volatile(); 
	qos_profile_pub.liveliness(RMW_QOS_POLICY_LIVELINESS_AUTOMATIC);

	// initialize publishers
	printf("Publishing to /fmu/in/trajectory_setpoint \n");
	trajectory_setpoint_publisher = node->create_publisher<TrajectorySetpoint>("/fmu/in/trajectory_setpoint", 10);

(Actual publishing code)

void idle() {
	
	//printf("IDP_x: %f \n", idlepoint.position[0]);
	idlepoint.yaw = -3.14;
	idlepoint.timestamp = node->get_clock()->now().nanoseconds() / 1000;
	trajectory_setpoint_publisher->publish(idlepoint);
}

^ The 'position' array of the idlepoint object is set in another function. Position and yaw are the only two offboard states the code is set to control through the offboard_control_mode topic.

It seems like the example you linked also doesn't actually publish the messages to /fmu/in/trajectory_setpoint unless the vehicle is in offboard mode, which may fix my problem. I will also try just building voxl-mpa-to-ros2 and using that version of px4_msgs instead. Thanks!

Hi, I am facing an issue running custom offboard code on a drone running a VOXL 2 thru ROS2 foxy. The node subscribes to the local position topic /fmu/out/vehicle_odometry, and publishes position to commands to /fmu/in/trajectory_setpoint. When the node runs, the drone seemingly cannot take off in position mode; the motors spin up but it struggles to get off the ground. Without the node running, it flies perfectly. I was able to narrow it down to the publisher causing the problem, as running the code with only the subscriber enabled still allows the drone to fly normally. So, basically, publishing TrajectorySetpoint messsages to the fmu/in/trajectory_setpoint topic causes some sort of communication issue(s) that prevent the drone from flying normally, even when the drone is not in offboard mode.

I had the same issue simulating the node with px4_sitl on ros2 foxy, but figured out it was because in some cases I was sending uninitialized values in the position array of the TrajectorySetpoint message. The code that I got to work normally in the sim then replicated the same issue on the VOXL 2 in real life. This leads me to believe the problem is with a mismatching version of the px4_msgs package, which might clash with whatever voxl-microdds-agent accepts. I am using this version of px4_msgs on the drone. It could also potentially be a QoS problem, but I matched the QoS of the publisher to whatever ros2 topic info --verbose spat out, so I don't think that's the issue.

Just wondering if you guys could share any insight into how the voxl-microdds-agent works, what px4_msgs package version I could use, etc. Or if you have experienced the same issue. I am going to try to replicate this on a starling that I have flown in offboard before (not with ROS 2 though). I might honestly just switch back to ROS 1 if this keeps happening, cause I have had nothing but trouble working with ROS 2 thusfar.

Thanks!

@Alex-Kushleyev I never uploaded any parameters, just used both escs out of the box. maybe that caused the issue?

@jonathankampia Update: running the voxl2_io driver command modified to px4-qshell voxl2_io start -p 7 worked! The voxl-px4-start script correctly noted that all qshell commands needed to be prefixed this way, but for some reason starting the driver from there wasn't working. I just added the line manually to the extra commands section of the voxl-px4.conf file and it works now. Weird, though.

As for the second IO board we have, I am still confused why I can't update the firmware. Maybe the board is just bricked.

@Alex-Kushleyev Hi, thanks for the reply, will try that tomorrow. As for the ESCs failing, we were using these motors (1155kV version) with GF8040-3 (8 inch triblade) props on a 6S setup. I don't have pictures of the two ESCs that broke, but they were the 6S version of the voxl esc here. They each had a sticker on them labeling them as 6S, and the packaging also said so.

It's also worth knowing that they failed in super low current settings. We never got the drone off the ground with the first ESC, a short somehow formed between two of the leads for one of the motors while we were testing them (we did motor testing with both voxl-esc spin and the motor slider tab in QGC). The second ESC just exploded the instant I moved one of the motor sliders in QGC. We heard a pop and a mosfet literally flew off, so I'm guessing there was a short inside it. Neither of those situations should be drawing much current...

There's really no way to mess up V+ and V-, and afaik there's no way to really 'mess up' the motor wires, but I kept them in order anyway. So, I highly doubt / hope it wasnt a wire mistake on my part.

My setup is nearly identical to the "VOXL 2 IO S.BUS input and PWM Output" case found here: https://docs.modalai.com/voxl2-io-user-guide/. The io board seems to work as intended, as I can communicate with the S.BUS receiver, and voxl-2-io upgrade_firmware says the firmware on the board is already up-to-date. I've edited the voxl-px4.conf file to change the receiver type to M0065_sbus and the ESC to VOXL_IO_PWM_ESC (or whatever the parameter is, it's correct there). I can also spin the motors through voxl-2-io spin. However, my ESC isn't connecting to the voxl 2 on bootup (I don't hear the final upbeat tones) and I can't spin the motors through the actuators tab on QGC, even though I believe it to be configured correctly.

By doing voxl-px4 -d | grep VOXL2_IO, and looking at the port numbers that voxl-2-io upgrade_firmware uses, it seems the problem is that it's trying to launch the driver and connect to port 2, when it should be trying to connect to port 7. However, when I run the command "voxl2_io start -p 7" in qshell, which should theoretically start the driver manually on port 7, it still won't connect.
We have one extra io board to test with at the minute, but I can't even update the firmware on that one, and when I run the 'spin' command it just spins one motor forever. Pretty sure both the io boards are bricked somehow.

The reason I am trying to use an external 4-in-1 esc is because the a mosfet(s) on the first VOXL esc we tried burnt out during initial motor testing and shorted, and the second VOXL esc exploded about 2 seconds into spinning up the motors for the first time. The drone is 6s, which they are rated for, and were 100% wired correctly, I had multiple people check and did continuity tests on all terminals.

Any advice on both of these matters would be appreciated.

Is there a way to change / mess with the song that plays when you power on the voxl esc?

Hi,

We are trying to hook up an mRo u-Blox ZED-F9 RTK L1/L2 GPS, which doesn't have a compass, alongside an external magnetometer with a QMC5883L chip. I read in another thread that chip is directly supported. Should we just be able to wire in the SCL and SDA pins from the mag, and PX4 should automatically recognize it? Or are there external drivers we need to add to the build? We tried it with an adafruit magnetometer + accelerometer unit and it wasn't recognized, but I'm not sure which chip it had or whether there were drivers for it (probably not).

Thanks

@Eric-Katzfey The EKF2_EV_CTRL param is set to 15 bits (all enabled). We don't have any cameras on the drone at the moment, though. Could that be introducing issues in the EKF2 and causing it to reset? I'll try disabling all vision stuff and see if it works different.