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/
It would have shipped with everything tested and working. What do you mean by "passed the wizard"?
Your understanding is correct, ModalAI's supported configurations are a result of Qualcomm limitations
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
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 don't have a production mechanical solution yet for the TOF. We have used double sided sticky tape for prototypes, picture below. An extension cable, found here, might help make things easier.
Bash for Windows is not something we have tried specifically.
If that is your only machine, your best bet though would be to try either:
A lot of effort goes in to supporting a new modem on a companion computer. The kernel needs to be modified, drivers need to be developed. We sell specific accessories that we put that effort in to so they can work with VOXL.
Without knowing what type of modem you are trying to connect, it is difficult to suggest where to begin.
Some things that might help:
The short answer is yes, the long answer is that it is probably a decent amount of work.
PX4 1.9 builds and runs for this platform, but may not fly. With that build, you need UART based ESCs like we have here: https://modalai.com/esc
Mid-PX4 1.10 development c++14 was introduced. The SLPI compiler does not support c++14. IMO it would be fairly straight-forward to either comment out that code (it's for simulation), or just use boost to fix the issue. We just haven't done that or put much effort into it.
You can take a look here:
branch https://github.com/PX4/Firmware/commits/excelsior_1.9
Build the firmware with "make atlflight_excelsior_default" to build the posix side and "make atlflight_execelsior_qurt-default"
Can you send the screenshot from the flashing process? Sometimes you need to run with 'sudo' or manually install via 'sudo fastboot'
if you type 'sudo fastboot devices' what do you see?
Also, voxl-vision-px4 uses the tracking camera. So if it is running image streamer will need to be set as a slave as voxl-vision-px4 is the master
The camera configuration must match what is connected to the board. So if all 3 cameras are connected, that is the configuration you must use.
Do not connect or disconnect cameras while the board is powered on
Can you share a picture of how you have connected things? Are you sure the pin ones line up appropriately?
Hopefully you are removing power from the board before changing the camera modules?
The board is not designed to handle hot-swapping of MIPI components. The connectors also are only designed for a few dozen insertions, so they are pretty delicate.
In short, it seems like you had it working and then changed some components? Did anything else change?
Are you sure they are all plugged in correctly? Does pin 1 on the stereo flex align for both connecting to the PCB and each sensor to the flex?
The two likely reasons for this error:
If you are not running anything that uses the stereo camera, is_cam_master should be true
You can check the configured camera IDs by:
cat /etc/modalai/camera_env.sh