Thanks for posting the ssl fix. We're looking into this. We don't typically use rosdep for anything. Is there something specific you need to get working?
A more traditional ROS experience is easy to achieve running Ubuntu in a Docker on VOXL : https://docs.modalai.com/docker-on-voxl/
You should be able to use the open source PX4 avoidance, but it may require a bit of an atypical architecture. When trying to use big ROS projects we recommended running Ubuntu on VOXL in Docker
The base Yocto layer should be ROS core and expose the VIO and depth from stereo modules:
Then the Ubuntu OS in the Docker should subscribe to the appropriate hardware layer topics to execute the PX4 Autonomy
We should have this better documented, but keep asking on this thread and we'll try to get you going. Shouldn't be any major blockers, but a few tweaks are probably necessary.
We haven't tried the Avoidance stack in a while, so it's probably going to come down to what you are more comfortable with. If you are comfortable with Gazebo, SITL might be a good way to go.
The trick with ROS always comes down to making sure all of the nodes are talking to each other. There is a good tutorial on debugging ROS here
You'll want to have a list of the ROS topics the Ubuntu PX4 Avoidance stack requires, and then a list of the ROS topics the yocto base layer is providing. Then you'll need to map the two together.
You should only have one roscore, which should likely be in the Yocto layer. Your PC implementation should be able to see that if you have ROS_IP, etc configured properly.
The most valuable tool right now will probably be rostopic list and rostopic echo. Run ros topic on each of the layers:
Make sure you see the proper topics in each location and that they are publishing data.
Regarding stereo, I don't think that PX4 docs section is applicable. That RosDfsExample node should already be publishing a disparity map and point cloud. You can see it is publishing the disparity map here and point cloud here
It is the way for software to tell which TOF driver should be used. Setting to 1 supports the HAL3 method you are using, setting to 0 supports the older libCamera method using tof_cam_ros
The HAL3 method is intended to give the developer more control over the pipeline
Assuming the ipk is installed, can you please then run this command and then try the ROS node again?
setprop persist.camera.modalai.tof 1
We used the mvVM mapping feature in mvSDK. We are currently migrating to voxblox. We do not have official support for this yet, but you can see the work in progress here: https://gitlab.com/matt.turi/mavros_test
it is using the roskinetic docker though too.
We recommend using Ubuntu in a Docker for that type of package. You can communicate ROS from yocto into Docker
thanks for sending, I will pass along to someone more familiar. Was this all working before? Do you know what has changed?
Can you put some pieces of duct tape on the floor or something to make it more interesting to the VIO system? Especially since it looks like that floor might be reflective. Random small pieces of tape, like electrical or duct tape, would likely help.
You can monitor the VIO stability on QGC. Those numbers should stabilize after takeoff, but obviously you want them stable on the ground too.
Is the tracking camera looking at interesting "features" when it takes off, or is it just white floor? If it can start on a carpet or something, the vision system will have something to track. this will help VIO reduce drift.
Configuring to run on boot is documented here
For peripherals, you can configure for privelaged mode. voxl-camera-server and voxl-imu-server run on the yocto layer and output their data to pipes which can be accessed inside of the Docker. That's all coming online right now but should be working. For the rest of the peripherials it comes down to what you expose at docker run
Yes, see docs here: https://docs.modalai.com/docker-on-voxl/
We have changed partition on flash to two 16GB partitions. See this section where it points you to use the /data partition which is 16GB specifically for Docker use
Running everything in a Docker would definitely be the easiest way to go. The code inside of the Docker runs faster than on the yocto layer as the Docker is a pure ARMv8 userspace. Is that a possibility?
Otherwise you would probably have to use a cross compiler (like an upgrade to voxl-cross) and then try to work out linking on target. This blog post here suggests using LD_PRELOAD
Docker would still be easier, and likely better performant
thanks for sending the video. We'll look at this in detail. Can you please dump /etc/modalai/voxl-vision-px4.conf and provide? Can you make sure offboard_mode: "off"?
Hi Daniel, the instructions for configuring station mode can be found here: https://docs.modalai.com/wifi-setup/#configure-station-mode