Hi Pito,
you are saying that you are comfortable that the dockerfile should work. Have you successfully built with it before?
The github link you posted in your last message does not work , can you provide a working link ?
John was going to try your configuration on a RPI with 32-bit OS but did not get around to that unfortunately. We come across problems with the 64-OS quite frequently so it might be worth a shot. I can give it a try if you supply your configuration…
Cheers Thomas
Yes the docker file builds fine as is. It is when I then try to add the libraries for the raspi camera that I get the error. Sorry if I wasn’t totally clear.
I’ve made https://github.com/campusrover/gpg_bran_balena public so it should work for you now. That repo should work fine with Balena and get properly downloaded to the raspberry Pi.
Then when I follow with the steps outlined in this repo: https://github.com/UbiquityRobotics/raspicam_node I get the error. Specifically the steps in that repo that I am doing are under “build instructions”. I need to build that raspicam support because ROS doesn’t provide binaries for my specific configuration.
When I do those build steps, I get the following error (which is kind of where I started). I hope that is helpful and makes more sense. Again, I really appreciate your help with this. It’s kind of important and time sensitive for me.
root@53c26b1:/ros/catkin_ws/src# git clone https://github.com/UbiquityRobotics/raspicam_node.git
Cloning into 'raspicam_node'...
remote: Enumerating objects: 21, done.
remote: Counting objects: 100% (21/21), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 786 (delta 6), reused 11 (delta 4), pack-reused 765
Receiving objects: 100% (786/786), 335.49 KiB | 714.00 KiB/s, done.
Resolving deltas: 100% (472/472), done.
root@53c26b1:/ros/catkin_ws/src#
root@53c26b1:/ros/catkin_ws/src# cat /etc/ros/rosdep/sources.list.d/30-ubiquity.list
yaml https://raw.githubusercontent.com/UbiquityRobotics/rosdep/master/raspberry-pi.yaml
root@53c26b1:/ros/catkin_ws/src# nano /etc/ros/rosdep/sources.list.d/30-ubiquity.list
root@53c26b1:/ros/catkin_ws/src# cat /etc/ros/rosdep/sources.list.d/30-ubiquity.list
yaml https://raw.githubusercontent.com/UbiquityRobotics/rosdep/master/raspberry-pi.yaml
yaml https://raw.githubusercontent.com/UbiquityRobotics/rosdep/master/raspberry-pi.yaml
root@53c26b1:/ros/catkin_ws/src# cat /etc/ros/rosdep/sources.list.d/30-ubiquity.list
yaml https://raw.githubusercontent.com/UbiquityRobotics/rosdep/master/raspberry-pi.yaml
yaml https://raw.githubusercontent.com/UbiquityRobotics/rosdep/master/raspberry-pi.yaml
root@53c26b1:/ros/catkin_ws/src# nano /etc/ros/rosdep/sources.list.d/30-ubiquity.list
root@53c26b1:/ros/catkin_ws/src# cd ..
root@53c26b1:/ros/catkin_ws# rosdep install --from-paths src --ignore-src --rosdistro=melodic -y
executing command [apt-get install -y libraspberrypi-dev]
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
libraspberrypi-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 242 kB of archives.
After this operation, 2213 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/ubuntu-raspi2/ppa/ubuntu bionic/main arm64 libraspberrypi-dev arm64 1.20161003.2350bf2-1 [242 kB]
Fetched 242 kB in 1s (262 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libraspberrypi-dev.
(Reading database ... 69635 files and directories currently installed.)
Preparing to unpack .../libraspberrypi-dev_1.20161003.2350bf2-1_arm64.deb ...
Unpacking libraspberrypi-dev (1.20161003.2350bf2-1) ...
Setting up libraspberrypi-dev (1.20161003.2350bf2-1) ...
#All required rosdeps installed successfully
root@53c26b1:/ros/catkin_ws# Connection to ssh.balena-devices.com closed.
~/m/gpg_bran_balena (master=)
~/m/gpg_bran_balena (master=) balena ssh gpg-bran main
╭────────────────────────────────────────────────────────────────────╮
│ │
│ Update available 12.9.9 → 12.14.14 │
│ │
│ https://github.com/balena-io/balena-cli/blob/master/INSTALL.md │
│ │
╰────────────────────────────────────────────────────────────────────╯
? Select a device bitter-butterfly (53c26b1)
root@53c26b1:/ros/catkin_ws#
root@53c26b1:/ros/catkin_ws#
root@53c26b1:/ros/catkin_ws#
root@53c26b1:/ros/catkin_ws#
root@53c26b1:/ros/catkin_ws# catkin_make
Base path: /ros/catkin_ws
Source space: /ros/catkin_ws/src
Build space: /ros/catkin_ws/build
Devel space: /ros/catkin_ws/devel
Install space: /ros/catkin_ws/install
####
#### Running command: "make cmake_check_build_system" in "/ros/catkin_ws/build"
####
-- Using CATKIN_DEVEL_PREFIX: /ros/catkin_ws/devel
-- Using CMAKE_PREFIX_PATH: /ros/catkin_ws/devel;/opt/ros/melodic
-- This workspace overlays: /ros/catkin_ws/devel;/opt/ros/melodic
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.17", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python2
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /ros/catkin_ws/build/test_results
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python2 (found version "2.7.17")
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.28
-- BUILD_SHARED_LIBS is on
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~ traversing 1 packages in topological order:
-- ~~ - raspicam_node
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'raspicam_node'
-- ==> add_subdirectory(raspicam_node)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
CMake Error at raspicam_node/CMakeLists.txt:30 (MESSAGE):
Could not find mmal librariesOk, that makes things a little clearer.
I wonder if it makes sense for me to try and reproduce what you are doing as I do not have the hardware other than the RPI3. I guess the process might fail for me anyway.
Looking at what you are doing, two things cross my mind:
- the operations you are running in the main container will not persist through updates of the container. All software installations should be done in the Docker build process, otherwise the installed software is not part of the image and will be missing if the container is recreated. This means that the manual (?) steps you are performing in the container have to be repeated after every update. At the end of the installation you appear to be losing connection spontaneously. Has the installation finished completely ?
- there is still a chance that the 64-bit base OS is the culprit. Is it possible for you to try this on a 32-bit version of balena ?
Agreed on your point 1)… My thinking is that I first need to get it to work “by hand”, prove that it works and then move it to the docker script.
On 2) Yes I can try it. Help me: I make a new “application” based on a 32 bit PI and the rest is the same, right?
Hi there,
Yes create a new application and as Default device type select Raspberry Pi 3 and not the one that says using 64bit OS. Like this your docker.template will get the 32bit Images.
After that add to the Docker file the steps that you did manually (SSHing into the device) and let us know how did that work out
Thanks!
Subtlety I didn’t notice before… I set the application with “default device type Pi3”. But when I create the device, I have to pick again. What do I say Pi3 or Pi3-64?
Hi there.
You should choose the Pi3 and not the Pi3-64 version.
Qualified success. It works!! No more mmal error.
But I am running my 64 bit processor at 32 bits. Wasting money and performance.
Does this establish that there’s a bug in your support of Pi3+? Is there a fix in the works?
Glad to hear it is working Pito. No, this not a bug on our side, this is a software package that does not offer 64-bit compatibility. The authors of that software / application have targeted their code at Raspbian, which is a 32-bit operating system. If in the future they offer 64-bit versions, then you would be able to run it in a 64-bit container, on the 64-bit balenaOS. Thanks.
That is really interesting to know! Could you help me and let me know how you figured that out and what the package is that we are talking about. Is it mmal or something else?
It just occurred to me that this same software stack works outside of the Balena environment on the same Raspberry Pi, but running in 32 bit mode.
Hi
Take a look at this issue on the Raspberry Pi’s GitHub - https://github.com/raspberrypi/userland/issues/460
This mmal thing for ROS is apparently something people run into often. See this particular comment there - https://github.com/raspberrypi/userland/issues/460#issuecomment-383151653
Pretty interesting… But do you know how come I don’t have that problem when running the exact same stack on the exact same hardware? I mean I am using the Ubuntu 18.04 image from Belana and the same one directly.
Pito Salas
Faculty, Computer Science
Brandeis University
Hi Pito,
I am not sure I understand your question. Can you please explain more?
Thanks,
Zahari
Recall that I only get that mmal error when I try to do the build on Balena for a Raspi 3+ 64bit. And that the problem doesn’t appear when I run it on Balena for a Raspi 3+ but in 32 bit mode. It was proposed that mmal was designed for Raspian and that the developers of mmal say that they dont or can’t support 64 bit. That sounds plausible. Except:
I tried instead of using Balena at all, to create a microSD card with a normal Raspi image, including Ubuntu 18.04 (64bit) and all the same software that I install with the Dockerfile. When run it on the same Raspberry Pi and everything works, I don’t get the mmal error.
So I think that calls into question whether the mmal problem is intrinsic to trying to run Ubuntu 18.04 and my software stack on 64bit Raspi.
Thanks for the clarification, Pito. Looking at Ubuntu docs ( https://wiki.ubuntu.com/ARM/RaspberryPi ) , I see the following:
arm64 is the Debian port name for the 64-bit ARMv8 architecture, referred to as 'aarch64' in upstream toolchains (GNU triplet aarch64-linux-gnu), and some other distros.
BCM2837 is the chip used in the Raspberry Pi 3 and in later models of the Raspberry Pi 2 (board revision V1.2). It packages a 64-bit quad-core ARM Cortex A53 (ARMv8) CPU with VideoCore IV GPU.
There is a config.txt entry to make the ARM start in 64-mode (otherwise 32-bit mode is used):
arm_64bit=1
(This will fail to boot unless you provide a kernel/uboot compiled for 64-bit mode)
64 bit versions of the linux-raspi2 kernels were introduced in Ubuntu 16.10 (Yakkety Yak).
can you confirm you are setting that value in your Ubuntu 64bit test?