Two years after completing the Self-Driving Cars with Duckietown MOOC on edx I decided to dust off my Duckiebot and go back to play with it to apply some of the things I learned in the last couple of years.
This repository contains the notes I collected to document this endeavor.
It seems that the version I own is the DB21M.
The first challenge was charging the battery after two years in order to power up the bot.
I plugged the bot and tried to power it up - Note: using the side button in the battery, not the button at the top which is only to power down.
The robot wouldn't boot. The LEDs lit up in odd colours, but the screen didn't work. After a while I noticed the fan in the Jetson would start to power up briefly and then power down again.
Handling instructions in the docs were not fully self explanatory. After searching the docs and Slack, I came to the conclusion that the battery was totally drained and followed the advice in the docs FAQ and in Slack to unplug the HUT cables going to motors and Jetson, and letting only the cables needed to charge the battery for 5+ hours.
After about 30' charging in this way, I plugged the cables and tried again to power up. This time the fan started, the wifi dongle started to blink blue... and then it shut off - before the screen ever switching on. Well, it seems I am moving in the right direction, but we need the battery to charge longer.
Note: browsing the section on circuits and batteries of the docs I came across the description of the so-called battery protection mode by which a depleted battery may go into hibernation and remain unresponsive during about 30' while trickle charging to a safe level.
Note: USB cables from left to right
- to Jetson
- to battery
- to mains
- to motors and LEDs
Unplug 3 from the mains when the battery is charged then connect cables in this order: 2 - 4 -1 (cfr steps 65-67 of the assembly instructions)
To be continued...
After the whole night charging, I tried again but the booting process did not complete. There was no blinking of the wifi dongle and when I plugged in a screen to see what was going on the screen froze with a Nvidia logo.
I assumed at some point the SD card got corrupted - perhaps when it attempted to boot and run out of battery or one of the times when I forcefully unplugged the Jetson...
I decided to install software in the laptop and flash the SD again following the docs step by step.
Note: I am using Ubuntu 20.04 instead of the recommended 22.04.
$ sudo apt update
$ sudo upgrade
$ sudo apt install -y python3-pip git git-lfs curl wget
$ pip3 version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)
Remove any older versions of Docker (there were none)
$ sudo apt-get remove docker docker-engine docker.io containerd runc
Set up the apt repo containing Docker
$ sudo apt-get update
$ sudo apt-get install ca-certificates curl gnupg
Add the official GPG key
$ sudo mkdir -m 0755 -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
Set up the repository
$ echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Update again and install Docker Engine and Docker Compose:
$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
$ sudo apt-get install docker-compose
Add the current user to the docker
user group
$ sudo adduser `whoami` docker
Note: I had to restart for this change to take effect
Checkpoint (should be docker version > v1.4.0 and buildx
version > v.0.8.0):
$ docker --version
Docker version 24.0.6, build ed223bc
$ docker buildx version
github.com/docker/buildx v0.11.2 9872040
Test docker:
$ docker run hello-world
Hello from Docker!
...
$ pip3 install --no-cache-dir --user --upgrade duckietown-shell
Do $ nano ~/.bashrc
to add the following lines to the end of ~/.bashrc
in order to make local binaries accessible to the system:
...
# make Duckietown shell local binaries accesible
export PATH=~/.local/bin:${PATH}
Save the file and source it by closing and reopening the terminal or running $ source ~/.bashrc
to apply the change.
Check it works:
$ which dts
/home/mhered/.local/bin/dts
Set version to daffy
:
$ dts --set-version daffy
Duckietown Shell (v5.5.10)
INFO:dts:Configured dts to version: daffy
...
Log in to Duckietown with the Github user, copy the Duckietown token and pass it to dts
with:
$ dts tok set
...
Enter token: ****************
dts : Correctly identified as uid = ****
Checkpoint:
$ dts version
Duckietown Shell (v5.5.10)
INFO:dts:Commands version: daffy
INFO:dts:Checking for updates in the Duckietown shell commands repo...
INFO:dts:Duckietown shell commands are up-to-date.
...
$ dts tok status
...
dts : Correctly identified as uid = 3372
Login to DockerHub (login:mhered/pwd: >9 letters)
Create an Access Token : username -> Account Settings -> Security -> New Access Token
Test the token from the docker CLI:
$ docker login -u mhered
Password:
...
Login Succeeded
Provide the docker credentials (login and token) to dts
:
$ dts config docker credentials set \
--username mhered \
--password ****************
...
INFO:dts:Docker access credentials stored!
Checkpoint:
$ dts config docker credentials info
...
INFO:dts:Docker credentials:
registry: docker.io
username: mhered
secret: ****************
Note: Duckietown and DockerHub credentials are stored unencrypted in ~/.dt-shell/config.yaml
Note: repeat this process if a new access token needs to be generated.
Tried and failed to read or format the SD (both in Ubuntu and Windows) until I came to the conclusion if was fried and bought a new one.
The GUI failed to launch with a page not found error (why?):
$ dts init_sd_card --gui
...
File "/home/mhered/.local/lib/python3.8/site-packages/dockertown/utils.py", line 220, in run
: raise DockerException(
: dockertown.exceptions.DockerException: The docker command executed was `/usr/bin/docker exec c8ce09d93cf92fa64615eac9417fe079329dfe30de65c8eebfbe511c41581864 sleep infinity`.
: It returned with code 1
: The content of stdout is ''
: The content of stderr is 'Error response from daemon: Container c8ce09d93cf92fa64615eac9417fe079329dfe30de65c8eebfbe511c41581864 is not running
: '
WARNING:dts:Please update "pip" to have better debug info.
dts : To report a bug, please also include the contents of /home/mhered/shell-debug-info.txt
So I used the CLI:
$ dts init_sd_card --hostname patobot --type duckiebot --configuration DB21M --wifi MY_WIFI:MY_PWD --country ES
The CLI will ask to accept 3rd party licenses, request the SD size (32) and ask to select the device to be flashed (in my case /dev/sda/
WARNING!! Be careful you could wipe your hard drive).
Then there are 3 long steps: download took 2-3h, then flash 30' and verify.
Default username and password in case you need to log in manually: duckie
/ quackquack
I flashed a new SD card and put it in the duckiebot, and finally managed to get it to boot: wifi dongle flashing, LEDs go white and the bot screen powers up. Battery was showing at 0% in the screen so I plugged it in.
The bot was not detected by dts:
$ dts fleet discover
NOTE: Only devices flashed using duckietown-shell-commands v4.1.0+ are supported.
| Type | Model | Status | Hostname
| ---- | ----- | -------- | --------
First I realized that the network configuration was incorrect, which I fixed plugging the SD in the laptop, opening a terminal in folder /etc/
(inside the SD) and manually editing the config file $ sudo nano wpa_supplicant.conf
, see here
Still didn't work so I plugged a screen to the bot and noticed many messages similar to tegra-i2c 7000c700.i2c no acknowledge from address 0x50
. One potential explanation is apparently that there are peripherals incorrectly powered. This together with the 0% battery indication made me decide to leave the bot charging overnight (to be honest I doubt the battery would be healthy and I have actually cycled it a few times since the last charge). Note Duckietown Stack Overflow offers many other explanations to these messages (including unplugged cables, a faulty Jetson, etc.)
While at it, this is apparently the proper sequence to power up:
- Get to a stable starting state: cable to both the first and last ports of the HUT are pulled out, battery has been charging for more than an hour, known good SD card has been inserted into the nano
- Unplug the charger cable from the charger and/or the HUT
- Plug in the cable to the first and last ports of the HUT
- Depress the button on the battery once
- Wait till the wifi dongle is blinking and depress the dashboard button on top of the robot once
To be continued...
After all the night charging battery shows 24%. Boot works but does not connect. Wifi dongle blinking in cycles of 11 blinks(?) then pause.