Full robot code for NASA Lunabotics 2020 competition. For any clarifications, suggested changes, etc. please contact:

Current maintainer: Dan Shafman (@danshafman on Slack, ds5695@nyu.edu)

1  Introduction

2  Communications

      2.1  Server ⟺ Robot

      2.2  GCS ⟺ Server

3  Additional Resources

4  Coming soon

In this section we will be introducing the NASA Lunabotics 2020 competition and the purpose, design, and operation of our robot. We will also be introducing some technical terms and vocabulary that we use throughout this README.

The Lunabotics competition is a simulation of an off-world mining mission: our robot, which simulates a moon rover

One Teensy/ESP pair does not have enough power to handle all the functionality of the robot at once, due to the Teensy's limited output capability and processing power. As such, the the robot functionality is handled over four Teensy/ESP pairs, each representing one subset of the robot's functionality. Specifically, this means there is a Teensy/ESP pair for:

1. Writing commands to the drivetrain
2. Writing commands to the rest of the robot's limbs
3. Reading sensor (except LIDAR) data and sending it back to the server
4. Reading LIDAR data and sending it back to the server

In this section, Teensy/ESP pair #1 will be referred to as the Drivetrain ESP, #2 will be referred to as the Limb ESP, #3 will be referred to as the Sensor ESP, and #4 will be referred to as the LIDAR ESP. These communicate with the server nodes send_drive_vector (#1), send_limb_controls (#2), and read_robot_state (#3,4). A diagram of this can be found at the bottom of this section.

This communication is done using the MQTT communication protocol, a method of wireless data transfer based on the publisher/subscriber pattern (the same pattern that ROS follows). This is implemented with the Paho MQTT Python library on the server and the Adafruit MQTT Library for Arduino. An example of this can be found on the TestBot20 repository under "MQTTCommsExample".

This protocol is used in autonomy and teleoperated mode identically, since the server is always required to send (or relay) commands to the robot.

Data is transferred between the server and the robot over several channels (or topics), divided into the main categories robotState and robotCmds. robotState is used to convey information about the state of the robot, from the robot to the server. robotCmds is used to send commands from the server to the robot. The subdivisions of these topics are as follows (once again, a diagram of this can be found at the bottom of this section):

Used to send drive commands from the server, specifically from the send_drive_vector node on the server, to the Drivetrain ESP. These commands will be used to control the robot's drivetrain. The data is sent in the following format:

{ byte robotSpeed,
byte offset_driveMode }

• byte robotSpeed can take on a value from 0 to 200, representing a percentage of the robot's potential speed to write to the motor controllers (0 means 100% speed backward, 100 means 0% speed, 200 means 100% speed forward).
• byte offset_driveMode can take on a value from 0 to 255. The robot has four separate "drive modes" it can be in, depending on what relation the wheels need to turn in relation to one another. The following values of this byte mean that the robot is in a specific drive mode:

Used to send limb-controlling commands from the server, specifically from the send_limb_controls node on the server, to the Limb ESP. These commands control ALL of the robot's limbs, except the drivetrain. The data is sent in the following format:

{ byte limbCmds }

• byte limbCmds is split into four sections, as shown in the diagram below (with MSB to the left side). The byte is split into 2 bits representing 4 drum speeds, 2 bits represeting 4 arms speeds, 2 bits representing 4 linear actuator speeds, and 1 bit representing the state of the door (open or closed).

Used to send sensor data from the robot's Sensor ESP to the read_robot_state node on the server. The LIDAR sensor data is NOT included in this! This sensor data will give the state_controller node on the server infomation about the state of all the robot's limbs so that it can plan the next command accordingly. The data is sent in the following format: work in progress

Used to send sensor data, specifically LIDAR data, from the robot's LIDAR ESP to the read_robot_state node on the server. This sensor data will give the state_controller node on the server information on the topology of the ground ahead of it. This then allows the obstacle_detection node to perform calculations on this data to determine whether or not there is an obstacle (hill or pit) in the robot's path.

There are 4 LIDARs mounted in an array on the front of the robot, angled downwards to scan for obstacles. The data is sent in the following format:

{ byte lidar1
byte lidar2
byte lidar3
byte lidar4 }

• byte lidar1 , byte lidar2 , byte lidar3 , byte lidar4 are the distances that the 4 LIDARs read, from left to right. The distances are in centimeters.

Two main objective's of the team's robot code this year are to minimize data transfer across the arena border and to maintain autonomy until a dire situation is reached. The GCS to Server communication protocols are built with this objective in mind. As such, at the competition start, the robot defaults to autonomous mode. Teleoperated mode can be invoked in two ways:

• The robot reaching a fatal error state in its autonomous operation, where it cannot restore normal operation.
• A key on the keyboard being pressed while the robot is in autonomous mode.

This pattern is built on top of two main programs: a Manager and a Socket. There is an identical Manager and Socket running on both the GCS and the Server, though they perform different functions for different purposes.

On the GCS side, the Manager detects key presses using SDL, a library that allows a program to interface with computer peripherals such as a keyboard. It then maps these key presses to their respective encoder (discussed in the "Making an Encoder/Decoder" section). The encoder heavily encodes these key presses down to one or two bytes. These encoded bytes are passed to the Socket, which simply relays them across the wireless network to the receiving Server.

For manual control, the Socket on the Server side does the opposite of what the GCS Socket does. It simply receives encoded bytes and relays them to the Server Manager. This, once again, performs the opposite function of the GCS Manager. Once the Manager gets an encoded byte, it determines which decoder to pass it on to

All of the Academic Year 2020 software trainings can be found here on Drive. You can also find many other resources on most of the topics used in our code (like Python programming, control theory, MQTT, etc.) in this sheet. These resources include blogs, YouTube tutorials, and textbooks.

• Description of the robot
• Code structure (NUC, robot, GCS)
• Term definitions (like ESP and NUC and server and limbs)
• Link the trainings from Google Drive