AS OF 9/23 THIS WIKI IS NO LONGER MAINTAINED.

For the updated wiki, please look at the knowledge base tab on YouTrack.

Introduction

Welcome to the MAVRIC Systems team wiki! This wiki is intended to be a resource for Systems team members to reference when making technical modifications to a MAVRIC rover. As MAVRIC has developed multiple rovers to date and will hopefully develop many more in future years, the information on this wiki may not always be up to date. It is recommended to double-check information on this wiki with a more experienced Systems team member or a technical advisor to ensure that the most up-to-date knowledge will be used.

System Architecture

Overview - General

The electrical architecture defines the power distribution, connectors, and modules of the rover. MAVRIC rovers are powered by two separate batteries: the Drive battery and the Systems battery. The Drive battery, which powers motors and other high-current devices, is a 6500mah 4s LiPo Battery. The Systems battery, which powers the main computers and other supporting devices, is a 4000mAh 6S LiPo battery. The Drive battery has a power switch that can be used to disable power to the motors when driving is not desired. The Systems battery has an emergency stop that can be hit to quickly disconnect power from the main computer and cease rover operation. If the main computer is disabled while motors are still powered, the motor controllers will wait for a heartbeat before operating.

Below are details about the rover-specific architecture and electrical structures.

Scarab

Electrical Diagram

Control Structure

The control system of Scarab has been consolidated onto a single nVidia Jetson TX2 board. The control systems on Phoenix have not suffered from reliability issues, so the system has been simplified on Scarab. This also allows the use of a more advanced main computer - the Jetson has an AI-capable GPU designed for machine vision and machine learning applications as well as a more powerful CPU.

ROS

ROS allows us to compartmentalize our software into small, self-contained nodes that each serve a specific function. These nodes communicate with each other using "topics" to pass data back and forth, creating a network of interacting software.

ROS allows seamless communication between separate devices (such as the multiple Raspberry Pi's of Phoenix) and between different languages (most of Scarab's software is written in Python, but some motor control nodes are written in C++). Some hardware components even have native ROS integration (such as the Intel RealSense stereo camera). Overall, ROS is a powerful software structure that makes it easy to add new software and hardware components to the rover's programming.

The architecture is broken up by the boards from the electrical design section, and then by the nodes that will run within them. Generally, each subsystem will have an interface module that will open a server for access by the base station. These nodes will parse the commands and publish them as topic messages. This opens up debugging options in that all internal communication can be captured and simulated. The communication between boards will be handled by a local network.

Communication Systems

Internal Communication

Ethernet and a network switch is used for networking onboard the rover, such as between all of the IP cameras on both rovers. Protocols such as UART, I2C, and CAN are used for communication with peripherals on breakout boards. UART is used to communicate and read NMEA strings from the GPS receiver. CAN is used to communicate with motor controllers on Scarab. CAN requires fewer wires and offers more control features than PWM, so all future rovers will likely use CAN.

External Communication

Ubiquiti Rocket M radios are used for communication between rovers and the base station. Currently, we are using 5GHz Rocket M5 radios, but have considered using a lower-frequency radio to increase range and non-line of sight performance common at competition.

Due to communications problems in the past, the protocol will not assume anything about responses. If a command requires a response, and none is received, another request should be sent.