The Experience of Home Mars Rovers

Hi Habr! I work as an RnD artist in the Minsk Wargaming development center. And in my free time I give free rein to my engineering imagination. In this article I want to share my experience of home rover construction.

It all started with the fact that I wanted to feel what it was like to control a rover, located in dozens of light minutes. Of course, there is no access to the real rover, so I built my own. The main condition that I intended to comply with was the simulation of a time lag in management. A lot of effort was spent, but the desired result was achieved.

I will not dwell on my research in detail, but immediately describe the final design. If it will be interesting why I came to these solutions and components (or you can offer better options), then you are welcome to comment.

Hardware

First and foremost, a platform was purchased - the Abrams M1A2 radio-controlled tank, the contents of which (with the exception of engines) were ruthlessly gutted:


Next, I proceeded to search for a power source. Unfortunately, Plutonium-238 could not be found for a home-made RTG, so an alternative was necessary. A worthy replacement was the battery of 16 batteries NCR18650B (3400 mA) with a charge / discharge controller. Estimated capacity - 27 A / h at a voltage of 7.2 V: The


Raspberry Pi 2 became the brain of the rover.


The backlight consumes quite a lot of energy, so it turns on only during shooting at a lighting level below the set threshold. Also, only at the time of measurement is the optical range finder turned on. Switching on and off is carried out using 40-ampere mosfets (there were no other keys in stock), controlled by an Atmega328 microcontroller with minimal binding. A range finder and a photoresistor are connected to the same controller. For the latter, I picked up the approximation function for an industrial light meter taken at work (there we use it for lighting validation). I also used a non-contact temperature sensor MLX90614. All this harness was assembled on a breadboard and screwed to the head rotation servomotors. The head module is connected to the Raspberry with just four wires - power and the I2C bus.


To control the servos, I used a specialized PCA9685 I2C controller with 16 PWM outputs. I tried Arduino at first, but the library for servos is implemented there programmatically. Because of this, spontaneous jerking and twitching occurred during the operation of the controller with I2C. Once the rover even began to hammer the camera on the table. After replacing the Arduino with the PCA9685, all movements became smooth and silky .

To control the engines, I used a slightly modified Dual Channel H-Bridge Motor Shield .


By default, control requires seven lines, two of which are PWM. I threw away the input logic by connecting directly to the driver inputs. It turned out five control lines. But now it has become necessary that four of them are controlled through PWM. I tried to use the remaining lines of PCA9685, but it turned out that the PWM frequency on all channels should be the same, and 50 hertz for controlling servomotors did not suit me in any way. Raspberry had only one full-fledged PWM, but did not want to mess with the software. As a result, I decided to use an additional controller, which at the same time measures the battery voltage. The result was an I2C motor shield:


Additionally, I installed encoders from mice with rubberized wheels from them, which track speed and distance when moving. Encoders are connected to the raspberry via RC filters and cause interruptions in the handler when triggered. The use of simple filters almost eliminated the chatter of contacts, and the remaining random responses were simply cut off in the code. The speed is measured over the time interval between interruptions, and averaged over several measurements.

To power the rover, two step-down stabilizers are used - separately for Raspberry and electronics, and separately for servos. The inside of the rover looks like this:


Humidity and pressure sensors, as well as GPS, I put on the “armor”. GPS is connected to the Raspberry native serial port. As a result, I got such a “zoo” of I2C devices:


Initially, Arduino worked with a radio module connected to a PC as a control center. But the solution was not entirely authentic, so I replaced it with another Raspberry Pi 2 controlled by SSH. At the same time, it allowed to control the rover from outside the house (if you know what I mean). Data exchange with the rover goes through the nrf24L01 PA modules.


The final photo of the rover:

Software

To work with iron, I assembled and installed the BCM2835, WiringPi, NRF24, and OpenCV libraries. There were great concerns about the latter, but surprisingly, everything went smoothly. Although the assembly took more than three hours. OpenCV was needed to fix the strong distortion of the camera (calibrated the camera for this), to draw a GUI on top of the pictures and create a primitive panorama:


I had to tinker with libraries for I2C sensors. In the end, I realized that each sensor prefers its own bus frequency. Most of the sensor code had to be rewritten for the BCM2835 library - here the bus frequency can be adjusted. Not without incidents. It turned out that the magnetometer of the nine-axis gyroscope is a separate device with its own address. When it was programmatically connected to a common bus, for some reason he knocked out a humidity sensor, although they had different addresses. Therefore, the magnetometer is programmatically connected to the bus just before measurement.

It is necessary to update the accelerometer data for the MadgwickAHRS filter at regular intervals, so I put its code in a separate stream. To avoid bus access conflicts, a mutex for I2C was added. By the way, MadgwickAHRS is a very convenient thing - we feed him raw data, and at the output we get a ready-made filtered quaternion of turning the rover in space. In order for the data not to swim too much, a calibrated gyroscope is needed. It also allows you to get the roll and pitch of the rover and rotate at a given angle.

To implement the custom radio module delay, I used queues from structures (32 bytes of the packet and timestamp), as well as two separate streams. One communicates directly with the radio module, and the second deals with data management. Again, there are mutexes for protection against conflicts. The exchange protocol is simple to disgrace - accept / send a line or file. Thanks to this, you can transfer the compiled program from the control center to the rover - as a result, it was useful for editing bugs already during the mission.

I control the engines using PID controllers, taking into account the data from the encoders. Spent several days adjusting the coefficients of the regulators, taking dozens and even hundreds of graphs and adjusting the parameters. But in the end I achieved a smooth and clear work.

There were some problems with data loss on the I2C bus between raspberries and microcontrollers. It was decided using checksums.

I wrote a parser for the GPS module, since the NMEA 0183 protocol is not difficult. The parser works in a separate thread and processes incoming information character by character.

He taught the rover to make heat maps using mlx90614 (the same view from the balcony):

Mission 1: home test

Initially, I planned to leave the countryside and launch a rover in the countryside. But due to adverse weather conditions (snow cover of half a meter), it was decided to launch right in the apartment.

So, the rover was activated before going to work. I remotely contacted the control center and successfully established communication with the rover. The signal delay is set to two minutes. Soon received the first panorama (clickable):


Suddenly a bug appeared in the code - the rover did not wait for the end of the movement commands. I had to edit, assemble and send him a fixed firmware. And then the rover sets off towards the unknown: But another problem surfaced - the information coming through the radio channel suddenly began to deteriorate. Example (checking for checksum is disabled here, otherwise the files would not be accepted): A quick parsing showed that the SPI bus in the control center was to blame. By reducing its frequency by half, the problem was solved. At the same time, I lowered the frequency of the bus for the rover and poured him a new firmware. So the mission continued. First thermal scan:









In general, remotely controlling the rover with a significant delay turned out to be very exciting. That's just the speed of advancement is low. For example, drove into the pantry, the rover spent an hour trying to get out of there. As it became clear later - I did not calculate the distance and the head module hooked on the vacuum cleaner hose:




When the radio module failed in the control center, the mission had to be scaled down, because at the software level it was not possible to solve the problem (let the connectors down)

---

Spring is coming! Therefore, I plan to fix all bugs in the near future and send the rover to the street.
If you can share useful experience or just want to ask questions - write comments.

All sources are here github.com/DIMOSUS/Rover