Building ROS node with OpenCV

sarahl

@modaltb thanks so much! I was actually wondering if I needed something like buildx for the multi-arch building, but I couldn't get it to work with the Ubuntu version of docker. But this seemed to fix my previous issue, so I'll see how this goes. Just trying the first command for now without the COPY line.

@Voxlady I'll let you know if this fixes my issue. Haven't gotten to the OpenCV portion yet. I don't know what your disk storage constraints are on the raspberry pi, but I'm running on an amd64 Ubuntu 18.04 machine which hopefully will not run into storage issues. I noticed on the Voxl that what was taking up a lot of space was the docker overlays. I wonder if condensing all the dockerfiles into a single one would help (if you don't need all the intermediate images)?

Hi @modaltb and @sarahl ,

Thank you for your messages. It took me some trial-and-error time but I finally solved the problem by reducing the number of Docker Files as well as images. Now, everything seems working again.

BR,
Ayberk

modaltb

Thanks for the update. We really appreciate the feedback and community response!

sarahl

@modaltb okay it finally built, but when I tried to load it onto the Voxl, it ran out of space. So now I'm trying to build a new version with fewer intermediate images and with opencl removed. Are there any other ways to make more space for docker?

@Voxlady were you able to load your roskinetic+opencv image to the Voxl? Did you use 4.2.0 or 3.4.6 or another opencv version?

@sarahl,

Yes, I was able to load the image and even download additional packages in the container.

I merged two base files from Opencv/cl and kinetic. Moreover, I put everything that's in Dockerfile.opencv into Dockerfile.xenial-packages. So, in the end I didn't have any extra Opencv-cl file. I also disabled Opencl.
Most importantly, after I built roskinetic-xenial:v1.0, I deleted other two images base and minimal. I think that's okay to delete since no error or failure has occurred so far.
Last, I used some best practices suggested by Docker. Especially, for Dockerfile.xenial-base. See sorting multi-line arguments .
I think 3.4.6 version doesn't have a corresponding release in GitHub. So, ARG opencv_version=4.2.0 in Dockerfile.opencv assigns automatically. Therefore, I went with 4.2.0.

Hopefully it helps.
All the best

sarahl

@modaltb So I finally got the docker loaded, and also built cv_bridge and the camera ros driver. However, it doesn't seem to be reading in the camera (a FLIR). When I'm outside the docker, plugging in the device adds /dev/ttyACM0 and /dev/video2, the latter of which is used by the ros node. Is there something I need to do when running the docker to have access to the usb devices?

modaltb

@sarahl , here's an example of how we map and HDMI adapter into docker, not exactly the same but shows the usage:

https://docs.modalai.com/hdmi-input-accessory-manual/#start-the-ffmpeg-docker

sarahl

@modaltb thanks, I actually tried something similar by mapping /dev to /dev, and also passing it in with the --device parameter, but I'll try this out! is there a reason it's mapped as /dev to /opt in here? Should the /dev directory not be used in the docker contained? I did notice when I plugged and unplugged the device and ran ls /dev, that the device list did not update.

sarahl

@modaltb actually I think it's working now, and I somehow didn't actually have to map the /dev port. Turns out I just had a typo in my launch file. Thanks again for all the help!

sarahl

@modaltb I wanted to send an update, I was able to build and run an Ubuntu 18.04 + ROS Melodic docker + OpenCV 4.2.0 (because some of my nodes weren't working on the ROS Kinetic docker), but did require using multi-line arguments as @Voxlady suggested to reduce the size enough to fit. It seems like the size constraints are somewhere around 2.7 GB virtual docker size, and stem from too many docker overlays. Is there anyway around that in case there is a need for larger docker images?

modaltb

Hi @sarahl , unfortunately I don't have a quick answer for this

Eric Katzfey

@sarahl You could try using an SD card to build. This would give you a lot more space. You would have to change the Docker start service to tell it to use the SD card instead of /data for the build.

ryan_meagher

@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

Chad Sweet

Thank you for following up! Added to the docs here: https://docs.modalai.com/docker-on-voxl/

ryan_meagher

@Chad-Sweet cool, happy to contribute!

ryan_meagher

@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