checkout the MCBL-00011 which can act as a cable coming from power regulator that powers both voxl and flight core

I know this is kinda an old post but I have created a driver for px4 that can use both flavors of the MS5837 the bar2 and bar30. I will create a pull request with px4 so it will be available.

You can add a directory from your host machine which has whatever python files you wish to add via adding a src directory path and mapping it to a path in the containers file structure.

docker run -it --rm -v /host_src_dir_path:/container_dir_path --privileged --net=host <img>:<tag>

Upon running the docker container, the directory from /host_src_dir_path will be available at /container_dir_path

In the future if you need to quickly change the ip address of where the voxl looks for qgc you can do

voxl-vision-px4 -i <ip>

@Eric-Katzfey Thanks for the suggestion.

For anyone else interested in doing this, these are the steps I took to accomplish this.

• In order to change where the root of the docker runtime points to in the docker service go to
  /etc/systemd/system/docker-start.service and change the following line so that it uses the sd card(ext4 format) in the voxl ExecStart=/usr/bin/docker daemon -g /mnt/sdcard

• restart the service for the changes to take effect: systemctl restart docker-start.service

• Delete the directories that docker uses in the data partition:cd /data; rm -rf containers linkgraph.db overlay tmp volumes graph network repositories-overlay trust

• [NOTE] The previous commands will delete any images that were previously available.

• You can now run voxl-configure-docker-support.sh and a hello world image will be created
  and the directories that were deleted from the /data partition will be in the /mnt/sdcard
  directory.

• You can verify that you have freed up the /data partition via df -h

So I am trying to find the place where I can setup network interfaces in order to assign a static ip address for eth0. On the rb5 I can do this via modifying the /etc/dhcpcd.conf file; however, this isn't present on the voxl. I see all the interfaces via ifconfig -a and the corresponding sys/class/net but there doesn't seem to be .network of ifcfg files there.

I would have thought that the interfaces would either be in /etc/sysconfig/network-scripts/ifcfg-eth* or in /etc/network/interfaces where I could modify files that could be brought up via ifconfig eth0 up but this doesn't seem to be the case.

Right now I am doing this via enabling a systemd service

set -e
ETH_ADD=192.168.2.120
ifconfig eth0 up || (echo " failed to open eth0" && exit 1)
ip addr add ${ETH_ADD}/24 dev eth0 || (echo " failed to add ip link eth0" && exit 1)

I see that this can be done in the poky_build but any suggestions as to where this can be done on the voxl in a more Linux-esque way?

Thanks,
Ryan Meagher

I was able to get the microRTPS_client and microRTPS_agent working between the flight core and the voxl. My ROS2 setup is now complete and I have done various testing between the flight core and voxl to confirm this. It turned out to be more work than I expected.

I created a compact microRTPS parser on the hexagon sDSP in the voxl_io on the receive side to minimize the snapdragon’s involvement with assembling messages. The messages are passed through the shared memory from the hexagon sDSP to the ARM CPU. I created a UDP tunnel in the voxl_vision (running on yocto Jethro) to tunnel UDP microRTPS messages between the host os and the Ubuntu 20.04 docker container running the micrortps_agent and ros2 px4_ros_com launch file.

There are a couple gotchas that I faced. The first is that some characters are being dropped between the flight core and the voxl every so often. I have not isolated which side is at fault (need to connect a logic analyzer and capture the event on the wire), but these cause CRC errors in the messages. Neither side reports an error on the write or read that I was able to log. If I get some additional equipment, I’ll probably try to track down which side is at fault.

I wrote a utility program that captures characters on any of the serial buses and logs the data to a file. I’ve verified that even in this simple setup, characters are being dropped. I have the baud rate set at 921600. With only about 6 messages being sent, I’m sending about 650kbps over the wire so this baud rate may need to be increased as the px4 guys recommend a minimum of 1MB.

There is also an issue with the way the micrortps_agent handles errors that can cause an eventual lockup if you have CRC errors in the messages that required some modification, which is what I believe you are facing @benjamin-linne . It seemed like the UDP messages were stopping but with tcpdump and voxl-perfmon, I was able to isolate it to the way the transport was handling errors. The fix is reasonably straightforward, but eliminating any CRC errors beforehand avoids this issue.

@benjamin-linne not sure if I’m allowed to give out the code but send me you contact info and we can talk offline.

@tom Thanks for the info, my voxl didn't have a default /etc/network directory which is what threw me off.

Thanks,
Ryan Meagher

So I am trying to find the place where I can setup network interfaces in order to assign a static ip address for eth0. On the rb5 I can do this via modifying the /etc/dhcpcd.conf file; however, this isn't present on the voxl. I see all the interfaces via ifconfig -a and the corresponding sys/class/net but there doesn't seem to be .network of ifcfg files there.

I would have thought that the interfaces would either be in /etc/sysconfig/network-scripts/ifcfg-eth* or in /etc/network/interfaces where I could modify files that could be brought up via ifconfig eth0 up but this doesn't seem to be the case.

Right now I am doing this via enabling a systemd service

set -e
ETH_ADD=192.168.2.120
ifconfig eth0 up || (echo " failed to open eth0" && exit 1)
ip addr add ${ETH_ADD}/24 dev eth0 || (echo " failed to add ip link eth0" && exit 1)

I see that this can be done in the poky_build but any suggestions as to where this can be done on the voxl in a more Linux-esque way?

Thanks,
Ryan Meagher

@Vinny no worries, I ended up just going to industrial hardware in SD and trying out a bunch of machine screws until I got one that fit nicely, cant recall the exact size. Here are the dimensions for mounting the M0026 in a part I made. Figured I would post it if it helps someone else out since I personally couldn't find a STEP file for this part. Dimensions are in mm, the camera is ~24.1mm from base to the tip of the lens from my caliper measurements.

@Chad-Sweet one last question, would it make sense to install a heat sink on the snapdragon in addition to the fan for a uuv application, or do you think that is overkill? I am doing heavy image processing so I want to make sure that the snapdragon doesn't throttle.

@Chad-Sweet Awesome, appreciate your help! I couldn't tell which one was the snapdragon

@Chad-Sweet thanks for the info, my voxl is in an enclosure of a uuv so I won't get the same heat dissipation as expected from flying.

Would it be better to mount above the Voxl in position A or B in the below picture?

I want to mount the Voxl cooling fan onto the Voxl board but I don't see any mounting holes. Based on your thermal testing where do you recommend the optimal placing of the fan in relation to the voxl and the optimal distance away from the board so I can make a custom part?

I was able to get the microRTPS_client and microRTPS_agent working between the flight core and the voxl. My ROS2 setup is now complete and I have done various testing between the flight core and voxl to confirm this. It turned out to be more work than I expected.

I created a compact microRTPS parser on the hexagon sDSP in the voxl_io on the receive side to minimize the snapdragon’s involvement with assembling messages. The messages are passed through the shared memory from the hexagon sDSP to the ARM CPU. I created a UDP tunnel in the voxl_vision (running on yocto Jethro) to tunnel UDP microRTPS messages between the host os and the Ubuntu 20.04 docker container running the micrortps_agent and ros2 px4_ros_com launch file.

There are a couple gotchas that I faced. The first is that some characters are being dropped between the flight core and the voxl every so often. I have not isolated which side is at fault (need to connect a logic analyzer and capture the event on the wire), but these cause CRC errors in the messages. Neither side reports an error on the write or read that I was able to log. If I get some additional equipment, I’ll probably try to track down which side is at fault.

I wrote a utility program that captures characters on any of the serial buses and logs the data to a file. I’ve verified that even in this simple setup, characters are being dropped. I have the baud rate set at 921600. With only about 6 messages being sent, I’m sending about 650kbps over the wire so this baud rate may need to be increased as the px4 guys recommend a minimum of 1MB.

There is also an issue with the way the micrortps_agent handles errors that can cause an eventual lockup if you have CRC errors in the messages that required some modification, which is what I believe you are facing @benjamin-linne . It seemed like the UDP messages were stopping but with tcpdump and voxl-perfmon, I was able to isolate it to the way the transport was handling errors. The fix is reasonably straightforward, but eliminating any CRC errors beforehand avoids this issue.

@benjamin-linne not sure if I’m allowed to give out the code but send me you contact info and we can talk offline.

I made a custom piece in solidworks for the M0026 HiRes camera and 3D printed the part and it requires longer screws. I have looked at the data sheets and cant seem to find the exact screw they use. The screws fits in nicely to a 1.3mm hole in PLA, wondering if you guys knew the exact screw needed?

@Alex-Kushleyev Thanks for the help, still working on this bridge but have made some progress, able to create io_rpc functions and add some stuff to voxl-vision and am now able to get messages in my docker container with
ros2 launch px4_ros_com <launch_file>