@tahawaru please pull down the latest dev branch: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros2/-/tree/dev?ref_type=heads
You can rebuild with the dev branch and see if you can both ros2 topic echo and rosbag record the encoded images. Please be aware that you will need to manually decode the images somehow on the receiving end (your application) as there isn't a built-in way in ros2/rviz to decode.
@binu-abraham I do not believe modalai has images on docker hub or any other docker repo. The gitlab repo has all of the Dockerfiles though.
@binu-abraham you can do an scp of the get_docker.sh script here on to the voxl2 and then run it.
Most of the voxl suite packages assume you have an adb connection.
As for building the docker image over ssh, I would just clone down voxl-docker-mavsdk on to the voxl2 itself, change directory to voxl-docker-mavsdk, and then just run the following command:
docker build . -t mavsdk --network=host
This should build an ubuntu focal image with mavsdk + all dependencies as well as the takeoff and land example
@ejohnson you are correct on both accounts.
There needs to be a unique component ID for each camera stream. And yes, each camera stream needs it's own pipe opened, since running all the threads in the same pipe will result in one pipe blocking the rest (and the mavlink streams will not work for the other camera instances)
There is already a compid variable within the context struct, so I just need to implement that in the main.c for loop. Will also need to add a unique "mavlink_from_gcs" pipe channel for each stream instance in the context struct as well. I can push these changes upstream
@JP-Drone said in Support Photo/Video Capture via RC Switch:
MAV_CMD_IMAGE_START_CAPTURE
How are you handling the mavlink camera protocol exchange within voxl-px4? I know that there is the ability to forward commands to the GCS if using mission commands (but not manually flipping an RC switch).
Alternatively when using a joystick you can map a button to image capture: https://docs.px4.io/v1.15/en/camera/mavlink_v2_camera.html#manual-controllers
Currently the mavcam manager fully implements the camera protocol to send the ack for the incoming mavlink commands. It also handles the capture and video stream status (satisfies the mavlink camera protocol).
My only issue with implementing this is that the upstream voxl-px4 will not be camera protocol compliant and thus we are bypassing the entire protocol just to get camera image capture from the autopilot instead of the GCS (which also implements the same camera protocol). If you have a way to implement the protocol (even a stripped down version of it) please send a link so I can look at the code.
I am trying to import an external tsdf and esdf from a realsense lidar into voxl-mapper. I am looking at the code and only see the mesh is not used in loading a saved map, but just tsdf and esdf. The error I get is the following, which causes voxl-mapper to freeze.
Client requested load map.
full file name: /data/voxl-mapper/officetest/esdf
full file name: /data/voxl-mapper/officetest/tsdf
Version number mismatch! This needs to be handled...
Updating mesh
I grepped for the error statement but came up with no results, so I am not sure where in the stack the error is coming from. Any help is appreciated (edited)
Make sure these variables are set on the voxl2 and external pc:
ROS_DOMAIN_ID = 0
ROS_LOCALHOST_ONLY = 0
You can check if multicast is enabled on both sides with this command (assuming external pc is linux):
ifconfig | grep -i multicast
This should show multicast enabled for the interface (wifi or ethernet) connected to the external pc via network.
@jonathankampia, the way that voxl-microdds-agent works is that it wraps around the XRCE microdds agent binary from e-prosima, and bridges the px4 microdds topics to the DDS global data space (e.g. ROS2 topics).
The voxl-microdds-agent runs irrespective of any serialized message definitions, so it is just the transport. Probably not the issue, but if you still feel strongly that the agent is the issue, there are ways to test that.
Most likely, the mismatch is between px4_msgs and the voxl-px4 version. In that case serialized message definitions DO matter, and the mismatch could cause issues, but usually this is caught when the dds agent service runs (it will report errors you can view via systemctl status).
What sdk version are you using on the voxl2? You could checkout the submodule px4_msgs version that voxl-mpa-to-ros2 uses.
It would be difficult to troubleshoot without the actual offboard code to test, maybe post a snippet of your code?
For an offboard example using trajectory setpoints, you can also try this one which has been referenced a lot in the PX4 community
@tahawaru please pull down the latest dev branch: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros2/-/tree/dev?ref_type=heads
You can rebuild with the dev branch and see if you can both ros2 topic echo and rosbag record the encoded images. Please be aware that you will need to manually decode the images somehow on the receiving end (your application) as there isn't a built-in way in ros2/rviz to decode.
@tahawaru there are a few intermediate steps to get ros2 offboard control:
disable offboard_mode (set to false) in voxl-vision-hub.conf line 237: "offboard_mode": "false"
Ensure voxl-microdds-agent is running. You can check by running systemctl status voxl-microdds-agent
Once these steps are complete, and you have the ros2 offboard fig 8 running, you should be able to echo the offboard control mode info either in an adb shell or mavlink console:
In adb you can use the command px4-listener offboard_control_mode which should return this
offboard_control_mode
timestamp: 314055050 (0.031338 seconds ago)
position: True
velocity: False
acceleration: False
attitude: False
body_rate: False
actuator: False
ros2 topic echo /fmu/in/trajectory_setpointManual mode is not really representative of the ability to switch into offboard mode and send setpoints. You will need to be able to arm in position or hold mode first. If you do not have an rc controller then try to arm in hold mode. If you are not able to arm in either mode, then there is a preflight check fail somewhere that needs to be addressed first.