-
Notifications
You must be signed in to change notification settings - Fork 2
2. Setting up your environment
In Windows, we need to install Ubuntu 22.04 (Jammy) under WSL 2. This is only possible on Windows 10 version 2004 and higher or Windows 11. To do so, open the Windows command prompt as administrator and run wsl --install. Once that's done, restart your computer and open the Terminal application (Use the search bar if you need to, I also recommend pinning it to your taskbar once its open). Click on the "v" next to the "+" in the top bar, go to settings, and change "Default profile" to "Ubuntu" (If Ubuntu doesn't appear as a possible choice, it was not installed properly, try wsl --install again). Then, under the "Profiles" section, find your Ubuntu profile, and enable "Run this profile as Administrator". Finally, press the "+" to open your Ubuntu terminal. Run cd && git clone https://github.com/mcgill-robotics/drone to be on the same page as Mac users.
In Mac, we don't have WSL and thus have to go through the normal means of getting a virtual machine. Install VirtualBox, this will be our virtual machine's type 2 hypervisor. Depending on if you have an Intel chip (amd64) or an Apple Silicon chip (M1/M2) (arm64), you will need to install a different image (.iso) file of Ubuntu 22.04 (Jammy). For Intel chips, download the x86_64/amd64 image. Otherwise, download the arm64 image. Open VirtualBox, go to Machine -> New, give your vm a name and select the ISO file you just downloaded. Enter a new username and password (or keep the default). Allocate as much Base memory and as many Processors as you can while still staying in the green zone. Give the vm around 70 GB for the Disk Size. Then press Finish. This should launch the vm, which may launch an installer, follow the steps of the installer if you need to do so. Once at the installer is done, you should be prompted to enter your username and password. Once you have your command prompt, run cd && git clone https://github.com/mcgill-robotics/drone && cd drone/setup_scripts && source setup_ubuntu.sh. This will install a graphical user interface, which is going to make your life easier and make it possible for you to run the Gazebo server. The user interface the script installs is the i3 window manager, which is a tiling window manager. For now all you need to know is that to run a terminal emulator (get a shell prompt), you press <Alt>+<Enter>, but there are plenty of other key combinations to perform various actions. More information can be found here and it's configuration file is under ~/.config/i3/config.
We need to clone the PX4 repo and to install ROS2 humble, Gazebo classic 11.10.2 and PX4's build dependencies. These can be done through the setup_tools.sh script under setup_scripts. Run cd ~/drone/setup_scripts && source setup_tools.sh. This will take a while so carry on to the next section while it's running. Avoid killing the virtual machine in the meanwhile or turning off your computer and keep an eye on it as it may prompt you for your sudo password again.
We need Gazebo version 11.10.2 running natively, Gazebo is the simulator we use. We will do so by using the Conda package manager.
- Install MiniConda by selecting the right installer for your OS, make sure to check the add to PATH box during the installation to not have to do it manually later
- Open the command prompt
- Search for cmd.exe on Windows
- Search for Terminal on MacOS
- Run
conda install gitin the prompt if you don't have git - Once that's done, run
conda create -n ros_env && conda activate ros_env- This creates a Conda environment which is self-contained, similar to a python venv, named "ros_env"
- Then you run conda activate to enter said environment
- This should prefix your prompt with "(ros_env)"
- Later, you can run
conda deactivateto exit the environment - More on managing conda environments here
- Run
conda config --env --add channels conda-forge
conda config --env --add channels robostack-staging
conda config --env --remove channels defaults- This ensures packages are installed from conda-forge or robostack-staging
- Install Gazebo 11.10.2 by running
conda install gazebo=11.10.2 - Once the install is done, close your terminal
- From a new terminal, run
conda activate ros_env, then try runninggazebo --version- This should not throw an error
- Run
gazeboin your terminal, this should open a GUI - Close the GUI (either CTR+C from the terminal or press the x at the top right of the gazebo GUI)
- From the terminal change directory into your home directory
- In Mac and Linux, this can be done with
cd ~ - In Windows,
cd %userprofile%
- Run
cd .gazebo && git clone https://github.com/PX4/PX4-gazebo-models.git
- We need the various meshes and scripts inside this repository so that our gazebo client can render the simulation properly
- Move all of the files and folders of the cloned repository to the .gazebo directory
An IP addresses is a number that identifies a device on the internet or in a local area network (LAN), namely, public IP addresses are used for the internet while private IP addresses are used for LANs. IPV4 addresses are composed of 4 bytes, then shown with a period seperating the various digital values of the bytes. IP addresses aid in the internet layer. Once we have the right machine through the IP address, a port is a number used to identify a connection endpoint on a computer. Ports aid in the transport layer. TCP and UDP are 2 common transport layer protocols. Through the Internet Protocol suite (TCP/IP), data is sent in small chunks called packets. TCP is reliable, sends one packet at a time and makes sure the current packet is received before sending the next. UDP is best effort, sends packets without bothering to check that the previous packet got to it's destination. They are both useful and are used for different use cases. UDP may be used for a video game's communication where we only care about the latest state of the game, while TCP may be used for a file transfer where the protocol's reliability is necessary to ensure no parts of the file is lost. On top of the transport layer sits the application layer. This layer has various protocols such as HTTP, SSH, NTP, etc. These usually are always used with either TCP or UDP, HTTP is for instance always used with TCP. A Uniform Ressource Identifier (URI) is a sequence of characters that distinguish one ressource from another, a Uniform Resource Locator (URL) is a type of URI. URIs may be composed of 4 parts: a scheme name, authority, path, query and fragment. Only the schema name, autority and path are mandatory. The scheme name may be the application protocol. For instance, http://192.168.0.3:1134/ has http as the scheme name, 192.168.0.3:1134 as the authority (which is an IP:Port composition named a socket) and / as the path. A firewall is a network security device that monitors traffic to or from a network. It allows or blocks traffic based on a defined set of security rules. These could be rules like allow all communication from any IP address on a specific port or block all communication from a specific IP address on all ports.
Local Area Networks allow 2 computers to communicate without going through the internet. Imagine, if you may, that the internet is like the postal service. In this metaphore, why would you go through the postal service if you want to deliver a mail to your neighbor ? Just go to his address and deliver the mail for him directly. Not only is this faster, but this also means that a postal service isn't even needed in the first place, communication can be done without the internet. Private IP address are used in the context of LAN communication and come with an address mask, which can be used to easily tell if another IP address could be in the same LAN. For instance, 192.168.0.0/16 is a private IP address a forward slash and a network mask (in number of bits), this says that all IP address starting with the same 16 bits (2 bytes) as the IP address, all addresses starting with 192.168.x.x, could be reachable without needing to go through the internet. The IP your computer as well as the network mask are defined by your router, or can be statically set then need to match on another computer on the same network for both computers to communicate (netmask mask compliant but different IP addresses + same network mask). More on private IP addresses.
We need our host and our VM/WSL machines to be in the same network, and we need to set the GAZEBO_MASTER_URI variable to both the client and server gazebo instances to be a URI inside the VM/WSL instance. We also need to configure the firewall on the VM/WSL and on our host machine to allow communications between the 2 computers.
On Ubuntu, you run the command ip a to see all your network adapters and your ip address/netmask for each adapter, or ifconfig.
On WSL, the network adapter of interest is called eth0 and everything should work out of the box. Copy the IP address (also called inet) you get for the eth0 adapter from your WSL, run export GAZEBO_MASTER_URI="http://<the_WSL_ip_address_here>:11345" on the WSL instance, and run set GAZEBO_MASTER_URI=http://<the_WSL_ip_address_here>:11345 on your command prompt. This will tell gazebo server and client where to find the gazebo master, syncing both applications and allowing them to communicate whenever they are running. This step needs to be done everytime.
This is slightly more complicated than the setup for WSL. You go into the settings for your VM, into network and change the adapter's "Attached to" setting from NAT to bridged.
Run the docker container using docker run -it --privileged -e DISPLAY:=0 -p 14570:14570/udp -p 11345:11345 unhappysquid/drone_a1.
From the docker container, run HEADLESS=1 GAZEBO_IP=$(ip a | grep 'eth0' -A 3 -m 1| grep 'inet' | awk '{print $2}' | awk -F"/" '{print $1}') make px4_sitl gazebo-classic_standard_vtol. From the native environment, open your terminal, activate your conda environment, run gzclient --verbose
We want a way to have our system run the simulation smoothly to make development enjoyable, this requires GPU accelerated graphics. In the case of a graphics card that is within the same chip as the CPU, a virtual machine or WSL should work fine. The issue arises when the computer has a dedicated GPU, thus making it complicated for the simulator to access the GPU from a virtual machine. Without a hypervisor type 1, only one OS can use the GPU at a time, meaning only the host OS uses the GPU, meaning no GPU for our virtual machine. Not to mention that a good proportion of students use mac, so our solution should be OS agnostic. In the bellow list, + means a positive aspect, - means a negative aspect, X means a dealbreaker
- Dual booting
- - Non-trivial to set up
- X Not universal, notably, complicated on Mac.
- - Trickier to restart from 0 than virtual machines
- + Bare metal performance
- WSL by itself
- X Requires Windows machine
- - Doesn't work with some GPUs, notably Intel Iris Xe GPU
- + Supports most GPUs
- + As easy to experiment with as any virtual machine, can always scrap it and restart from new
- Virtual machine by itself
- X Doesn't work with GPUs at all
- Docker for tool set + Gazebo ignition running natively
- + Can easily share an image with all the tools needed for development
- Supported platforms for gazebo
- X Gazebo's Windows support doesn't include the GUI at the time of writing
- - Untested on Mac
- Docker for tool set + AirSim running natively
- + Can easily share an image with all the tools needed for development
- + Runs on top of Unreal Engine, making it ideal for realistic computer vision
- X AirSim doesn't work on MacOS
- - Microsoft, AirSim's developers, have stopped working on it since 2022
- Colosseum is a successor to AirSim which supports PX4, sadly only for multi rotors as well
- - Only supports PX4 multi rotor, no VTOL
- Docker for tool set Gazebo server + Gazebo-classic client running natively
- + Can easily share an image with all the tools needed for development
- - Gazebo-classic is reaching end of life in 2025
- Hopefully by the time it reaches end of life, gazebo ignition will work on more than just Linux
- + Easy to setup
- + Uses Conda for Gazebo which is cross-platform
- + Gazebo classic works on all platforms (supposedly), meaning simulation is running natively
- X Docker desktop doesn't support x11 which is needed by Gzserver
- No way around Docker desktop on Windows and Mac
- (WSL for windows, VM for mac) for tool set and Gazebo server + Gazebo-classic client running natively
- - A bit more complicated to setup
- + Uses Conda for Gazebo which is cross-platform
- + Gazebo classic works on all platforms (supposedly), meaning simulation is running natively
sudo apt remove gz-garden
sudo apt install aptitude
sudo apt autoremove
sudo aptitude install gazebo libgazebo11 libgazebo-dev