Curiosity rover driver meets Habr
It happened! The long-awaited answers of the "driver" MSL Curiosity to the questions that Habr asked him . Paolo Bellutta also worked with Opportunity and Spirit, so he has rich experience, and most importantly, he does not hesitate to talk about it.
This wonderful translation is provided by Singerofthefall . Paolo's text was sent in bulk, so we divided the answers in half, and the translator will publish the second part. Therefore, you can thank him now, and you can later, when he finishes work on the second part and puts it out. [1]
[1] In square brackets translator's notes.
I posted the full English text on Google and anyone who wishes can contact him, but believe me, this is not necessary because the translation is excellent.
So, let's start our interview:

Q: What is your work schedule?
A: After the first 90 days during which we lived according to Martian time, we switched to the usual schedule. Typically, a business day runs from 8am to 8pm Pacific Standard Time (PST). We work every day, including Saturday and Sunday, but rested, for example, on Thanksgiving and Christmas. Before the holidays, we prepared the teams in advance for a few days in advance, so we managed to stay home, but the rover had to work without a break. Soon we will switch to a 6-day working week, and after the confrontation of Mars [the moment when the Sun is exactly on the line between the Earth and Mars will be in April] we’ll probably switch to the usual five-day one. Although the rover will continue to work every day, it [1] has no days off :-(
[1] [ Paolo speaks of a female rover - she - apparently by analogy with ships to which this pronoun is also used in English. Although now they are practically animating it and treat it not like a ship, but like a girl :)
Elevator doors in JPL NASA.

Since this is unusual for a Russian audience, I will use the pronoun “he” - the rover ]
Q: How is the code for the next-day traffic program checked / debugged? How many people check the code before sending? Are emulators used to check the movement program before sending to the rover? What do they do if they find errors in a submitted traffic program?
A: Great questions! To prepare the teams, we use software specially developed for these purposes in JPL. We have a dedicated editor called RoSE (Robot Sequence Editor - Sequence Editor [ actions ] of the robot), which is the most simple errors - typos in the names of the teams, the error range of parameter values, and so on. A simulator called Hyperdrive is connected to the editor. It receives images that were made in previous Solas, and shows a three-dimensional image of the area surrounding the rover. Then the simulator receives a list of commands and shows what the rover will do, and how it will interact with the environment. You can also simulate basic telemetry, such as location and direction.
For the most important tasks, such as drilling using a manipulator, we sometimes use a prototype.

When it seems to us that the command set does not contain errors, we pass it on to other drivers for verification. Usually at least three people work each shift (a driving specialist, a specialist in using a robotic arm, and a specialist in using tools), but sometimes there are more people left, and they all check the prepared teams. During the shift, we also pass five formal checks, which are carried out by a group of a dozen people, and not all of them are drivers of the rover, since during the daily work we have to use various tools, and we need to make sure that none of the teams can entail equipment failure, or, well, damage to the rover. We also have software for additional verification of commands, and a long list of things that need to be checked every time.
We try not to make mistakes, but sometimes they happen, and a fairly large part of the software on the rover must check that the commands are not meaningless, and that we are not trying to do any stupid thing like shooting from a laser at the rover itself. So even if we make a mistake here on Earth, a rover on Mars will detect it.
Q: How is testing on earth (is there a copy of the rover in the desert on the home planet?)
A: We have two devices. The first is called VSTB (Vehicle Surface Testbed), and all the equipment is installed on it, including cameras and a hand, so we can control it just like a rover on Mars. Every time we need to ensure the special reliability of the program, we use it. Here - photojournal.jpl.nasa.gov/catalog/PIA15876 - there is his photo. The second unit, called the Scarecrow, is equipped only with wheels and an engine. We use it to test movement on various types of surfaces.
We also have two training grounds in JPL, one of them is in the building, it is called In-Situ Instrument Laboratory:

And the other is in the open air - Mars Yard, where we can conduct more tests for movement.
( At 0:33 in the frame, Paolo flashes - the cable pulls )
In May 2012, before landing the rover, we drove the Scarecrow into the desert near the Death Valley in California to check how he would behave in the sand, as it bothered us that the rover could land on the sand dunes.
Q: What do programmers train on?
A: We teach each other. Someone has experience in management, someone helped create a rover, someone participated in writing software. Believe me, all this requires a lot of experience and practice.

IN:After the Curiosity rover completes the entire planned research program, is it planned to provide part of the rover’s resources and time (if at that time it will be operational) at the disposal of students to carry out educational scientific experiments?
A: Actually, a huge number of scientists and students of various universities are working on this mission. Their task is to decide what experiments we should conduct and monitor the progress of their implementation. Honestly, I don’t think that we will ever finish all our experiments at all, since their list is constantly updated - as soon as we find the answer to one of the questions, we immediately have 10 others!
IN:Are there plans for NASA to visit the rover of the landing sites of previous devices for exploring Mars? Most of them have already failed, but it would be interesting to establish the true cause on the spot. Moreover, photographs of these once legendary devices would have a very high aesthetic, and material value.
A: At the moment, our main goal is to explore as much of the planet as possible, so returning to where we have already been would not be very useful, even if we return with more tools. Understanding the reason why our old robots are out of order is still a less important task than collecting new scientific data. So, although I share your desire to see these devices again, I do not think that this will happen in the near future.
Q: How do you solve the problem of a 7 minute signal delay? And is this a big problem?
A: Signal delay due to distance varies from 5 to 20 minutes one way. Now this time is close to maximum, and is about 19 minutes. Of course, the delay is too long for us to be able to control the rover interactively. Think about it - if you see an obstacle in front of the rover, and immediately send a command to stop, then even with the smallest possible delay you will already be 10 minutes late! Therefore, we manage it by sending a sequence of commands every day. In addition, we could not control the rover interactively also because the Earth is not always visible from Gale Crater, in which Curiosity is located. And finally, even if you do not take all this into account, calling the rover is quite expensive - about $ 10,000 per hour!
In general, the delay before receiving data is usually even greater, since we transmit the signal through the Mars Odyssey and Mars Reconnaissance Orbiter satellites. It usually takes at least several hours to get data from the rovers.
Q: Is there any tool or device that is very lacking in Curiosity in your work?
A: More scientific instruments, a more powerful computer, more space for data storage, more options for their transfer, more energy, a higher resolution camera, a higher mast ...
Q: Have there been times when you wrote a program for the day, but already during of its execution, it became clear that a critical error crept into the program’s work, which is too late to fix, but if it’s too late, how do you fix it?
A: Of course! On MER, we found some bugs years after landing. One of the critical bugs was found on the Spirit rover on the 18th Sol, and the other we found at all in 2007 when we traveled around Victoria Crater. We have a team of specialists (including myself) that analyzes the telemetry of the rover. Every time we find something that seems strange to us, we go to the test bench and try to recreate the conditions and see if the problem manifests itself. When we find the reason, we can either change one of several thousand software parameters or send a patch, which is a small piece of code designed to solve the problem. Well, and obviously, after the problem is solved, we try to avoid conditions in which its repetition is possible.
Q: What is the most difficult thing in your work?
A: Well, besides all the paperwork that is part of the Curiosity management process ... ;-) It is very difficult to imagine all kinds of problems. Of course, we have vast experience managing the rover on Mars, but we still have to always be on our guard, in case something goes wrong. For example, when we move the rover, we always try to leave at least one path along which, if necessary, it can definitely go back. We also try to avoid actions that, even if very unlikely, can lead to disastrous consequences.
Q: What oddities or unusual situations did you have?
A: One of the funniest cases happened in 2006 during the work of MER. In general, this mission was designed for only 90 Solov, and when software was written, only three categories were assigned to the storage of Sol’s number. As the 999th Sol approached, we prepared a software update, and uploaded a new version to the rovers. It was a titanic work - it took us a whole year to write the update and test, plus it took several months to download the update to the rovers. The new on-board software [2] also required changes to the ground-based software [3], as it was incompatible with its old version. Therefore, we needed to reload both rovers into the same Sol, so that it would not happen that one of them was already working on the new software, and the other was still on the old one. So this day is finally coming. Spirit has the honor of rebooting first we send a reboot command with new software, the rover sends a response, everything is great. Opportunity at this time is on the other side of the planet, and we have to wait 12 hours before we can send him the right team. And right before that, backbon [the trunk ] in JPL is disconnected, and without it we cannot transmit commands from our servers to the DSN [Deep Space Network] station. So, the time is running out, and the backbone is still not working. What to do?! Fortunately, one of the computers in the control center had a direct line with the DSN station (in Canberra, it seems), and this computer also had a ... floppy drive! Fortunately, one of the MER computers also has a floppy drive, but who will have a floppy disk in 2006? But there was nothing else left, and we began to run around the laboratory in search of a floppy disk. We finally found the floppy disk in some forgotten desk drawer, quickly reformatted it, copied the commands, and ran to the control center to send them. In the end, we even had two minutes left!
[2] [Paolo uses the term flight software, which in aviation and astronautics usually means "flight control software." In this case, we mean the part of the software that is on the rover itself. ]
[3] [ Paolo uses the term ground software, and refers to the part of the software that is used on Earth ]
Q: How many people control the rover?
A: Well, it depends on what you mean by the word “govern”. Now we have 16 drivers, but the team of people who control various equipment (cameras, SAM, CheMin, ChemCam ...) numbers, I think, almost 100 people.
Q: Is there a built-in “protection against the fool” on the rover?
A: You know, as they say, there can be no complete “defense against a fool,” since fools are too inventive.
Q: If the programmed movement of the arm-manipulator can demolish, for example, some antenna or simply crash into the body of the rover, will such a program be blocked automatically (for example, after checking on a computer model), or does it have to be monitored manually?
A: The rover software checks if any of its parts can collide with others, so in this case the command simply will not be executed, an error will be generated, and the rover will stop the manipulator. If any of the following commands depends on the position of the manipulator (for example, a shot from a laser), then these actions will also not be performed.
But even considering that this software protects the rover, we still double-check (three times, and four times) that this could not happen. We also try to make sure that this cannot happen even if the manipulator, or other parts of the rover, are not quite where they should be. Sometimes it is impossible to predict the exact conditions on Mars. Of course, we have cameras and a 3D map of the area, but this data can always contain inaccuracies related to measurement errors. Therefore, we need to make sure that the programmed actions will be performed safely even if the error is high enough.

Q: What is the relationship with the rover? What antennas / modems are used for this? What are the low-level protocols? How do higher-level protocols deal with errors in transmitting information?
A: We send commands from Earth directly to the rover antenna, which is called HGA (High Gain Antenna), using one of the DSN stations. Communication is in the X-band (7-8 GHz). Here in this PDF you can find all the information you can imagine.
The data that the rover collects for the day is sent back using the UHF antenna [4] - it looks like a black cylinder to the right of the RTG [it is black on the ground copy, and on Mars it is in silver foil, RTG is the RTG, Prim Zelenyikot] - to one of the satellites (MRO or ODY), after which the satellites transmit data to the DSN stations (again in the X-band, if I'm not mistaken). Typically, the amount of data we received from MER was about 100 megabits. Much more data comes from MSL - an average of about 500 megabits, but once we had a really gigantic transfer of 1200 megabits.
[4] [ Ultra High Frequency ]
Q: What are the main features and differences of photographing in Martian conditions compared to earth? What additional knowledge should a Martian “photographer” have? For example, does the dominance or degradation of certain colors take place differently from what we are used to seeing on Earth, just as these differences are noticeable in underwater photography. First of all, photographs familiar to the human eye are of interest, not photographs that reflect the invisible part of the spectrum.
A: Mike Caplinger [ one of the people responsible for the cameras ] could provide much more information to this question , but of course I will try to answer.
The atmosphere of Mars is much thinner than that of the Earth, and much more predictable. There is a certain amount of dust in the atmosphere, so at large distances you will see some deterioration in the picture; sometimes the atmosphere looks like dirty air in the bay of Los Angeles. Being farther from the Sun than the Earth, Mars receives a little less light, but on the whole, as it seems to me, there are no significant differences. In fact, taking a photo on Earth is more difficult than on Mars, as here you will find much greater differences in color, brightness and contrast.
Q: Was the rover shooting program more difficult than other daily programs?

[ It seems that Paolo did not understand the question. We tried to ask about a self-portrait, and he answers about this video shooting - Note. Zelenyikot ]:
A: The cameras developed by Mars Space Science Systems are designed to capture video at up to 15 hertz (or frames per second, if you want), and they have built-in memory, so for us this does not present any problems. The only difficulties that could potentially arise are the duration of the video, the frame rate, and then to make sure that the video starts at the right time and the cameras are rotated in the right direction. Again, Mike Caplinger could answer this question in more detail than I did.
Q: Are there any algorithms for self-recovery from an emergency, or when it occurs, the program is interrupted and the device enters standby mode?
A: There are several levels of action in case of emergency. If an error is detected in the commands that we sent, the rover will simply refuse to execute them. If the problem occurs during the execution of the command (as in the example with the hand that I mentioned above), the rover will send an error message and simply refuse to use one or more devices. Finally, if there is some kind of bug in the software, the rover will reboot and go into “safe mode”. In this case, he will perform a pre-programmed set of actions, including sending an error message, and will wait for instructions from Earth to continue working. In case the software freezes, we have watchdog timers that can restart the rover and put it into safe mode. So we don’t have a blue screen of death.
IN:What parameters of the rover do you track for this in “real time” mode or close to it?
A: I hope the answer to the question above answers this question.
Q: In what cases does the rover safety system independently terminate the program?
A: It seems that on MSL we had one hardware reboot, but I don’t remember what was the reason. MER rebooted many times, including repeated cases caused by radiation effects on the processor and memory. Depending on the reason for the reboot, such situations are considered insignificant (as is the case with cosmic radiation), or as significant (such as, for example, the Spirit anomaly on the 18th Sol).
Q: Are there algorithms for self-recovery from an emergency?
A: As I just said, it depends on the reasons that caused the emergency.
Q: Does Curiosity use the DTN data transfer protocol / architecture, and if so, what are the minimum packet delays?
A: The minimum delay is 5 minutes, the maximum is 20, but since we do not work with rovers in real time, this delay does not affect control. We do not use DTN, but we have some technologies that help establish communications over such long distances. Usually, for one Sol, we collect much more data than we can transfer, so we have to choose exactly which data will be sent to Earth in each Sol. Each piece of data gets priority, and the most important of them will be transmitted in the first place, and the less important will be sent later (or will not be sent at all). Of course, if we suddenly decide that the importance of the data has been judged incorrectly, then we can change priorities. For example, if on a miniature we see that the camera was turned in the wrong direction, then we either lower the priority, or delete the full-size image altogether, and vice versa: if we have an image with a better exposure, then its priority will be increased. Moreover, the data is divided into packets - this is important for transferring large amounts of information, for example, the same images. That is why some of the images you saw had holes. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again.
<.....>
As you can see, this part of the interview turned out to be more professional. Here we recognized Paolo as a JPL specialist. I distributed the questions so that at first they were serious, and then not quite. The second part was also enough for serious ones, but she will talk more about Paolo as a person, as well as about the relationship of Curiosity and Martians, about people in black hiring at NASA, and whether the driver of the rover dreams of Mars.
If I really want to continue, I can offer you to watch this little Paolo interview on the NASA website for now, and be patient and wait a couple of days when the work on the translation is completed. Thanks again, Singerofthefall for his work.
To be continued.
This wonderful translation is provided by Singerofthefall . Paolo's text was sent in bulk, so we divided the answers in half, and the translator will publish the second part. Therefore, you can thank him now, and you can later, when he finishes work on the second part and puts it out. [1]
[1] In square brackets translator's notes.
I posted the full English text on Google and anyone who wishes can contact him, but believe me, this is not necessary because the translation is excellent.
So, let's start our interview:

Q: What is your work schedule?
A: After the first 90 days during which we lived according to Martian time, we switched to the usual schedule. Typically, a business day runs from 8am to 8pm Pacific Standard Time (PST). We work every day, including Saturday and Sunday, but rested, for example, on Thanksgiving and Christmas. Before the holidays, we prepared the teams in advance for a few days in advance, so we managed to stay home, but the rover had to work without a break. Soon we will switch to a 6-day working week, and after the confrontation of Mars [the moment when the Sun is exactly on the line between the Earth and Mars will be in April] we’ll probably switch to the usual five-day one. Although the rover will continue to work every day, it [1] has no days off :-(
[1] [ Paolo speaks of a female rover - she - apparently by analogy with ships to which this pronoun is also used in English. Although now they are practically animating it and treat it not like a ship, but like a girl :)
Elevator doors in JPL NASA.

Since this is unusual for a Russian audience, I will use the pronoun “he” - the rover ]
Q: How is the code for the next-day traffic program checked / debugged? How many people check the code before sending? Are emulators used to check the movement program before sending to the rover? What do they do if they find errors in a submitted traffic program?
A: Great questions! To prepare the teams, we use software specially developed for these purposes in JPL. We have a dedicated editor called RoSE (Robot Sequence Editor - Sequence Editor [ actions ] of the robot), which is the most simple errors - typos in the names of the teams, the error range of parameter values, and so on. A simulator called Hyperdrive is connected to the editor. It receives images that were made in previous Solas, and shows a three-dimensional image of the area surrounding the rover. Then the simulator receives a list of commands and shows what the rover will do, and how it will interact with the environment. You can also simulate basic telemetry, such as location and direction.
For the most important tasks, such as drilling using a manipulator, we sometimes use a prototype.

When it seems to us that the command set does not contain errors, we pass it on to other drivers for verification. Usually at least three people work each shift (a driving specialist, a specialist in using a robotic arm, and a specialist in using tools), but sometimes there are more people left, and they all check the prepared teams. During the shift, we also pass five formal checks, which are carried out by a group of a dozen people, and not all of them are drivers of the rover, since during the daily work we have to use various tools, and we need to make sure that none of the teams can entail equipment failure, or, well, damage to the rover. We also have software for additional verification of commands, and a long list of things that need to be checked every time.
We try not to make mistakes, but sometimes they happen, and a fairly large part of the software on the rover must check that the commands are not meaningless, and that we are not trying to do any stupid thing like shooting from a laser at the rover itself. So even if we make a mistake here on Earth, a rover on Mars will detect it.
Q: How is testing on earth (is there a copy of the rover in the desert on the home planet?)
A: We have two devices. The first is called VSTB (Vehicle Surface Testbed), and all the equipment is installed on it, including cameras and a hand, so we can control it just like a rover on Mars. Every time we need to ensure the special reliability of the program, we use it. Here - photojournal.jpl.nasa.gov/catalog/PIA15876 - there is his photo. The second unit, called the Scarecrow, is equipped only with wheels and an engine. We use it to test movement on various types of surfaces.
We also have two training grounds in JPL, one of them is in the building, it is called In-Situ Instrument Laboratory:

And the other is in the open air - Mars Yard, where we can conduct more tests for movement.
( At 0:33 in the frame, Paolo flashes - the cable pulls )
In May 2012, before landing the rover, we drove the Scarecrow into the desert near the Death Valley in California to check how he would behave in the sand, as it bothered us that the rover could land on the sand dunes.
Q: What do programmers train on?
A: We teach each other. Someone has experience in management, someone helped create a rover, someone participated in writing software. Believe me, all this requires a lot of experience and practice.

IN:After the Curiosity rover completes the entire planned research program, is it planned to provide part of the rover’s resources and time (if at that time it will be operational) at the disposal of students to carry out educational scientific experiments?
A: Actually, a huge number of scientists and students of various universities are working on this mission. Their task is to decide what experiments we should conduct and monitor the progress of their implementation. Honestly, I don’t think that we will ever finish all our experiments at all, since their list is constantly updated - as soon as we find the answer to one of the questions, we immediately have 10 others!
IN:Are there plans for NASA to visit the rover of the landing sites of previous devices for exploring Mars? Most of them have already failed, but it would be interesting to establish the true cause on the spot. Moreover, photographs of these once legendary devices would have a very high aesthetic, and material value.
A: At the moment, our main goal is to explore as much of the planet as possible, so returning to where we have already been would not be very useful, even if we return with more tools. Understanding the reason why our old robots are out of order is still a less important task than collecting new scientific data. So, although I share your desire to see these devices again, I do not think that this will happen in the near future.
Q: How do you solve the problem of a 7 minute signal delay? And is this a big problem?
A: Signal delay due to distance varies from 5 to 20 minutes one way. Now this time is close to maximum, and is about 19 minutes. Of course, the delay is too long for us to be able to control the rover interactively. Think about it - if you see an obstacle in front of the rover, and immediately send a command to stop, then even with the smallest possible delay you will already be 10 minutes late! Therefore, we manage it by sending a sequence of commands every day. In addition, we could not control the rover interactively also because the Earth is not always visible from Gale Crater, in which Curiosity is located. And finally, even if you do not take all this into account, calling the rover is quite expensive - about $ 10,000 per hour!
In general, the delay before receiving data is usually even greater, since we transmit the signal through the Mars Odyssey and Mars Reconnaissance Orbiter satellites. It usually takes at least several hours to get data from the rovers.
Q: Is there any tool or device that is very lacking in Curiosity in your work?
A: More scientific instruments, a more powerful computer, more space for data storage, more options for their transfer, more energy, a higher resolution camera, a higher mast ...
Q: Have there been times when you wrote a program for the day, but already during of its execution, it became clear that a critical error crept into the program’s work, which is too late to fix, but if it’s too late, how do you fix it?
A: Of course! On MER, we found some bugs years after landing. One of the critical bugs was found on the Spirit rover on the 18th Sol, and the other we found at all in 2007 when we traveled around Victoria Crater. We have a team of specialists (including myself) that analyzes the telemetry of the rover. Every time we find something that seems strange to us, we go to the test bench and try to recreate the conditions and see if the problem manifests itself. When we find the reason, we can either change one of several thousand software parameters or send a patch, which is a small piece of code designed to solve the problem. Well, and obviously, after the problem is solved, we try to avoid conditions in which its repetition is possible.
Q: What is the most difficult thing in your work?
A: Well, besides all the paperwork that is part of the Curiosity management process ... ;-) It is very difficult to imagine all kinds of problems. Of course, we have vast experience managing the rover on Mars, but we still have to always be on our guard, in case something goes wrong. For example, when we move the rover, we always try to leave at least one path along which, if necessary, it can definitely go back. We also try to avoid actions that, even if very unlikely, can lead to disastrous consequences.
Q: What oddities or unusual situations did you have?
A: One of the funniest cases happened in 2006 during the work of MER. In general, this mission was designed for only 90 Solov, and when software was written, only three categories were assigned to the storage of Sol’s number. As the 999th Sol approached, we prepared a software update, and uploaded a new version to the rovers. It was a titanic work - it took us a whole year to write the update and test, plus it took several months to download the update to the rovers. The new on-board software [2] also required changes to the ground-based software [3], as it was incompatible with its old version. Therefore, we needed to reload both rovers into the same Sol, so that it would not happen that one of them was already working on the new software, and the other was still on the old one. So this day is finally coming. Spirit has the honor of rebooting first we send a reboot command with new software, the rover sends a response, everything is great. Opportunity at this time is on the other side of the planet, and we have to wait 12 hours before we can send him the right team. And right before that, backbon [the trunk ] in JPL is disconnected, and without it we cannot transmit commands from our servers to the DSN [Deep Space Network] station. So, the time is running out, and the backbone is still not working. What to do?! Fortunately, one of the computers in the control center had a direct line with the DSN station (in Canberra, it seems), and this computer also had a ... floppy drive! Fortunately, one of the MER computers also has a floppy drive, but who will have a floppy disk in 2006? But there was nothing else left, and we began to run around the laboratory in search of a floppy disk. We finally found the floppy disk in some forgotten desk drawer, quickly reformatted it, copied the commands, and ran to the control center to send them. In the end, we even had two minutes left!
[2] [Paolo uses the term flight software, which in aviation and astronautics usually means "flight control software." In this case, we mean the part of the software that is on the rover itself. ]
[3] [ Paolo uses the term ground software, and refers to the part of the software that is used on Earth ]
Q: How many people control the rover?
A: Well, it depends on what you mean by the word “govern”. Now we have 16 drivers, but the team of people who control various equipment (cameras, SAM, CheMin, ChemCam ...) numbers, I think, almost 100 people.
Q: Is there a built-in “protection against the fool” on the rover?
A: You know, as they say, there can be no complete “defense against a fool,” since fools are too inventive.
Q: If the programmed movement of the arm-manipulator can demolish, for example, some antenna or simply crash into the body of the rover, will such a program be blocked automatically (for example, after checking on a computer model), or does it have to be monitored manually?
A: The rover software checks if any of its parts can collide with others, so in this case the command simply will not be executed, an error will be generated, and the rover will stop the manipulator. If any of the following commands depends on the position of the manipulator (for example, a shot from a laser), then these actions will also not be performed.
But even considering that this software protects the rover, we still double-check (three times, and four times) that this could not happen. We also try to make sure that this cannot happen even if the manipulator, or other parts of the rover, are not quite where they should be. Sometimes it is impossible to predict the exact conditions on Mars. Of course, we have cameras and a 3D map of the area, but this data can always contain inaccuracies related to measurement errors. Therefore, we need to make sure that the programmed actions will be performed safely even if the error is high enough.

Q: What is the relationship with the rover? What antennas / modems are used for this? What are the low-level protocols? How do higher-level protocols deal with errors in transmitting information?
A: We send commands from Earth directly to the rover antenna, which is called HGA (High Gain Antenna), using one of the DSN stations. Communication is in the X-band (7-8 GHz). Here in this PDF you can find all the information you can imagine.
The data that the rover collects for the day is sent back using the UHF antenna [4] - it looks like a black cylinder to the right of the RTG [it is black on the ground copy, and on Mars it is in silver foil, RTG is the RTG, Prim Zelenyikot] - to one of the satellites (MRO or ODY), after which the satellites transmit data to the DSN stations (again in the X-band, if I'm not mistaken). Typically, the amount of data we received from MER was about 100 megabits. Much more data comes from MSL - an average of about 500 megabits, but once we had a really gigantic transfer of 1200 megabits.
[4] [ Ultra High Frequency ]
Q: What are the main features and differences of photographing in Martian conditions compared to earth? What additional knowledge should a Martian “photographer” have? For example, does the dominance or degradation of certain colors take place differently from what we are used to seeing on Earth, just as these differences are noticeable in underwater photography. First of all, photographs familiar to the human eye are of interest, not photographs that reflect the invisible part of the spectrum.
A: Mike Caplinger [ one of the people responsible for the cameras ] could provide much more information to this question , but of course I will try to answer.
The atmosphere of Mars is much thinner than that of the Earth, and much more predictable. There is a certain amount of dust in the atmosphere, so at large distances you will see some deterioration in the picture; sometimes the atmosphere looks like dirty air in the bay of Los Angeles. Being farther from the Sun than the Earth, Mars receives a little less light, but on the whole, as it seems to me, there are no significant differences. In fact, taking a photo on Earth is more difficult than on Mars, as here you will find much greater differences in color, brightness and contrast.
Q: Was the rover shooting program more difficult than other daily programs?

[ It seems that Paolo did not understand the question. We tried to ask about a self-portrait, and he answers about this video shooting - Note. Zelenyikot ]:
A: The cameras developed by Mars Space Science Systems are designed to capture video at up to 15 hertz (or frames per second, if you want), and they have built-in memory, so for us this does not present any problems. The only difficulties that could potentially arise are the duration of the video, the frame rate, and then to make sure that the video starts at the right time and the cameras are rotated in the right direction. Again, Mike Caplinger could answer this question in more detail than I did.
Q: Are there any algorithms for self-recovery from an emergency, or when it occurs, the program is interrupted and the device enters standby mode?
A: There are several levels of action in case of emergency. If an error is detected in the commands that we sent, the rover will simply refuse to execute them. If the problem occurs during the execution of the command (as in the example with the hand that I mentioned above), the rover will send an error message and simply refuse to use one or more devices. Finally, if there is some kind of bug in the software, the rover will reboot and go into “safe mode”. In this case, he will perform a pre-programmed set of actions, including sending an error message, and will wait for instructions from Earth to continue working. In case the software freezes, we have watchdog timers that can restart the rover and put it into safe mode. So we don’t have a blue screen of death.
IN:What parameters of the rover do you track for this in “real time” mode or close to it?
A: I hope the answer to the question above answers this question.
Q: In what cases does the rover safety system independently terminate the program?
A: It seems that on MSL we had one hardware reboot, but I don’t remember what was the reason. MER rebooted many times, including repeated cases caused by radiation effects on the processor and memory. Depending on the reason for the reboot, such situations are considered insignificant (as is the case with cosmic radiation), or as significant (such as, for example, the Spirit anomaly on the 18th Sol).
Q: Are there algorithms for self-recovery from an emergency?
A: As I just said, it depends on the reasons that caused the emergency.
Q: Does Curiosity use the DTN data transfer protocol / architecture, and if so, what are the minimum packet delays?
A: The minimum delay is 5 minutes, the maximum is 20, but since we do not work with rovers in real time, this delay does not affect control. We do not use DTN, but we have some technologies that help establish communications over such long distances. Usually, for one Sol, we collect much more data than we can transfer, so we have to choose exactly which data will be sent to Earth in each Sol. Each piece of data gets priority, and the most important of them will be transmitted in the first place, and the less important will be sent later (or will not be sent at all). Of course, if we suddenly decide that the importance of the data has been judged incorrectly, then we can change priorities. For example, if on a miniature we see that the camera was turned in the wrong direction, then we either lower the priority, or delete the full-size image altogether, and vice versa: if we have an image with a better exposure, then its priority will be increased. Moreover, the data is divided into packets - this is important for transferring large amounts of information, for example, the same images. That is why some of the images you saw had holes. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again. Part of the data may have been lost during transmission, or may have been transmitted with errors. Of course, in case of errors, we can try to transfer the data again.
<.....>
As you can see, this part of the interview turned out to be more professional. Here we recognized Paolo as a JPL specialist. I distributed the questions so that at first they were serious, and then not quite. The second part was also enough for serious ones, but she will talk more about Paolo as a person, as well as about the relationship of Curiosity and Martians, about people in black hiring at NASA, and whether the driver of the rover dreams of Mars.
If I really want to continue, I can offer you to watch this little Paolo interview on the NASA website for now, and be patient and wait a couple of days when the work on the translation is completed. Thanks again, Singerofthefall for his work.
To be continued.