-
ROS2 Headaches.
01/02/2024 at 13:02 • 0 commentsFirst step to get anywhere is to get ROS2 and the camera working. Which ideally would have been a matter of some apt-gets. Except there were a few complications:
- ROS2 is native to Ubuntu LTS.
- Latest LTS is Ubuntu 22.04.
- Camera Module 3 is a new module from 2023 and requires the latest camera library and Kernel Drivers. Otherwise it ain't detected.
- Only the new Debian based Raspberry Pi OS and Ubuntu 23.10 have this.
- So no native binaries exist...
This means that i don't get a easy "apt install ros-iron" and call it a day. Either i need to get the driver working on the older distro, wait till may 2024 for a new LTS ubuntu + ROS2, or get ROS2 working on the newer via alternative means. Since the driver is meant for a significantly newer Linux Kernel and i know nothing about drivers, the former is pretty much off the table. I gotta find a different way to get ROS2.
There are two ways to do this. Either i build it myself OR i use a Docker container.
I would prefer not to wrestle with docker just yet, even though it is the easiest way to get things running. If i can run something without any overhead i'd rather use that. so i figured building ROS2 would be worth a try. I can always try to migrate to a newer Distro with Docker later and see if it has any impact.
Let me pre-empt by saying I came to regret this decision and urge anyone to just use the 24.04 LTS+ROS2 Jazzy (if available by time of completion) or use Docker to run it on Raspberry Pi OS. The following is more for the curious/brave. Took weeks to get things compiled and working on a Zero2 (memory contraints). NO Guarantee the following even works!!!
How to BUILD ROS2 on RPi Ubuntu Server 23.10:
This is assuming a freshy flashed OS just booted into for the first time and is being accessed via SSH.
Step 1) Prep the Distro.
First things first. Ubuntu doesn't start with swap space, which isn't a good thing on a tiny pi like the zero2. Gotta get that fixed, preferably before the Kernel starts to throw a fit and the Pi freezes. First we allocate about 2Gb to a swapfile, Give it permissions and than make it a swap.
sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile
We now have a 2GB Swap file ready and active. To make it permanent, we open up the fstab file:
sudo nano /etc/fstab
And add as entry:
/swapfile swap swap defaults 0 0
So that it will always be active whenever the Pi is started.
After that we go through the apt upgrade and apt update routine (you should know how it goes)
Step 2) Get the prerequisites
Time to get the first set of prerequisites needed. Run the following command:
sudo apt install -y git colcon python3-rosdep2 vcstool wget python3-flake8-docstrings python3-pip python3-pytest-cov python3-flake8-blind-except python3-flake8-builtins python3-flake8-class-newline python3-flake8-comprehensions python3-flake8-deprecated python3-flake8-import-order python3-flake8-quotes python3-pytest-repeat python3-pytest-rerunfailures python3-vcstools tmux
This should hopefully get every that is needed. If some parts don't install, note them down for later checking. Some python parts may not want to install via the
apt install
approach. Often you can try to forcefully install them anyway via "-pip install (PACKAGE) –break-system-package
". The break package flag tells it to ignore the system package manager and do it anyway.Step 3) Prep the source and get the ROS dependancies
mkdir -p ~/ros2_iron/src cd ~/ros2_iron vcs import --input https://raw.githubusercontent.com/ros2/ros2/iron/ros2.repos src sudo rm /etc/ros/rosdep/sources.list.d/20-default.list
sudo apt upgrade sudo rosdep init rosdep update rosdep install --from-paths src --ignore-src -y --skip-keys "fastcdr rti-connext-ds-6.0.1 urdfdom_headers"
With this. Everything should be there to let one build. But don't do it yet!!
Step 4) Ignore unused parts
Now it is of vital importance to start disabling parts we ain't going to use. Especially if you are using a tiny pi like the Zero2. If you don't. It will try to build very large components we don't need like Navigation, desktop components and 3D Robotic visualization stuff that will overflow rapidly into SWAP and cause the building to take bloody MONTHS....
The trick to do so. Is to make liberal use of the "COLCON_IGNORE" flag file. This is a empty file that if found by colcon in a folder, causes it to ignore everything inside that folder. Carefully placing it here and there can help cut down the work by like 90% really. To make it convenient to spread it around. I used winSCP to get a explorer like window through which to easily copy-paste the flag file.
Here is a list where i dropped some Ignores:
- /ros2/rviz/
- /ros-perception
- /ros-planning
- /ros-tooling
- /ros-visualization
Step 5) Build & Pray!
Now to pull the trigger.
First things first: Be sure you are in a tmux session.
This process will take AGES and you'd rather not have it stop the moment you close the SSH session or connection drops. Once inside a tmux session: just enter ros2_iron folder (if not already there) and execute the command:colcon build --symlink-install --executor sequential
The PI will start working on compiling ROS2 for you.
Astute may notice the Executor flag. This forces the system to work on each package individually in sequence, rather than try to work on multiple in parallel. This is mainly for the sake of memory as running multiple compilations at the same time quickly fills it up and if that happens compilation will go at less than 10% speed. If your Pi is beefier you can swap it out with "
--parallel-workers 2
" to make it use two threads or just omit the flag all-together to go full-throttle. For such users this shouldn't take too long.While its busy, Detach from the tmux session (CTRL+B followed by D), close the SSH and just walk away and do other things. You can tell your Pi is still busy by its activity led blinking like mad. Once it goes solid it means either the process is done (yay) OR something has gone horribly wrong (Frik). This can take a few days really...
If everything goes well you shouldn't have had any major errors. Only error is Python pleading to not use a deprecated easy_install method, but that can't be helped. Colcon will claim packages have failed because of this, but that isn't really the case. TMUX makes it hard to see if anything major happened (can't scroll up ) so it might be worthwhile to run colcon again in a normal session to verify.
IF you manage to do everything. Be sure to backup your card just in case.
-
Concept
12/06/2023 at 19:15 • 0 commentsFirst things first. Trying to figure out some things to look at and experiment with.
Mechanical
The idea isn't the most complex. No actual mobility is needed it just needs to be able to emote. For which the ability to move its head should be enough along with some OLED eyes. I came up with an idea involving 6 servos. 3 for the head movement, 1 for the neck (to tilt forward/backwards) and two for ears.
Overall skeletal structure would be akin to your typical Egyptian cat statue posture. Body holds logic with ribbon cables going to the various components. Outer shell is mounted with screws onto the skeletal structure. Initial aim is for a low-poly look. Cause i think it would make my life a little easier and not look ghastly for a first try.
Only thing i am not certain on. Is how to deal with the Camera. I am dead set on using a wide-angle camera. They give a very wide field of view (about 120 degrees) which makes them ill-suited for photos, but great for detection. Mounting in the head would be the obvious way, but the wide view may be enough for a torso mount. Something to try out first.
Hardware
This will take a bit more than your average controller to pull off. So a single-board computer is the obvious choice and on that the Raspberry family stands unrivaled. Plus they apparently aren't made out of unobtanium anymore.
Gonna try to get the job done with a Zero2 first. It is the smallest and the lack of USB and Ethernet is of no concern for this project. Only limitation is Memory. At 512Mb it doesn't have that much room, but by going headless it should be possible to keep memory use low enough.
To handle some of the more specific I/O such as controlling the servos a RP2040 is to paired up as a co-controller. A advantage is that the Raspberry itself can program the RP2040 by bitbanging a SWD interface.
The main form of input will be a Camera. Ideally the Camera Module 3 Wide is used as its wide field of view is great for detection tasks.
Other inputs are figured out as i go along.
Software:
This kind of scope project is kind of annoying to do in a single program. So many components that need individual testing, calibration and constantly iterating. Since the project is already planned to be realized on a single board computer with regular Operating System, it makes sense to utilize its ability to handle task scheduling and divide the project over multiple individual programs that together make up the animatronic's software.
To let the processes operate in tandem a method of inter-process communication is needed that lets them pass data between eachother. e.g. the Vision program tells the behavior Agent that a face was spotted, the behavioragent then tells the animation program to track, etc. The most common way is to use something that enables Inter-Process Communication. A simple Subscriber/Publisher or Request/Reply message system should do the trick.
Ideally i would be able to use the Robot Operating System 2 (ROS2), which was specifically intended for this kind of task. It gives any CPP/Python project run through it, access to a Data-Distribution-Service (DDS) that enables them to discover each-other and pass messages to one another. It is however not the easiest to get working as it is maintained specifically for the Ubuntu Operating system. For others you gotta build it yourself.
Alternatively if it proves difficult to get operational (you never know with Embedded linux). ZeroMQ can act as an alternative. Much like ROS2 it enables processes to pass messages to eachother, but instead of using a DDS it uses more conventional methods such as TCP for inbetween devices or a local file that acts as a bridge inbetween processes. It is lightweight, but the use of a in-between file means hammering the flash storage with constant writes. I'd rather avoid that.
Should be enough to get a start.