diff --git a/src/book/02-system/02-subsystems/06-behaviour.mdx b/src/book/02-system/02-subsystems/06-behaviour.mdx index c42def315..f78adb5b9 100644 --- a/src/book/02-system/02-subsystems/06-behaviour.mdx +++ b/src/book/02-system/02-subsystems/06-behaviour.mdx @@ -102,7 +102,7 @@ To use this module, build the [PS3Walk role](https://github.com/NUbots/NUbots/bl ### Script Runner -[ScriptRunner](https://github.com/NUbots/NUbots/tree/96357855b059cd499021552b3e25a4b158828dc5/module/behaviour/tools/ScriptRunner) is a purpose-level module. It takes the name of one or more script files as arguments and attempts to run the scripts. It does not take file paths, only the file name/s of the script/s to execute. +[ScriptRunner](https://github.com/NUbots/NUbots/tree/8bfdde1ac3f51764515908dd514e653f6b38cf04/module/purpose/ScriptRunner) is a purpose-level module. It takes the name of one or more script files as arguments and attempts to run the scripts. It does not take file paths, only the file name/s of the script/s to execute. When ScriptRunner is executed, it stores the script file names passed to it as a vector of strings. When the green button on the robot is pushed, the scripts are executed in order of appearance, one after the other. ScriptRunner also provides an option to set a delay before the execution of the first script, as well as a delay between the execution of each script. @@ -114,7 +114,7 @@ An example of using ScriptRunner to run a script called `Stand.yaml` is: ### Script Tuner -[ScriptTuner](https://github.com/NUbots/NUbots/tree/96357855b059cd499021552b3e25a4b158828dc5/module/behaviour/tools/ScriptTuner) is a purpose-level module. Using a command-line argument, it can either create a new script or open an existing script for editing. It uses [curses]() to create a user interface in the terminal. Through this user interface, YAML files are created or edited that specify a script that can then be used by other modules. +[ScriptTuner](https://github.com/NUbots/NUbots/tree/0a948978ba5806ee532bc1120a76e9e58c4e6533/module/purpose/ScriptTuner) is a purpose-level module. Using a command-line argument, it can either create a new script or open an existing script for editing. It uses [curses]() to create a user interface in the terminal. Through this user interface, YAML files are created or edited that specify a script that can then be used by other modules. A script consists of frames (also called targets) which specify the position of one or more servos at a given time. The ScriptTuner interface allows for stepping through and modifying those frames. When a frame is selected in ScriptTuner, a ServoCommand for that frame will be emitted to the robot. By stepping through multiple frames, the entire script can be played back on the robot, allowing the user to preview changes to the script. diff --git a/src/book/03-guides/01-main-codebase/01-getting-started.mdx b/src/book/03-guides/01-main-codebase/01-getting-started.mdx index 9762506c2..add46031d 100644 --- a/src/book/03-guides/01-main-codebase/01-getting-started.mdx +++ b/src/book/03-guides/01-main-codebase/01-getting-started.mdx @@ -11,13 +11,13 @@ authors: - Lachlan Court (@LachlanCourt) --- -Throughout this guide we will focus on completing a specific example task. This task will involve setting up the codebase, running the fake/keyboardwalk binary (which uses simulated hardware) and seeing the robot move in NUsight. +Throughout this guide we will focus on completing a specific example task. This task will involve setting up the codebase, running the `fake/keyboardwalk` binary (which uses simulated hardware) and seeing the robot move in NUsight. ## Prerequisites ### Git -For our example, we will need Git to get the codebase. This will happen later in this guide. +For our example, we will need Git to get the codebase later on in this guide. [Git](https://git-scm.com/) is a [version control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) tool. We use it to track changes to the codebase and work together on the same codebase without getting in each other's way. @@ -39,52 +39,25 @@ You will need to perform the steps correctly to set up Docker for your operating
-Ubuntu/Linux Mint +Ubuntu -To install on Ubuntu, use the [official Docker instructions](https://docs.docker.com/engine/install/ubuntu/). These work with Linux Mint, with some adjustments. There are multiple ways to install Docker, as detailed on the website. NUbots recommends the following for installing Docker +To install on Ubuntu, use the [official Docker instructions](https://docs.docker.com/engine/install/ubuntu/). These instructions should work for Ubuntu-like Linux distributions, such as Pop!\_OS. There are multiple ways to install Docker, as detailed on the website. NUbots recommends the following for installing Docker -1. Navigate to the section where you [Install Docker using the Repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository). Complete the three steps under the heading 'Set Up the Repository'. +1. Navigate to the section for [installing using the Apt repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository). Complete the three steps under this section. - If you are using Linux Mint, please read the info bubble below. - - - - The third step will not work on Linux Mint for two reasons. - - 1. You will get a malformed input error. Removing `[arch=amd64]` fixes this. - - 2. You cannot use the command `$(lsb_release -cs)` on Linux Mint. This command returns the name of the Ubuntu LTS. On Linux Mint, you will need to manually enter the LTS name. - - If you are using the latest Linux Mint version, 'Ulyana', you will need to replace the command with `focal`. This refers to the Ubuntu LTS that Linux Mint Ulyana is build off, 'Focal Fossa'. - - If you are using an old version of Linux Mint, you can find out what Ubuntu LTS it uses on the [Linux Mint all downloads page](https://www.linuxmint.com/download_all.php). For example, if you are using Linux Mint Tricia, use `bionic`. - - If you are using Linux Mint Ulyana - the latest Linux Mint version - then your command for step three will be - - ```bash - sudo add-apt-repository \ - "deb https://download.docker.com/linux/ubuntu \ - focal \ - stable" - ``` - - - -2. Complete the three steps under the heading 'Install Docker Engine', which is just below the previous section, 'Set Up the Repository'. After you complete this step, you are finished with the Docker install page. - -3. Install python3 and pip. +2. Install python3 and pip. ```bash sudo apt-get install python3 python3-pip ``` -4. Add the current user to the Docker group, so you can run Docker commands without `sudo`. +3. Add the current user to the Docker group, so you can run Docker commands without `sudo`. ```bash sudo usermod -aG docker "${USER}" ``` -5. Reboot to make the group change take effect. +4. Reboot to make the group change take effect.
@@ -228,7 +201,7 @@ Run all these commands for our example, and pay special attention to the instruc To build the code, open a terminal and change into the NUbots code directory. Then do the following: -1. Select the platform (e.g. type of computer) that the built binaries will run on and create the Docker image. You do this by running the command: +1. Select the platform (type of computer) that the built binaries will run on and create the Docker image. You do this by running the command: ```bash ./b target @@ -237,7 +210,7 @@ To build the code, open a terminal and change into the NUbots code directory. Th Replace `` with your desired platform. The available platforms are: - `generic` - used to build the code for a "generic" computer. This will enable you to run the built binaries on the computer you're building the code on. - - `nuc7i7bnh` - used to build the code for the platform that the robots run on. This will build binaries that are optimised for the NUgus robots. + - `nuc12wshi7` - used to build the code for the platform that the robots run on. This will build binaries that are optimised for the NUgus robots. If you are following the example, use `generic`. @@ -248,11 +221,11 @@ To build the code, open a terminal and change into the NUbots code directory. Th ./b configure -i ``` - Note that you will need to do `configure` without `-i` the very first time you do this. Using `-i` will show a menu that will allow you to choose the roles to build. Enable the roles you want to build and disable the ones you don't by highlighting them using using the ↑ and ↓ arrow keys and pressing the spacebar to toggle on and off. + Note that you will need to do `configure` without `-i` the very first time you do this. Using `-i` will show a menu that will allow you to choose the roles to build. Enable the roles you want to build and disable the ones you don't by highlighting them using the ↑ and ↓ arrow keys and pressing the spacebar to toggle on and off. - If you are following the `fake/keyboardwalk` example, you will need to make sure `fake/keyboardwalk` is set to `ON`. Find the list of items that are prefixed with `ROLE_` and set all to `OFF` except for `fake/keyboardwalk`, which should be `ON`. You do not need to change any other build options in this example. + If you are following the `fake/keyboardwalk` example, you will need to make sure `ROLE_fake-keyboardwalk` is set to `ON`. Find the list of items that are prefixed with `ROLE_` and set all to `OFF` except for `fake-keyboardwalk`, which should be `ON`. You do not need to change any other build options in this example. - Press c to configure. This will show a confirmation menu, press e to go back to the main menu. Press g to generate the build list, and then press e to exit. + Press c to configure. Once configuration has finished, press g to generate the build list. Press e to exit if it has not automatically returned you to the terminal. 3. Build the code by running: @@ -300,8 +273,8 @@ To run the code on a robot, you need to make sure the robot is powered on, insta Where: - - `[options]` corresponds to zero, one, or multiple options as detailed in the [Build System](/system/foundations/build-system#install) - - `` corresponds to the name of the robot such as `n1` or `nugus1` + - `[options]` corresponds to zero, one, or multiple options as detailed in the [Build System](/system/foundations/build-system#install) page + - `` corresponds to the name of the robot such as `n1` or `nugus1`, or an IP address 2. Next, open a new terminal and `ssh` into the robot by running: @@ -321,7 +294,7 @@ To run the code on a robot, you need to make sure the robot is powered on, insta In addition to the stand script, the `scriptrunner` role can run other scripts. These can be found in the `scripts` folder. See [Configuration and Script System](/system/foundations/config-script) for details. -4. You can also run other roles that are not `scriptrunner`. For example, to run the `robocup` role enter the command: + You can also run other roles that are not `scriptrunner`. For example, to run the `robocup` role enter the command: ```bash ./robocup @@ -397,8 +370,8 @@ By now you will have gone through this page and have everything set up to make t With the `fake/keyboardwalk` binary running, and with NUsight running and your browser open to [localhost:9090](localhost:9090), do the following -- Select the 'localisation' tab in NUsight. +1. Select the 'localisation' tab in NUsight. -- You will see a stationary robot. To focus on the robot, click inside the window and press space to change perspective. +2. You will see a stationary robot. To focus on the robot, click inside the window and press space to change perspective. -- To make the robot walk, go into the terminal that is running `fake/keyboardwalk` and hit e to enable walking. Use w, a, s and d to make the robot move. Note that this is a basic simulation that does not use gravity, so the robot will move its limbs but it likely won't move in the world. +3. To make the robot walk, go into the terminal that is running `fake/keyboardwalk` and hit e to enable walking. Use w, a, s and d to make the robot move. Note that this is a basic simulation that does not use gravity, so the robot will move its limbs but may not move in the world. diff --git a/src/book/03-guides/01-main-codebase/02-nuclear-tutorial.mdx b/src/book/03-guides/01-main-codebase/02-nuclear-tutorial.mdx index eb5c7b26a..820191b65 100644 --- a/src/book/03-guides/01-main-codebase/02-nuclear-tutorial.mdx +++ b/src/book/03-guides/01-main-codebase/02-nuclear-tutorial.mdx @@ -27,7 +27,7 @@ Make sure you have If the last two commands ran successfully, you are ready to go! -### The folder structure +### The Folder Structure Before getting into it, let's look at what we are working with. @@ -45,17 +45,17 @@ Other folders that are important but won't be visited in this tutorial are the f ### Generate the Module -There is a neat tool that you can run that will generate the boilerplate code for a module. Here's the command +The generate tool will create the boilerplate code for a module. Here's the command ```bash ./b module generate TestModule ``` -Run it if you haven't already done so. If you look in the `module` folder, you will see a new folder called `TestModule`! +Run it if you haven't already done so. If you look in the `module` folder, you will see a new folder called `TestModule`. This module wasn't created in a folder, but if you are making a new module in a real scenario you should identify the folder your module best fits in and put it in there. -Ok, so lets see what we have in this folder. +Lets see what we have in this folder. - **data/config**: Contains a `TestModule.yaml` file, which holds configuration values. Rather than hardcoding values in your implementation, put the values in this file so they can be easily seen and updated. This file is generated with one value, `log_level`. We will look into how this works later. - **src**: This folder contains the `.hpp` and `.cpp` files for the module. If you look in the `.hpp`, you'll see a TestModule class is declared that extends `NUClear::Reactor`. The `.cpp` file implements the constructor with one lambda statement that reads configuration values. @@ -87,7 +87,7 @@ Most of this is copied from other role files. The first three modules are necess The last module added is our new module, `TestModule`. -This should compile. Let's have a go. First we'll need to turn the role we just made `ON`. Run +This should compile. First we'll need to turn the role we just made `ON`. Run ```bash ./b configure @@ -120,7 +120,7 @@ This file will store any of values for the program that might change. It is bad Open `module/TestModule/src/TestModule.cpp`. There is one `on` statement here, the Configuration `on` statement. The code inside this function will run on startup and whenever the configuration file `TestModule.yaml` is changed. -Inside this statement, after the log_level is set, add the following code +Inside this statement, after the `log_level` is set, add the following code ```cpp log("This is a TRACE log."); @@ -131,20 +131,20 @@ log("This is a ERROR log."); log("This is a FATAL log."); ``` -`log` will print to the terminal. The log level set from the configuration file determines what level logs are printed. The log level is currently on `DEBUG`. Let's compile and run the program again. +`log` will print to the terminal. The log level set from the configuration file determines what level logs are printed. The log level is currently on `INFO`. Let's compile and run the program again. ```cpp ./b build ./b run testprogram ``` -You should see all of the logs print except for `TRACE`. This is because all logs with level `DEBUG` and higher will run. Lets change the configuration file without stopping the program! Open a new terminal and run `./b edit config/TestModule.yaml`. This will open the TestModule configuration file in `nano`. Change `DEBUG` to `TRACE`. Save with CTRL + O and then Enter. If you look at the program, you will see the logs print out again, but with `TRACE` included. Go back and change the config file to `WARN`. You will now see the logs print again, but with only `WARN`, `ERROR` and `FATAL`. +You should see all of the logs print except for `TRACE` and `DEBUG`. This is because all logs with level `INFO` and higher will run. Lets change the configuration file without stopping the program! Open a new terminal and run `./b edit config/TestModule.yaml`. This will open the TestModule configuration file in `nano`. Change `INFO` to `TRACE`. Save with CTRL + O and then Enter. If you look at the program, you will see the logs print out again, but with `TRACE` and `DEBUG` included. Go back and change the config file to `WARN`. You will now see the logs print again, but with only `WARN`, `ERROR` and `FATAL`. The log level system allows you to keep statements for debugging or tuning without the logs spamming the terminal when someone is running the module for other purposes. Remove all of the log statements. We will be making a 'ping-pong' program that sends an incrementing count between reactions. The increment size will be a configuration value. Let's add that configuration value now. -In `TestModule.yaml` (in your text editor, not in the terminal since this is not persistent), add in the following lines +In `TestModule.yaml` (in your text editor, not with `./b edit` since this is not persistent), add in the following lines ```yaml # Each time the Ping Pong messages are sent, a count is incremented and the increment is of the following size @@ -174,7 +174,7 @@ Save, recompile and check that the program prints the message. ./b run testprogram ``` -Make sure you see your `INFO` log and then lets move onto making the messages that we need. +Make sure you see your `INFO` log and then lets move onto making the messages that we need. If you can't see the log in the terminal, make sure that `log_level` in `TestModule.yaml` is set to `INFO`. ### Protobuf Messages @@ -196,7 +196,7 @@ message Pong { } ``` -There is an integer in each of these messages. This is the count that will be incremented each time a new `Ping` or `Pong` message is sent. The number it is assigned, `1`, is not the value but its position in the Protobuf message. Save this file and head back over to `TestModule.cpp`. +There is an unsigned 32-bit integer in each of these messages. This is the count that will be incremented each time a new `Ping` or `Pong` message is sent. The number it is assigned, `1`, is not the value but its position in the Protobuf message. Save this file and head back over to `TestModule.cpp`. Up at the top of the file, include the protobuf message we just created. Note that these messages are transcompile into C++ code, so include the generated header. @@ -256,7 +256,7 @@ And for the second reaction // Print the Pong message! log("Pong count", pong.count); -// Make a Pong message to send +// Make a Ping message to send auto ping = std::make_unique(); ping->count = pong.count + config.increment; diff --git a/src/book/03-guides/01-main-codebase/03-tuning-and-running-scripts.mdx b/src/book/03-guides/01-main-codebase/03-tuning-and-running-scripts.mdx index f536af129..958f30a7f 100644 --- a/src/book/03-guides/01-main-codebase/03-tuning-and-running-scripts.mdx +++ b/src/book/03-guides/01-main-codebase/03-tuning-and-running-scripts.mdx @@ -4,13 +4,15 @@ chapter: Main Codebase title: Running and Tuning Scripts description: How to tune and run scripts. slug: /guides/main/tuning-and-running-scripts +authors: + - Ysobel Sims (@ysims) --- Scripts are static motions for the robot. By static, we mean they are preconfigured motions that won't change at runtime. They specify what joint angles to move to and how long the robot should take to go to those joint angles. For example, standing up is a small script telling the robot to move its joints to the stand position over one second. There can be many of these position specifications in a row to make the robot do more complex movements like getting up or kicking. -The Script Engine executes script files by performing the robot motions that they describe. It takes each joint position and time from the `.yaml` file and sends the information to the servos, causing the robot to move. +Scripts are run using the script utility and the [Director system](/system/foundations/director). The script utility will convert a specified script yaml file into a [Sequence Task message](/system/subsystems/motion#actuation). It takes each joint position and time from the `.yaml` file and adds these frames to the Sequence of servo targets. The Sequence Provider will request a Director Task for each Group in its Sequence, and will only progress to the next Group when the previous has completed. -Information on Script Engine is on the [Motion](/system/subsystems/motion#script-engine) page. Information on Script Runner and Script Tuner is on the [Behaviour](/system/subsystems/behaviour#script-runner) page. +More information on the script system is on the [Motion](/system/subsystems/motion#scripts) page. Information on Script Runner and Script Tuner is on the [Behaviour](/system/subsystems/behaviour#script-runner) page. ## Script Runner @@ -20,7 +22,7 @@ The `scriptrunner` command will run a script. It is used as follows: ./scriptrunner ``` -Where `` is the name of the script you want to run, such as `Stand.yaml`. All scripts can be found in the NUbots repository under `/module/motion/ScriptEngine/data/scripts/`. +Where `` is the name of the script you want to run, such as `Stand.yaml`. All scripts can be found in the NUbots repository under `/shared/utility/skill/scripts`. The script you are running needs to be on the robot in the `/scripts/` folder. These scripts can be robot specific. For example, you could have a stand script specifically for the NUgus 1 robot stored in `/scripts/nugus1/Stand.yaml`. When you run `./scriptrunner Stand.yaml` on NUgus 1, the ScriptEngine will first look for the robot-specific `Stand.yaml` in the `/scripts/nugus1/` folder. If found, it will execute it. If not, it will look for a platform-specific `Stand.yaml` in the `/scripts/nugus/` folder, which it will execute if found. Otherwise, it will look for a more general `Stand.yaml` in the `/scripts/` folder. @@ -107,18 +109,19 @@ The bottom of the interface shows what commands are available. It does not show ## List of Scripts -| Script Name | Description | -| -------------------- | --------------------------------------------------------------------------------------------------- | -| `KickLeft.yaml` | The robot kicks with its left foot. | -| `KickRight.yaml` | The robot kicks with its right foot. | -| `NodYes.yaml` | The robot nods its head. | -| `Relax.yaml` | The robot relaxes all of its joints. Be prepared to hold it if it's standing, as it will fall over. | -| `RelaxHead.yaml` | The robot relaxes its head joints. | -| `RollOverFront.yaml` | The robot rolls from its back onto its front. | -| `Stand.yaml` | The robot moves into a standing position. | -| `StandUpBack.yaml` | The robot gets up from its back and moves into a standing position. | -| `StandUpFront.yaml` | The robot gets up from its front and moves into a standing position. | -| `Zombie.yaml` | The robot moves into a standing zombie position, with arms straight out. | +| Script Name | Description | +| -------------------- | ------------------------------------------------------------------------------------------------------- | +| `DiveLeft.yaml` | The robot stretches its arm out to the left and moves its left leg so that it will dive to the left. | +| `DiveRight.yaml` | The robot stretches its arm out to the right and moves its right leg so that it will dive to the right. | +| `KickLeft.yaml` | The robot kicks with its left foot. | +| `KickRight.yaml` | The robot kicks with its right foot. | +| `NodYes.yaml` | The robot nods its head. | +| `Relax.yaml` | The robot relaxes all of its joints. Be prepared to hold it if it's standing, as it will fall over. | +| `RollOverFront.yaml` | The robot rolls from its back onto its front. | +| `Stand.yaml` | The robot moves into a standing position. | +| `StandUpBack.yaml` | The robot gets up from its back and moves into a standing position. | +| `StandUpFront.yaml` | The robot gets up from its front and moves into a standing position. | +| `Zombie.yaml` | The robot moves into a standing zombie position, with arms straight out. | ## Modifying and Adding Scripts @@ -134,4 +137,4 @@ scp nubots@
: `
` is the address of the robot, such as `10.1.1.1` for NUgus 1. `` is the path to the script. `` is the path you want to copy the script to on your computer. Run this command on your computer. -After you copy the script to your computer, you should commit it to a new branch and make a pull request to merge it into the `main` branch on GitHub; unless the changes are not suitable to keep, in which case you can discard them. For information on Git visit the [Git guide](/guides/general/git). +After you copy the script to your computer, you should commit it to a new branch and make a pull request to merge it into the `main` branch on GitHub; unless the changes are not suitable to keep, in which case you can discard them. For information on Git and GitHub visit the [Git guide](/guides/general/git). diff --git a/src/book/03-guides/01-main-codebase/04-maintaining-subsystems.mdx b/src/book/03-guides/01-main-codebase/04-maintaining-subsystems.mdx index 87c1cba54..55fb17690 100644 --- a/src/book/03-guides/01-main-codebase/04-maintaining-subsystems.mdx +++ b/src/book/03-guides/01-main-codebase/04-maintaining-subsystems.mdx @@ -25,6 +25,8 @@ The `nugus_controller` in Webots has functionality to send live odometry ground The accuracy of the vision system is reliant on the accuracy of odometry and kinematics because they affect the placement of the mesh and green horizon. It is important that these systems work reasonable well otherwise the robot may have issues detecting objects. +If you are using Webots, you can turn on odometry ground truth in the SensorFilter module. Go to the `SensorFilter.yaml` configuration file and set the `filtering_method` to `GROUND_TRUTH`. This will use the ground truth odometry from Webots instead of the odometry from the robot. This is useful for testing the vision system without having to worry about odometry errors. + ### Dataset Generation Synthetic and semi-synthetic training data for vision can be generated using [NUpbr](/system/tools/nupbr). Pre-generated datasets for training the Visual Mesh are on the NAS in the lab. @@ -69,7 +71,7 @@ An automatic camera calibration tool is available in the NUbots repository. See After updating the Visual Mesh in the NUbots repository, it should be tested before merging. Refer to the [Getting Started guide](/guides/main/getting-started) for assistance for the following steps. -1. Build the code, ensuring `ROLE_visualmesh` is set to `ON` in `./b configure -i`, and install it to the robot. Ensure the new configuration file is installed by using the `-cu` or `-co` options when installing - check out the [Build System page](/system/foundations/build-system#install) to find out more about options when installing onto the robot. +1. Build the code, ensuring `ROLE_test-visualmesh` is set to `ON` in `./b configure -i`, and install it to the robot. Ensure the new configuration file is installed by using the `-cu` or `-co` options when installing - check out the [Build System page](/system/foundations/build-system#install) to find out more about options when installing onto the robot. 2. When your new Visual Mesh is installed onto the robot, connect to the robot using: @@ -77,13 +79,13 @@ After updating the Visual Mesh in the NUbots repository, it should be tested bef ssh nubots@
``` -3. Ensure NUsight is on: +3. Ensure the robot is sending vision data: ```bash nano config/NetworkForwarder.yaml ``` - Turn `vision object` and `compressed images` on. Run NUsight using `yarn prod` and navigate to the NUsight page in your browser. More on NUsight can be found on [the NUsight NUbook page](/system/tools/nusight). + CompressedImage, Balls, Goals and GreenHorizon should be on. Run NUsight using `yarn prod` and navigate to the NUsight page in your browser. More on NUsight can be found on [the NUsight NUbook page](/system/tools/nusight). If you have not already set up and built NUsight, refer to the [Getting Started page](/guides/main/getting-started). 4. Run the `test/visualmesh` role @@ -93,7 +95,7 @@ After updating the Visual Mesh in the NUbots repository, it should be tested bef 5. Wait for the cameras to load and then watch the Vision tab in NUsight. To determine if the output is correct, consult the [vision page](/system/subsystems/vision) for images of the expected output. -If you would like to see the Visual Mesh output in NUsight, you will need to log the data and run it back in NUsight using DataPlayback, since the data is too large to send over a network. Use the steps in the [DataLogging and DataPlayback guide](/guides/main/data-recording-playback) to record and playback data. Adjust the instructions for our purpose using the following hints: +To see the Visual Mesh itself in NUsight, you will need to enable the `message.vision.VisualMesh` message in the `NetworkForwarder.yaml` file. Most of the time the networking should work, but sometimes there may be issues since the Visual Mesh data is large. If there are issues with seeing the Visual Mesh output in NUsight, you will need to log the data and run it back in NUsight using DataPlayback. Use the steps in the [DataLogging and DataPlayback guide](/guides/main/data-recording-playback) to record and playback data. Adjust the instructions for our purpose using the following hints: - In step 1 of Recording Data, use the [`test/visualmesh`](https://github.com/NUbots/NUbots/blob/main/roles/test/visualmesh.role) role to record the data. - In step 2 of Recording Data and step 4 of Playing Back Data, set `message.output.CompressedImage` to `true` and add `message.vision.VisualMesh: true` in both [DataLogging.yaml](https://github.com/NUbots/NUbots/blob/main/module/support/logging/DataLogging/data/config/DataLogging.yaml) and [DataPlayback.yaml](https://github.com/NUbots/NUbots/blob/main/module/support/logging/DataPlayback/data/config/DataPlayback.yaml). diff --git a/src/book/03-guides/01-main-codebase/05-recording-playback.mdx b/src/book/03-guides/01-main-codebase/05-recording-playback.mdx index 340481cec..3f465070d 100644 --- a/src/book/03-guides/01-main-codebase/05-recording-playback.mdx +++ b/src/book/03-guides/01-main-codebase/05-recording-playback.mdx @@ -8,7 +8,7 @@ authors: - Ysobel Sims (@ysims) --- -The NUbots system is based on [NUClear's message passing architecture](/system/foundations/nuclear). Any [messages](https://github.com/NUbots/NUbots/tree/main/shared/message) that are emitted when the system is running can be recorded and saved as [NUClear Binary Stream (NBS) files](/system/foundations/nuclear#nbs-files). These NBS files can later be filtered, played back (to simulate the running system), analysed, and converted to alternative formats for further processing. +The NUbots system utilises [NUClear's message passing architecture](/system/foundations/nuclear). Any [messages](https://github.com/NUbots/NUbots/tree/main/shared/message) that are emitted when the system is running can be recorded and saved as [NUClear Binary Stream (NBS) files](/system/foundations/nuclear#nbs-files). These NBS files can later be filtered, played back (to simulate the running system), analysed, and converted to alternative formats for further processing. ## Recording Data @@ -27,7 +27,7 @@ The following steps detail how to record data. An example will be given througho In this example, the sensors message already exists in the file (`message.input.Sensors`). Set the boolean to `true` next to this message. - If you would like to log a different message, do the following: + If you would like to log a different message and it doesn't already have a corresponding line in the DataLogging configuration file, do the following: 1. Find the `.proto` file that defines that message, such as [`Sensors.proto`](https://github.com/NUbots/NUbots/blob/main/shared/message/input/Sensors.proto). 2. Find what the `package` is. For `Sensor.proto`, it is `package message.input`. @@ -55,7 +55,7 @@ The following steps detail how to record data. An example will be given througho **Locally in Docker:** The log file will be in your NUbots directory under `/recordings/`. - **On a real robot:** You will need to move the file off the robot so that it is not lost and so that it can be used. Note that when someone else installs to the robot any recordings will be lost, so immediately copy them to another computer. + **On a real robot:** You will need to move the file off the robot so that it is not lost and so that it can be used. Note that when someone else uses the robot any recordings may be lost, so immediately copy them to another computer. 1. The NBS file will be located on the robot in the `log/role_name/` folder. The name will correspond to the time and date it was created, according to the robot's clock. Make note of the name. In our example, this may be `log/test/sensor/18072020T082100.nbs`. 2. Copy the file across. On the destination computer, run: @@ -170,7 +170,7 @@ Following on from the previous example, lets now run `test/sensor.role` with rec Playing back recorded data is useful when: -- Working remotely, where the data is previously recorded or recorded by another team member +- Working remotely, where the data was previously recorded or recorded by another team member - Testing a system with the same input data - Not wanting to run the real robot continuously, where it is possible to use the same data - Viewing the Visual Mesh in NUsight, due to bandwidth issues in sending it over the network diff --git a/src/book/03-guides/01-main-codebase/06-camera-calibration.mdx b/src/book/03-guides/01-main-codebase/06-camera-calibration.mdx index b96eefdbc..3f0567b40 100644 --- a/src/book/03-guides/01-main-codebase/06-camera-calibration.mdx +++ b/src/book/03-guides/01-main-codebase/06-camera-calibration.mdx @@ -28,15 +28,14 @@ The calibration requires two steps, creating the `nbs` recording and using it to 5. Check the focus of the lenses using the NUsight vision tab. If it is not sharp, focus the camera. This involves pulling the camera out from the head, still plugged in, and loosening the three grub screws. Twist until the camera is focused. -6. Check the [transformation matrix](/system/foundations/mathematics#homogeneous-transformations) from the left camera to the pitch motor (Hpc) is correct in the `Left.yaml` file. This should be the transformation matrix from the camera to the end of the rigid body, i.e. the pitch motor as used in forward kinematics. Currently this is 69.952mm in $x$, 33.795mm in $y$, 64.88mm in $z$, and a positive $y$-axis rotation of $2^\circ$. In SI units the matrix is +6. Verify that the extrinsics look correct in NUsight. The extrinsics are the transform from the last neck motor to the camera. This is retrieved from the robot's URDF model, but differences in the real robots may result in required offsets. Offset values for both pitch and roll are in the camera configuration files. The offsets are in radians. - $$ - \text{Hpc} = \begin{bmatrix} - \cos(\frac{2 \pi}{180}) & 0 & \sin(\frac{2 \pi}{180}) & 0.069952 \\ - 0 & 1 & 0 & 0.033795 \\ - -\sin(\frac{2 \pi}{180}) & 0 & \cos(\frac{2 \pi}{180}) & 0.06488 \\ - 0 & 0 & 0 & 1 \end{bmatrix} - $$ + 1. Ensure `NetworkForwarder.yaml` has a `message.output.CompressedImage` value greater than 0. + 2. Stand the robot up with `./scriptrunner Stand.yaml` + 3. Face the robot towards a straight horizontal line, such as a line of bricks on a brick wall. + 4. Run `./test/visualmesh` and switch to the vision tab in NUsight + + NUsight should show a blue horizontal line. Adjust the offsets until the line is drawn at a constant height (the height of the cameras) along the wall. 7. Run `./test/camera` on the robot and hold up a board as shown in the below image. There is an appropriate board in the NUbots laboratory. Move the board around to cover the robot's view over time, taking into account that the lenses have a $180^{\circ}$ field of view. Move the board around at different distances and angles. @@ -89,12 +88,9 @@ The calibration requires two steps, creating the `nbs` recording and using it to 3. Verify these values by running vision and checking the output in NUsight. - 1. Ensure `NetworkForwarder.yaml` has a `message.output.CompressedImage` value greater than 0. - 2. Stand the robot up with `./scriptrunner Stand.yaml` - 3. Face the robot towards a straight horizontal line, such as a line of bricks on a brick wall. - 4. Run `./test/visualmesh` and switch to the vision tab in NUsight + You should see the same blue line as before, correctly aligned with the wall. If the line is not aligned, you will need to adjust the camera offsets. - NUsight should show a blue horizontal line, drawn at a constant height along the wall. If this is the case, then the calibration is verified. + Run the `test/localisation` role and check that the field lines in the localisation view are parallel or perpendicular to each other. If the perspective does not look right, then the cameras are not calibrated correctly. 4. Repeat this process with other robots if needed. diff --git a/src/book/03-guides/01-main-codebase/images/flashing/bios_boot_configuration.jpg b/src/book/03-guides/01-main-codebase/images/flashing/bios_boot_configuration.jpg deleted file mode 100644 index a385d677c..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/bios_boot_configuration.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/bios_power.jpg b/src/book/03-guides/01-main-codebase/images/flashing/bios_power.jpg deleted file mode 100644 index 3c1399e4b..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/bios_power.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/bios_secure_boot.jpg b/src/book/03-guides/01-main-codebase/images/flashing/bios_secure_boot.jpg deleted file mode 100644 index d8f2e5ff9..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/bios_secure_boot.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/internet.jpg b/src/book/03-guides/01-main-codebase/images/flashing/internet.jpg deleted file mode 100644 index f9b61a513..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/internet.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/known_interfaces.jpg b/src/book/03-guides/01-main-codebase/images/flashing/known_interfaces.jpg deleted file mode 100644 index e5aad153d..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/known_interfaces.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/liveusb.jpg b/src/book/03-guides/01-main-codebase/images/flashing/liveusb.jpg deleted file mode 100644 index e7ab973d5..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/liveusb.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/login.jpg b/src/book/03-guides/01-main-codebase/images/flashing/login.jpg deleted file mode 100644 index 1e2a0decb..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/login.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/flashing/no_internet.jpg b/src/book/03-guides/01-main-codebase/images/flashing/no_internet.jpg deleted file mode 100644 index 5ae315473..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/flashing/no_internet.jpg and /dev/null differ diff --git a/src/book/03-guides/01-main-codebase/images/scripttuner.png b/src/book/03-guides/01-main-codebase/images/scripttuner.png deleted file mode 100644 index 545153869..000000000 Binary files a/src/book/03-guides/01-main-codebase/images/scripttuner.png and /dev/null differ diff --git a/src/book/03-guides/02-tools/02-webots.mdx b/src/book/03-guides/02-tools/02-webots.mdx index 9de677ab7..f5f71af7d 100644 --- a/src/book/03-guides/02-tools/02-webots.mdx +++ b/src/book/03-guides/02-tools/02-webots.mdx @@ -106,15 +106,15 @@ sudo apt-get install cmake-curses-gui libprotobuf-dev protobuf-compiler libeigen 1. Move into the directory you would like the clone into. The following command will put you in your `home` directory. -```bash -cd ~ -``` + ```bash + cd ~ + ``` 2. Clone the RoboCup TC Virtual Season repository: -```bash -git clone https://github.com/RoboCup-Humanoid-TC/hlvs_webots.git -``` + ```bash + git clone https://github.com/RoboCup-Humanoid-TC/hlvs_webots.git + ``` ### Set Up the Controllers @@ -125,7 +125,7 @@ git clone https://github.com/RoboCup-Humanoid-TC/hlvs_webots.git pip3 install -r controllers/referee/requirements.txt ``` -2. Build the Robocup controllers: +2. Build the RoboCup controllers: ```bash make -j$(nproc) @@ -145,7 +145,7 @@ git clone https://github.com/RoboCup-Humanoid-TC/hlvs_webots.git sudo apt-get install ant default-jdk ``` -2. Clone the Robocup TC GameController repo: +2. Clone the RoboCup TC GameController repo: ```bash cd ~ @@ -187,7 +187,7 @@ git clone https://github.com/RoboCup-Humanoid-TC/hlvs_webots.git export GAME_CONTROLLER_UDP_FILTER= # replace with your IP address from step 1 ``` -3. Run the following to open Webots with the Robocup world and the GameController: +3. Run the following to open Webots with the RoboCup world and the GameController: ```bash webots ~/hlvs_webots/worlds/robocup.wbt @@ -215,7 +215,7 @@ Running the RoboCup scenario requires two things: [the Webots simulator](https:/ 1. As done previously, get the hostname of each computer by running `hostname -I` in a terminal on each computer. - 2. On each computer you will be running the robot code on, run `./b edit config/webots.yaml` and change the IP in `server_address` to the hostname of the Webots simulator computer found in the previous step. For any robots running on the same computer as the Webots simulator, do not change the IP. + 2. On each computer you will be running the robot code on, run `./b edit config/Webots.yaml` and change the IP in `server_address` to the hostname of the Webots simulator computer found in the previous step. For any robots running on the same computer as the Webots simulator, do not change the IP. 3. On the computer you will be running the Webots simulator on, open the `hlvs_webots` repo in a text editor. Open the file `controllers/referee/game.json` (you can use Ctrl+p, search for `game.json` and the first file should be the correct one). @@ -382,7 +382,7 @@ NUbots runs full Webots games to benchmark the current performance of the code. 2. Change the `"blue":` `"id"` to `13`. 3. Change the `"blue":` `"config"` field to `"team_1.json"`. -3. Open a terminal and run the following to open Webots with the Robocup world and the GameController: +3. Open a terminal and run the following to open Webots with the RoboCup world and the GameController: ```bash webots ~/hlvs_webots/worlds/robocup.wbt diff --git a/src/book/03-guides/02-tools/03-visualmesh.mdx b/src/book/03-guides/02-tools/03-visualmesh.mdx index 4fd7e8fbc..ca4beb40f 100644 --- a/src/book/03-guides/02-tools/03-visualmesh.mdx +++ b/src/book/03-guides/02-tools/03-visualmesh.mdx @@ -8,7 +8,7 @@ authors: - Joel Wong (@wongjoel) --- -This guide compliments the quickstart guide on the [main Visual Mesh repo](https://github.com/Fastcode/VisualMesh) by being geared towards those with little experience of the [Linux command line (i.e. bash)](https://ubuntu.com/tutorials/command-line-for-beginners#1-overview) or of Machine Learning workflows. If you are already familiar with bash and machine learning, you may prefer to work off the Quickstart guide on the Visual Mesh repo as it is briefer than this guide. +This guide compliments the quickstart guide on the [main Visual Mesh repo](https://github.com/NUbots/VisualMesh) by being geared towards those with little experience of the [Linux command line (i.e. bash)](https://ubuntu.com/tutorials/command-line-for-beginners#1-overview) or of Machine Learning workflows. If you are already familiar with bash and machine learning, you may prefer to work off the Quickstart guide on the Visual Mesh repo as it is briefer than this guide. To get started, run this line to check the installation and version of the required programs. @@ -70,7 +70,7 @@ cd code Once you're in the folder you wanted to be in (e.g. `~/code/`), clone the repository with the following command: ```bash -git clone https://github.com/Fastcode/VisualMesh.git +git clone https://github.com/NUbots/VisualMesh.git ``` ## Build the docker image diff --git a/src/book/03-guides/02-tools/images/WindowsInstall1.PNG b/src/book/03-guides/02-tools/images/WindowsInstall1.PNG deleted file mode 100644 index 106d9075f..000000000 Binary files a/src/book/03-guides/02-tools/images/WindowsInstall1.PNG and /dev/null differ diff --git a/src/book/03-guides/02-tools/images/WindowsInstall2.PNG b/src/book/03-guides/02-tools/images/WindowsInstall2.PNG deleted file mode 100644 index 36013ed51..000000000 Binary files a/src/book/03-guides/02-tools/images/WindowsInstall2.PNG and /dev/null differ diff --git a/src/book/03-guides/02-tools/images/WindowsInstall3.PNG b/src/book/03-guides/02-tools/images/WindowsInstall3.PNG deleted file mode 100644 index 403781686..000000000 Binary files a/src/book/03-guides/02-tools/images/WindowsInstall3.PNG and /dev/null differ diff --git a/src/book/03-guides/02-tools/images/display-number.png b/src/book/03-guides/02-tools/images/display-number.png deleted file mode 100644 index dfed5c094..000000000 Binary files a/src/book/03-guides/02-tools/images/display-number.png and /dev/null differ diff --git a/src/book/03-guides/02-tools/images/extra-settings.png b/src/book/03-guides/02-tools/images/extra-settings.png deleted file mode 100644 index 9eb8a8e03..000000000 Binary files a/src/book/03-guides/02-tools/images/extra-settings.png and /dev/null differ diff --git a/src/book/03-guides/03-hardware/02-servo-calibration.mdx b/src/book/03-guides/03-hardware/02-servo-calibration.mdx index 1f5917878..56509823a 100644 --- a/src/book/03-guides/03-hardware/02-servo-calibration.mdx +++ b/src/book/03-guides/03-hardware/02-servo-calibration.mdx @@ -8,7 +8,7 @@ slug: /guides/hardware/servo-calibration Servos are electromechanical components that allow for the precise control and positioning of the various limbs attached to the NUgus robot. Usually, when a servo is found to not be performing correctly (i.e. seizing or a crunching sound can be heard), it should be removed and replaced with a new servo. -Before a servo is first used, its default parameters need to be updated to ensure correct operation. This is done using Dynamixel Wizard, which can be installed for [Windows, Linux or Mac from the Robotis website](https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/). +Before a servo is first used, its default parameters need to be updated to ensure correct operation. This is done using Dynamixel Wizard, which can be installed for [Windows, Linux or macOS from the Robotis website](https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/). ## Set Up @@ -28,7 +28,7 @@ To calibrate a servo perform the following instructions: 1. Select "**Tools -> Calibration**". A window will pop up with instructions on how to calibrate the servo. -2. Select the correct servo model. The model will be written on the servo (either MX-64 for head and arm servos or MX-106 for leg servos). Do **NOT** select the 2.0 versions. +2. Select the correct servo model. The model will be written on the servo. The arms and head use MX-64 and the legs use a mixture of MX-106 and XH540-W270 servos. For the MX servos, choose the 2.0 version. 3. Select the communication port from the dropdown menu (if correctly connected and there is only a single servo attached, this port will autofill). @@ -122,4 +122,4 @@ If this occurs, the following should be performed to validate that the error exi 3. If there are no issues detected, perform another calibration by repeating the above instructions under **Calibration** and **Testing**. -If any issues persist after performing these steps, the servo should be marked as **BAD**. More thorough diagnostic testing is performed by Peter Turner for problem servos. +If any issues persist after performing these steps, the servo should be marked as **BAD**. More thorough diagnostic testing is performed by Peter Turner/Tribotix for problem servos. diff --git a/src/book/03-guides/03-hardware/03-batteries.mdx b/src/book/03-guides/03-hardware/03-batteries.mdx index c4281af40..c5121265b 100644 --- a/src/book/03-guides/03-hardware/03-batteries.mdx +++ b/src/book/03-guides/03-hardware/03-batteries.mdx @@ -61,7 +61,7 @@ used for the purposes of the images below. 1. Plug the battery cable with the white plug into the corresponding socket on the side of the charger. The plug should only fit in one orientation so check before plugging it in. If you find yourself forcing the plug into the socket you are doing something wrong. -2. Plug the other battery cable into the main output cable of the charger, this may require an adaptor, as seen in the section on using in the robot +2. Plug the other battery cable into the main output cable of the charger, this may require an adaptor, as seen in the section on using a battery in a robot. 3. Plug the Powertech Plus into a power socket, and use the arrow buttons to select the "Charging" setting for the type of battery you are charging. For the NUgus robot battery this is a 14.8V 4 Cell, as seen in the image below. For a Darwin robot battery, this is a 11.1V 3 Cell. diff --git a/src/book/03-guides/04-general/02-git.mdx b/src/book/03-guides/04-general/02-git.mdx index 08ffb3186..a0b4e16fa 100644 --- a/src/book/03-guides/04-general/02-git.mdx +++ b/src/book/03-guides/04-general/02-git.mdx @@ -48,7 +48,7 @@ To be approved, you should add reviewers to the pull request. Each reviewer will The reviewers will give constructive feedback about your code, by making comments on code snippets from your changes. You can respond to these on GitHub. They can also directly suggest changes to specific sections. Additional commits you make to the branch will update the PR and will reset reviews of the changed sections. -Once all of the comments are resolved, the reviewers have approved the PR, and the build checks have passed (see [_Formatting and Buildkite Checks_](#formatting-and-buildkite-checks)), you can **Squash and Merge**. Squashing combines every commit on the PR into a single commit so that the `main` branch history is clean and easy to follow. Once the code has been squashed and merged, it is in the codebase and you have succeeded in contributing code to NUbots. +Once all of the comments are resolved, the reviewers have approved the PR, and the build checks have passed (see [_Formatting and PR Checks_](#formatting-and-buildkite-checks)), you can **Squash and Merge**. Squashing combines every commit on the PR into a single commit so that the `main` branch history is clean and easy to follow. Once the code has been squashed and merged, it is in the codebase and you have succeeded in contributing code to NUbots. ## Commit Etiquette @@ -56,7 +56,7 @@ Commits should make minor changes, and the changes in each commit should have a Commit messages should describe what you did, starting with an action verb in the present tense. If you added a file with a new stand script, for example, prefer "Add new stand script" over "Added new stand script" or "Adding new stand script" or "Add script". -## Formatting and Buildkite Checks +## Formatting and PR Checks Before making a pull request, it is important that your code adheres to the code style and formatting rules for the project you are contributing to. diff --git a/src/book/03-guides/04-general/03-troubleshooting.mdx b/src/book/03-guides/04-general/03-troubleshooting.mdx index 61f2cb0a7..36f329a2b 100644 --- a/src/book/03-guides/04-general/03-troubleshooting.mdx +++ b/src/book/03-guides/04-general/03-troubleshooting.mdx @@ -81,7 +81,7 @@ This means someone else is also running a Docker robot. You can modify the name ## Hardware -TODO +Take care when working with hardware. If you are unsure, ask someone directly for assistance. ## NUbook diff --git a/src/book/03-guides/04-general/04-glossary.mdx b/src/book/03-guides/04-general/04-glossary.mdx index c2a847474..77e785754 100644 --- a/src/book/03-guides/04-general/04-glossary.mdx +++ b/src/book/03-guides/04-general/04-glossary.mdx @@ -10,7 +10,7 @@ authors: ## Conventions and Notations -**For naming conventions of matrices and vectors see the [Mathematics Section](/system/foundations/mathematics).** +**For naming conventions of matrices and vectors see the [Mathematics page](/system/foundations/mathematics).** **Coordinate Orientation**: Robot's local coordinate system is x forward, y to the left, z up. Global coordinates are also z up. @@ -30,9 +30,7 @@ authors: [**Bit-Bots**](https://bit-bots.de/): A RoboCup team from the University of Hamburg, which created the quintic walk NUbots uses. -[**Buildkite**](https://buildkite.com/): A platform for running fast, secure, and scalable continuous integration pipelines, which NUbots runs on machines in the NUbots lab. - -[**Calibration Tool**](https://github.com/NUbots/NUbots/blob/main/tools/nbs/calibrate_cameras.py): NUbots automatic tool for calibrating the cameras in the head which are used for the robot's vision. +[**Camera Calibration Tool**](https://github.com/NUbots/NUbots/blob/main/tools/nbs/calibrate_cameras.py): NUbots automatic tool for calibrating the cameras in the head which are used for the robot's vision. [**Clang**](https://clang.llvm.org/): A compiler, frontend, and tooling infrastructure used for C and C++ which is part of the LLVM infrastructure. @@ -52,13 +50,15 @@ authors: [**Convolution**](https://en.wikipedia.org/wiki/Convolution): A function which transforms two functions into another. [Convolutional Neural Networks](https://en.wikipedia.org/wiki/Convolutional_neural_network) (CNNs) are very commonly used for image processing and computer vision, working by passing filters across the image and combining those outputs in further layers. -[**Darwin**](https://robots.ieee.org/robots/darwin/): A _Robotis_ robot platform which was the platform NUbots used before making the NUgus. +[**Darwin**](https://robots.ieee.org/robots/darwin/): A _Robotis_ robot platform which was the platform NUbots used before making the NUgus. Currently used at outreach events. [**Deep Learning**](https://en.wikipedia.org/wiki/Deep_learning): Machine learning techniques which utilise artificial neural networks with many layers. +[**Director**](/system/foundations/director): The tree-based behaviour framework that NUbots uses. + [**Docker**](https://www.docker.com/): A software service for developing containers which enable standardised cross-platform development consistency. -[**Dockerhub**](https://hub.docker.com/): A hosting service for docker container images. +[**Docker Hub**](https://hub.docker.com/): A hosting service for docker container images. [**Doxygen**](https://www.doxygen.nl/index.html): Generates documentation from comments in the code. @@ -182,7 +182,7 @@ authors: **Static Motion**: We tend to refer to motion which is fully controlled by scripts which do not change at run-time as _Static Motion_. -**Subsumption**: The priority system that determines if a neutron gets access to the servos it wants to control. +**Subsumption**: The priority system previously used by NUbots that determines if a neutron gets access to the servos it wants to control. [**Tensorboard**](https://www.tensorflow.org/tensorboard): Visualisation toolkit used to inspect the training performance of the visual mesh. @@ -193,7 +193,7 @@ authors: [**Transformation**](): A function which maps a set to itself (sometimes called an operator on that set). Often, it is used in the context of a spatial manipulation - regularly representated as a translation and a rotation. **Units**: [S.I. units](https://en.wikipedia.org/wiki/International_System_of_Units) are used for everything but time. Storage of values may have a different unit, e.g. [nbs and nbs index files](/system/foundations/nuclear#nbs-files). -In c++ units are a templated parameter to [NUClear::clock::duration](https://en.cppreference.com/w/cpp/chrono/duration) and [NUClear::clock::time_point](https://en.cppreference.com/w/cpp/chrono/time_point) is unit agnostic. +In C++ units are a templated parameter to [NUClear::clock::duration](https://en.cppreference.com/w/cpp/chrono/duration). [NUClear::clock::time_point](https://en.cppreference.com/w/cpp/chrono/time_point) is unit agnostic. [**TFRecord**](https://www.tensorflow.org/tutorials/load_data/tfrecord): Binary format used by the Visual Mesh to store input data - contains image, mask, and lens metadata records.