Communication

Antenna

Table of content

History

Earth and Mars are separated of 56 to 380 million of kilometres. The delay caused by this distance on the communication between Mars and Earth varies between 3 and 20 minutes. Moreover, the Sun produces a heating noise which interferes with our transmissions. Finally, there are also spatial rays and electrical noise generated by components.

Despite that, NASA's engineers can use space probes gravitating around Mars to communicate (Mars Odyssey or Mars Global Surveyor for example). It's used as a relay with the DSN server (Deep Space Network). The rovers use high frequencies in S band (2.2GHz), X band (8.4GHz) and K band (32GHz). But there is a problem with this kind of communication because the slot is only about 8min per sol with a high-speed of 2Mb/s.

Characteristics

Goal

In this project, we have implemented a direct communication with Raspberrys between Earth and the Rover.We have used radiofrequency modules (compatible with Arduino and Raspberry) to get closer to the Curiosity's communication method. Some rules (different according to the country) control radiofrequency emissions: a few frequency bands are free but most of them are charged. We have had the choice to use the common 433-434 MHz or the 868MHz.

433MHz 868MHz
Advantage: cheap, very common so easy to find help, authorised nearly in the entire world Advantage: already in stock (LPRS ERA Connect2 Pi), less perturbation, long range (200m maximum), easy to use on cheap or computer, no proprietary protocol
Drawback: short range (20m maximum), 433MHz band blocked so perturbation is very frequent, spread power doesn't exceed 10mW Drawback: expensive knowing 2 modules are necessary

We have finally chosen the USB dongles Module Connect2Pi 868MHz implemented on Raspberry whose sensibility is about -107dBm. Our mission in this project is to equip the rover of many sensors then create a bidirectional transfer between the control system on Earth and the Martian Rover.

Step 1

Reception

On Mars, the board must:

Step 2

Sending

On Earth, the Raspberry must:

We have also defined some important characteristics for the transmission.

Our web site must give the possibility to the user to send order (to record temperature, humidity...) but also display the data received and/or errors messages.

General explication

Considering all these points, the problematic is: how to send an request via the web site to a particular sensor on the Rover? It's simple: the request is processed by the master (the Raspberry) which calls the slave (the Arduino) associated to the respective sensor via an USB wire (transmit information and power in the same wire). There are many possible actions so we have designed a protocol which will be sent by the Raspberry to the slave.

The first character is a number which corresponds to the number of the wished action that we have defined (10 maximum), then all the characters until "#" correspond to the angle.

For example:

The main drawback of this kind of protocol is that it restrains us to have only 10 (0 to 9) different actions on one Arduino but we have already thought of another simple solution to solve this problem. It would be sufficient to add separators as "$" between the number of action and the angle.

For the requests, we make a difference between the data command ("Get": ask the result of measurement already done and recorded) and the action order ("Do&", make a measurement or move a servo). To interpret the order, we use a division by 10 and the modulo. For example:

Protocol

The web site

We have had 2 choices to let the user send orders to the Martian Rover: a web site or a mobile application. We have chosen the first one because the web site can be used both on a computer or a mobile.

It's easy to implement a web site on a Raspberry thanks to a the Webpy library. We have used tutorials on Internet which use similar libraries to help us understand the development steps. This library allows us to manage POST and GET requests, but also press a button which corresponds to a single action as well as to write numbers in right text area. This interface is very simple and completely user friendly.

Website

It's easy to implement a web site on a Raspberry thanks to a the Webpy library. We have used tutorials on Internet which use similar libraries to help us understand the development steps. This library allows us to manage POST and GET requests, but also press a button which corresponds to a single action as well as to write numbers in right text area. This interface is very simple and completely user friendly.

Bug site

Given that the user can input servo angles, we made sure that the data requested was authorised (angle between 0° and 180°) and wouldn't put in danger the rover. For that we used HTML5 which can impose a number input for example.

We wanted it to be responsive to the screen size and also enjoyable to watch. So we used a template (with a drop-down menu) which we have adapted to our system.

Theme site 1 Theme site 2

Problems and Bugs

The most difficult step has been to think about the state machine of both Raspberrys. The first idea was to develop a complex state machine which verified if a data was received when it was just sent before. In theory, we insured the information was correctly transmitted but in practice the behaviour was completely incontrollable. In consequence, we have decided not to make verifications. We have just conserved a temporal control of the requests: if the data is not received after a defined time, we consider the request lost.

All the structure functioned but when we have decided to power it with the battery, the motors didn't react as we expected (halting movements). It came from the Arduino which was powered by the battery and the raspberry via the USB wire. Thanks to the precious advice of SOFAB, we use the Software Serial library and a wire USB/TTL to solve the difficulty.

To debug easily the code, we used a global variable to choose if we want to display an error message on the server or on the computer screen. It also allows to check the sturdiness of the system making corner simulation.

We have already thought about improvements like add a failure protocol or send bigger files.