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/
The system was tested in VIO mode for 20 minutes before shipping. All drones are very sensitive to frame modifications, so this needs to be done carefully
Your understanding is correct, ModalAI's supported configurations are a result of Qualcomm limitations
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.
You can see an example of how to write telemetry on top of a video frame here
https://gitlab.com/voxl-public/modal-pipe-architecture/voxl-qvio-server/-/blob/master/server/main.cpp#L715
Are you flipping the fastboot switch back? Your symptom is consistent with leaving the fastboot switch engaged instead of setting it back to normal after a few seconds
Might be worth watching the tutorial here if you're unsure
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 would have shipped with everything tested and working. What do you mean by "passed the wizard"?
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
You should not change the firmware that shipped with the drone. The drone was flown right before putting in the box and it is tested to be in working order.
Are you outside testing GPS?
The instructions before are in case you accidentally changed the firmware.
Everything you are looking for can be found at https://docs.modalai.com
Those are all OV7251 sensors, you can see the product brief here
Otherwise, you need to be outside for GPS to lock
If you are just using top, it may not be the complete story. The Snapdragon 821 CPU scales the frequencies based on usage, but top does not take that into account.
The voxl-inspect-cpu tool does take that into account
The thermal and performance page may also be interesting
These are the dampeners we are using on VOXL Flight
The dampening may needed to be tuned for your flight platform though, and can definitely be different depending on flight dynamics. We have had a lot of success sticking a piece of foam between the plate and the frame.
https://www.amazon.com/gp/product/B073LPTHCL/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1
Yes, but to use the B2B connector you will need a custom PCB.
There are other i2c available.
There are no HW PWM on VOXL, but on VOXL Flight there are HW PWM through the Flight Core portion
Is this a custom setup? If so, my first guess would be that the extrinsic pareters between camera and IMU have not been set
Check out the debugging section in this document https://docs.modalai.com/flying-with-vio/#troubleshooting-vio