Posts made by ryan_meagher

@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>

@Chad-Sweet Hey, I updated my voxl to the newest system image and after doing so my docker is using docker-start.service while before it was using docker-daemon.service.

Not sure why this has changed, but I have updated the above instructions and wanted to let you know so you could change this in the documentation.

Is there a reason why this would have changed after flashing a new system image onto the device? Both times I configured my docker by using voxl-configure-docker-support.sh

@gauravshukla914 no problem, glad it helped

@Alex-Kushleyev So something utilitzing the io_rpc similar to the io_rpc_mavparser.c and then exposing it to the voxl_io.h similar to voxl_io_mavparser.c then using this like how you guys are using it in the voxl-vision?

When developing this functionality on the hexagon sDSP are there any special issues or pitfalls I should pay particular attention to?

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

@Alex-Kushleyev That is the route I was taking and have finished implementing in the micrortps_transport.cpp file.

I have a few questions:

• @Chad-Sweet said that the libvoxl_io is not supported in a docker environment which is needed in order to build the micrortps_agent with ROS2. Is this possible?

• The voxl_io.h specifies a buffer length of 128 bytes whereas the micrortps_transport.h uses 1024 byte buffers. Can I pass a buffer larger than 128 to the voxl_uart_write()?

@Alex-Kushleyev Thanks for the response! the micrortps_client is running in the nuttx shell on the flight core and is autogenerated based on the *.msg files when building the px4 firmware. In order for it to work with a companion computer (according to the px4/ros slack channel) you have to pass one of the tty devices that is setup for telemetry in modalai's rtps.cmake file.

The following command will be run from the mavlink console or the voxl-px4-shell:
micrortps_client start -t UART -d /dev/ttyS6 -b 921600

The following command will be run from a docker image on voxl:
micrortps_agent start -t UART -d /dev/ttyX -b 921600

Due to the fact that the flight core doesn't have wifi, I dont think I can setup a socat connection or pseudo terminal as I am assuming this requires ipv4/ipv6 connectivity on both sides of client/agent.

It looks like the msg/generate_microRTPS_bridge.py file is calling microRTPS_transport.cpp which is setting up the read/writes so I will try to change this file to use the voxl_io on both sides.

I was wondering if anyone has successfully setup a micrortps_agent micrortps_client connection via UART attached to J10 or J11 on the voxl to the flight core. Ideally I would have the micrortps_agent performing the read and writes but since these connectors are mapped to the SDSP it doesn't seem possible to do it this way. I was wondering if there was an easy way to setup this bridge in the voxl_io and if someone would point me in the right direction as I haven't found much documentation regarding this.

@Chad-Sweet cool, happy to contribute!

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.

@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