ESW Overview
The embedded software team of MRover (ESW) writes the driver code that allows the other programming subteams to utilize the electronic equipment on the rover. ESW works primarily with libraries in C, Python, and C++ to abstract the functions needed by the other teams for easy use. To do this we use different communication protocols such as I2C and UART to transmit and receive relative data from sensors.
This page will list all the systems that the ESW sub-team must write code for. If you are interested in helping out or in any of these systems or offering suggestions for improvement, please reach out! You can do this via by sending a message on Slack or by submitting a GitHub issue ticket.
To view our detailed tutorials, visit the embedded-testbench wiki.
There are many brushed motors on the rover. All of these motors can be controlled in open-loop mode (input a velocity and receive no feedback) and some offer the option to be controlled in closed-loop mode (input a position and receive feedback from the absolute and relative encoders). Limit switches are also used to limit movement of some motors.
See the picture below for a block diagram of the motor system. The hardware components involved are 3 STM32F303RE Nucleo boards, 6 Cytron DC Motor Drivers, 4 H-bridges, brushed motors, absolute encoders, relative encoders, and limit switches.
The rover drives on 6 brushless motors. 3 ODrive motor controllers are used to control the brushless motors. Each ODrive motor controller controls two brushless motors. The ODrive motor controller connects to the Jetson Xavier via USB.
The ESW program and the ODrive firmware have watchdog capabilities. If the ODrive disconnects from the Jetson, then the wheels will stop moving. If the Jetson no longer receives new comms from the base station, then the wheels will stop moving. In all states, our program is able to recover (whether there be a watchdog error, ODrive error, a disconnection error, and more). In our system, if there is an error in one axis, then the corresponding axis of that same ODrive will not run (e.g. if encoder does not work for left front wheel, then the front ODrive will run into an error state, and the right front wheel will not process commands either).
See the picture below for a block diagram of the drive system.
Almost all of the onboard science system is controlled by the science board. The science system can be described as follows: On the rover is a carousel that houses three sites that have instruments to test soil samples. Soil is deposited on the top of carousel to one of the sites, where the soil travels through funnels to beakers that test for different things.
Each site has their own thermistor, heater, spectral sensor, and servos motors. The thermistor and heater are used for the ninhydrin test. The servo motors are used for the strip test to test for ammonia, nitrates, and nitrites as well as pH. The servo motors dip the strips into the solution containing the soil. The spectral sensor is used for the autofluorescence test which tests for chlorophyll. A shared UV LED is used inside the carousel for all the sites, as well as a white LED to aid with camera viewing. There is also another UV LED used for disinfecting the scoop after soil acquisitions.
Because many of these functions require just the presence or absence of a voltage difference, we use MOSFETs for many of our devices. The high level view of the MOSFET is that our science board sets the voltage of a particular MOSFET high and the corresponding device turns on.
Our science board has an STM32 chip which we write code for that controls all the logic flow for controlling the MOSFET, reading in spectral data, reading in thermistor data, and controlling the servo sensors. Here, the MOSFET is controlled via output pins from the science board.
The three spectral sensors are close to identical. The communication protocol between the science board and the spectral sensors is I2C, which requires each of the slave devices to have different addresses. Thus, we use an I2C mux. The thermistor data is read in through the STM32 chip's ADC input pins. The servo sensors are commanded via PWM (where a certain PWM corresponds to a certain angle).
The Jetson is the one that runs the program to connect the science board system to the ROS network. A script runs on the Jetson to run all the logic to handle this connection. The Jetson is connected to the STM32 chip via USART. NMEA-like messages are used to transmit information via USART.
See the picture below for a block diagram of the science board system. The hardware involved includes a custom science board with STM32G050C8 chip, 3 spectroscopy sensors, I2C mux, 3 servo motors, 3 thermistors, 1 MOSFET, 3 nichrome wires, 2 UV LEDs, white LED, LED array, and the arm laser.
The Rosie '22 rover uses multiple USB cameras for every mission. The USB Cameras are connected straight into the Jetson via USB (the Jetson does not have that many USB ports so we use a USB Hub too). The Jetson views these cameras as /dev/video* depending on the order they are read into the system (e.g. /dev/video0 or /dev/video6). We have up to 8 devices connected at the same time so we cycle through these cameras and stream the desired cameras only when we need to.
The camera program running on the Jetson takes in requests of which cameras to stream and then publishes it to specific endpoints. An endpoint consists of an IP and a port. The IP is either the base station laptop, or the alternate laptop which is used only during the science mission. We stream up to 2 streams per laptop at once. Because of bandwidth issues, we choose to stream a specific number of cameras at maximum at a specific resolution quality. The number of cameras and the resolution quality is changed depending on the mission.
Our program streams the cameras to a specific stream using a library called jetson-utils, which uses GStreamer. Our base station laptops listen to the streams using GStreamer in the command line. When the base station laptop listens to the stream at a particular endpoint and the Jetson is streaming camera feed to that specific endpoint, a screen will pop-up on the laptop. The people operating the base station may choose to turn off the streams whenever or switch to alternate camera views.
See the picture below for a block diagram of the camera system.
STM32401RE, Raman, Raman laser, and TCD1304 Linear CCD
The Raman spectrometer is used during the science mission to detect kerogens and carotenoids. The CCD is a sensor and is the portion of the Raman setup that collects light, working together with the Raman laser. The CCD is connected to the STM32F401RE Nucleo. The Nucleo is connected to the Jetson via USB. The Jetson script forwards data from the Nucleo directly to the base station using socat such that the data can be accessed on the base station via the Raman gui (pyCCDGUI).