Study, design, simulation and implementation of terrain detection algorithm for the navigation task of the European Rover Challenge

Study, design, simulation and implementation of terrain detection algorithm for the navigation task of the European Rover Challenge Document: Mem` oria Autor: Adri` a Barja Pel´ aez Director / Co-director: Jaume Figueras Jove / Antonio Guasch Petit Titulaci´ o: M` aster Universitari en Enginyeria Aeron` autica Convocat` oria: Tardor, 2022 Agra¨ ıments Moltes gr` acies a la meva fam´ ılia, en especial als meus pares, per donar-me suport en tots els meus projectes i per ensenyar-me que sense importar la situaci´ o s’ha de continuar lluitant i tirar endavant. Un agra¨ ıment especial a la meva parella, la N´ uria, per haver estat un suport en tot moment i no deixar-me abandonar, sense tu aquest projecte no s’hauria presentat. Un agra¨ ıment tamb´ e als meus companys i amics de l’associaci´ o UPC Space Program per haverme perm` es desenvolupar projectes que m’apassionen i viure experi` encies incre¨ ıbles. I finalment, moltes gr` acies al meu tutor, Jaume Figueras per haver sigut comprensiu i pacient, i haver-me introdu¨ ıt en el m´ on dels robots m` obils. Abstract This project develops an algorithm for detecting the terrain and finding the position of the robot to be used in the Navigation task of the European Rover Challenge with the GRover robot from the UPC Space Program association. The localization is developed by detecting AR Tags placed at reference points with known coordinates using a custom marker dictionary in OpenCV and using ROS and gazebo to set up a simulation environment with the robot model. The marker detection is tested with the cameras, the movement of the robot on the real terrain is simulated, and in the simulation of the Navigation Task, results are obtained where the calculated positions have a deviation of 1.34 m by calculating the position at all angles with variations of π/4 radians. It can be concluded that the marker-based positioning algorithm is suitable, but it needs other sensors to reduce the deviation and the possibility of changing the arrangement of the cameras on the robot is presented. Resum Aquest projecte desenvolupa un algorisme per detectar el terreny i trobar la posici´ o del robot per utilitzar-se a la tasca de navegaci´ o del European Rover Challenge amb el robot GRover de l’associaci´ o UPC Space Program. La localitzaci´ o es desenvolupa detectant AR Tags situats en punts de refer` encia amb coordenades conegudes fent servir un diccionari de marcadors personalitzat a OpenCV i fent servir ROS i gazebo per preparar un entorn de simulaci´ o amb el model del robot. Es prova la detecci´ o de marcadors amb les c` ameres, es simula el moviment del robot pel terreny real i en la simulaci´ o de la tasca de navegaci´ o es obtenen uns resultats on les posicions calculades presenten una desviaci´ o de 1,34 m fent el c` alcul de la posici´ o en tots els angles amb variacions de π/4 radians. Es pot concloure que l’algorisme de posicionament mitjanc¸ant la detecci´ o de marcadors ´ es adequat, per` o necessita altres sensors per reduir la desviaci´ o i es presenta la possibilitat de canviar la disposici´ o de les c` ameres al robot. Declaration of Honour I declare that, the work in this Master Thesis is completely my own work, no part of this Master Thesis is taken from other people’s work without giving them credit, all references have been clearly cited, I understand that an infringement of this declaration leaves me subject to the foreseen disciplinary actions by the Universitat Polit` ecnica de Catalunya - BarcelonaTECH. Adri` a Barja Pel´ aez 01/07/2022 Student Name: Signature: Date: Terrain detection algorithm for the European Rover Challenge Contents 1 Introduction 1 1.1 Object............................................ 1 1.2 Scope............................................ 1 1.3 Requirements........................................ 1 1.4 Justification......................................... 2 2 State of the art 3 2.1 Robotics........................................... 3 2.2 MobileRobots ....................................... 3 2.3 ROS............................................. 5 2.4 Robotcompetitions..................................... 6 2.5 EuropeanRoverChallenge ................................ 7 2.5.1 NavigationTask .................................. 8 3 Theoretical framework 11 3.1 ComputerVision ...................................... 11 3.1.1 ARTags....................................... 11 3.1.2 OpenCV....................................... 12 3.1.3 Detectionofmarkers................................ 12 3.1.4 Customdictionary ................................. 13 3.2 Cameracalibration..................................... 14 3.2.1 Calibrationcode .................................. 15 3.3 Odometry.......................................... 16 3.4 Simultaneous Localisation and Mapping (SLAM) . . . . . . . . . . . . . . . . . . . . 17 4 Elements decisions 18 4.1 Environmentselection ................................... 18 4.2 Libraries........................................... 18 4.2.1 Rospy........................................ 18 4.2.2 Roscpp ....................................... 18 4.2.3 OpenCV....................................... 18 4.2.4 CvBridge...................................... 19 4.2.5 Numpy ....................................... 19 4.3 Nodeandtopicsdefinition................................. 19 5 Robot definition 21 5.1 Structure .......................................... 21 5.2 Tractionandsuspension.................................. 22 5.3 Batterymodules ...................................... 22 i Terrain detection algorithm for the European Rover Challenge 5.4 RoboticArm......................................... 23 5.5 Electronicsmodules .................................... 23 5.6 Software........................................... 24 5.7 Simulation model definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6 Software structure 29 6.1 Vision ............................................ 29 6.2 Navigation.......................................... 30 6.3 Position ........................................... 33 7 Results 37 7.1 Cameracalibration..................................... 37 7.2 Custom dictionary generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3 Markerdetection ...................................... 39 7.4 Model description movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.5 ARTagimplementation .................................. 44 7.6 Model detection of markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.7 Locationofthemodel ................................... 48 7.8 CustommapwithARTag ................................. 48 7.9 Navigation task simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.9.1 WaypointA ..................................... 52 7.9.2 WaypointF ..................................... 53 7.9.3 WaypointG..................................... 54 7.9.4 WaypointH..................................... 55 7.9.5 Finaljudging .................................... 56 7.10 European Rover Challenge 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 8 Budget 61 8.1 Costofworker ....................................... 61 8.2 Softwarecost........................................ 61 8.3 Electriccost......................................... 61 8.4 Components ........................................ 61 8.5 AttendancetotheERC22 ................................. 61 8.6 Totalbudget......................................... 62 9 Social and Environmental implications 63 10 Conclusions 64 11 Future improvements 65 ii Terrain detection algorithm for the European Rover Challenge A Code 69 A.1 Camerapublishers..................................... 69 A.2 Customdictionary ..................................... 71 A.3 Markerdetection ...................................... 74 A.4 Robotlocation ....................................... 80 A.5 Cameracalibration..................................... 83 A.6 Customtaggenerator ................................... 85 A.7 Robotmodeldefinition................................... 86 A.8 Simulationlauncher ....................................106 A.9 Controllersdefinition....................................107 A.10Controllerslauncher ....................................108 A.11Modelyawpublisher....................................109 B Appendix 110 B.1 Landmarks .........................................111 B.2 Cameraview ........................................118 iii Terrain detection algorithm for the European Rover Challenge List of Figures 1 Diagram of Martian Rovers [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 AGH Space Systems is the winner of the ERC2022 edition. [23] . . . . . . . . . . . 7 3 Dimensions of landmarks [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 ERC22 Marsyard with landmark position. [24] . . . . . . . . . . . . . . . . . . . . . . 9 5 ARTag1.[24] ....................................... 12 6 AR Tag marker conversion to a matrix. Own image . . . . . . . . . . . . . . . . . . . 13 7 Chess board distorted in the camera with the straight lines drawn. [28] . . . . . . . . 14 8 Chess board with calibration pattern drawn. [28] . . . . . . . . . . . . . . . . . . . . 15 9 Diagram of the intention of odometry. [30] . . . . . . . . . . . . . . . . . . . . . . . . 16 10 Diagram of the function of Cv Bridge [34] . . . . . . . . . . . . . . . . . . . . . . . . 19 11 Diagram of nodes and rostopics. Own image . . . . . . . . . . . . . . . . . . . . . . 20 12 CAD model of the ERC22 robot. Own image . . . . . . . . . . . . . . . . . . . . . . 21 13 Structure of the robot next to a wheel. [36] . . . . . . . . . . . . . . . . . . . . . . . . 21 14 Traction systems and wheels . [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15 Batterymodule.[36] .................................... 22 16 Roboticarmextended.[36] ................................ 23 17 Software scheme. Own image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 18 Scheme of joystick control. [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 19 Scheme of wheels control. [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 20 Scheme of robotic arm control. [36] . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 21 Simplified model of the ERC2022. Own image . . . . . . . . . . . . . . . . . . . . . 27 22 ERC22 model represented in rviz. Own image . . . . . . . . . . . . . . . . . . . . . 28 23 Diagram of the vision package. Own image . . . . . . . . . . . . . . . . . . . . . . . 29 24 Diagram of the navigation package. Own image . . . . . . . . . . . . . . . . . . . . . 32 25 Camera axes conversion to robot axes with formulas left side. Own image . . . . . . 35 26 Camera axes conversion to robot axes with formulas right side. Own image . . . . . 35 27 Robot axes conversion to terrain axes using the yaw angle (θ). Own image . . . . . 36 28 Diagram of the position package. Own image . . . . . . . . . . . . . . . . . . . . . . 36 29 Chessboard template and sample images. Own image . . . . . . . . . . . . . . . . . 37 30 Chessboard template and sample images with the calibration pattern. Own image . 38 31 Generated AR Tag used by the organisation. Own image . . . . . . . . . . . . . . . 39 32 Detection of custom AR Tag. Own image . . . . . . . . . . . . . . . . . . . . . . . . 39 33 Model collapsing to origin. Own image . . . . . . . . . . . . . . . . . . . . . . . . . . 41 34 PID tunning using the real-time configuration. Own image . . . . . . . . . . . . . . . 42 35 Simulation with brakes and rotatory wheels steady. Own image . . . . . . . . . . . . 42 36 Simulation of the stepper with the rqt command. Own image . . . . . . . . . . . . . 43 37 Simulation of rectilineal movement with the rqt command. Own image . . . . . . . . 43 38 Simulation of rotation with the rqt command. Own image . . . . . . . . . . . . . . . . 44 39 Model of the LandMark 1. Own image . . . . . . . . . . . . . . . . . . . . . . . . . . 44 iv Terrain detection algorithm for the European Rover Challenge 2 State of the art 2.1 Robotics Robotics is the branch of mechanical engineering, electronic engineering and computer science that deals with the design, construction, operation, structure, manufacture and application of robots. The first time the word ”robot” was used was in 1921, when Karel Capek wrote Rossum’s Universal Robots (RUR). This was a work of science fiction about the rapid evolution of technology and, as a consequence, the revolt of robots against humans. Etymologically speaking, the word ”robot” comes from the Czech ”robota” and means slave or servant. Although the concept emerged in 1921, it was not until 1958 that it ceased to be a science fiction concept. When Ultimation introduced Unimate, designed to assist in the production of automobiles. [2] It should also be borne in mind that in order to develop this first application of robotics, mechanical devices have been created and perfected over the centuries to facilitate physical tasks or simply to create entertainment. Such is the case of the Egyptian water clocks that used human figurines to ring the hour bells, or centuries later, in 1557, the wooden figure created by Giovanni Torriani that could bring the emperor his daily bread from the shop. These would be what we can call the antecedents of the first robot. [3] The evolution of robotics has been considerable, going from being applied in specific processes to being used on a daily basis in all kinds of fields, including aerospace. But not only that, but throughout history it has always had the same objective: to facilitate people’s tasks and improve their lifestyle. 2.2 Mobile Robots Mobile robots are computational systems that are able to move and have sensors that allow them to gather information from their surroundings and actuators that enable their movement. According to Guarnizo, Bautista, and Sierra [4], mobile robots are defined as computational entities that have the ability to move and are equipped with sensors and actuators that help them interact with and navigate their environment. Therefore, due to their capabilities, they are not only intended to facilitate difficult tasks for people, but can also help to solve specific tasks that are performed in one or more difficult locations. Historically, the military sector has been an area that due to its high funding has helped to develop new technologies, such as mobile robots. This is no different, as it was during World War II 3 Terrain detection algorithm for the European Rover Challenge that the Germans built the V1 and V2 missiles. The latter being the forerunner of today’s rockets.[4] A striking predecessor that bears a closer resemblance to what we consider today’s mobile robot is the Speculatrix or ”turtle”, created in 1948 by W. Walter Grey. It could: clumsily avoid obstacles, return to its resting area and recharge its batteries before they ran out. In keeping with the theme of this project, if we look at mobile robots for aerospace use, better known as ”rovers”, the first were those dedicated to discovering the moon. The first rover was the Soviet Lunokhod 1, which landed on the Moon in 1970. It was followed by Lunokhod 2 in 1973. Both rovers were tasked with collecting topographic information about the lunar soil, as well as its chemical and physical composition, and measuring solar radiation. [5] The Lunokhods have been two of only four rovers to explore our satellite. The other two, of Chinese origin, Yutu and Yutu 2, would not set foot on it until 2013 and 2019 respectively. The latter, being historically relevant to discover the hidden face of the Moon. [6] [7] In addition to exploring the Moon, there has also been a desire to find out more about Mars. Several attempts have been made to land on Mars, with unsatisfactory results. It was not until 1997 that Sojourner arrived on Mars. The first ”Martian” rover sent more than 500 images of the star back to Earth, having been active for 85 days. The next to arrive were Spirit and Opportunity, launched in 2003. Spirit was the first to send back colour images, check volcanic activity and discover the presence of water on Mars. Opportunity managed to stay active the longest and set the record for distance travelled: 45 kilometres. It also sent the first image we have of the Earth from another planet. If we compare the latter with the first Martian rover, the latter collected more than 200,000 images. [8] In 2012 Curiosity lands, with the aim of determining whether there has been life on Mars. It is still active, sending back information of all kinds. [9] The last rover to be sent was Perseverance, which arrived in 2021. The novelty of this mission is the incorporation of an explorer helicopter (Ingenuity). The Perseverance is a car-size rover, which is 3 meters long, 2.7 meters wide, 2.2 meters tall and weights 1,025 kilograms [10]. Besides, it includes a large number of new technologies as: an autopilot which avoids dangers, named Terrain Relative Navigation, a new autonomous navigation system, and a set of sensors to facilitate the landing. Thanks to these technologies, the spaceship could understand its location and modify the trajectory during the landing [11]. Events such as the first helicopter flight on Mars have been achieved, as well as transforming the 4 Terrain detection algorithm for the European Rover Challenge carbon dioxide in its atmosphere into oxygen. [12] The following image presents the progress of the martian rovers: Figure 1: Diagram of Martian Rovers [13] 2.3 ROS ROS, or Robot Operating System [14], is an open-source middleware designed to support the development of robots. It is a collection of software libraries and tools that can be used to create and operate robots. ROS provides a framework for building robot applications, and it is often used as a platform for creating robot software. It is a widely used and well-respected system in the robotics community, and it is often used in research and industry to build and operate robots. The Stanford Artificial Intelligence Laboratory first created ROS in 2007 under the name “switchyard” to serve the Stanford Artificial Intelligence Robot (STAIR2) project. Since 2008, the majority of the work has taken place at Willow Garage, a federated development model collaboration between more than twenty institutions. [15] The ROS architecture is based on a graph architecture where processing occurs at nodes, which can receive and send topics to a data stream so that other nodes can publish and subscribe. ROS presents two important parts, the operating system, ROS itself and the ROS packages developed by the community. The packages implement features such as localisation, mapping, simulation, etc. This, together with the fact that it is licensed for commercial and research use, makes ROS an open system with a large development community that continues to grow the environment and add functionalities. 5 Terrain detection algorithm for the European Rover Challenge 2.4 Robot competitions The development of mobile robots has also led to their use in playful environments, such as competitions. Thus, from the 1970s to the present day, robotics competitions of various themes have been created. The first one we know of was in 1979, when the IEEE (Institute of Electrical and Electronics Engineers) organised a Micromouse competition. This consisted of small mouse-shaped robots that had to get out of a maze. An interesting fact about these competitions is that they are still held today. [16] Although there is not much historical information about robot contests, there are two that are considered the longest running, the All Japan Sumo and the Trinity College International Fire Fighting Robot Contest. [17] [18] Nowadays, it is difficult to establish categories of participation, as they vary according to various concepts. One of them is according to their orientation: as a hobby, aimed at students and/or intended for a more professional level. Some of the most prominent types of competitions at present are: -The Maze or Micromouse: contest in which teams of robots compete to see which one can solve a maze the fastest. These robots are typically designed to be small and agile, and are equipped with sensors, control logic, and actuators that allow them to navigate through a maze and find their way to the centre. The goal of the competition is to see which team can build and operate the best maze-solving robot. [16] -Sumo robots: robots compete in a simulated sumo wrestling match. These robots are designed for strength and power, and are equipped with sensors and technology to push their opponents out of the ring. The goal is to see which team can build and operate the best sumo robot. [19] -Fire extinguishers: This type of competition involves the mobile robot being able to autonomously, using sensors, control logic and actuators, respond to an alarm, discover where the fire is, and extinguish it. There are also more difficult versions where the robot must first rescue a baby in danger from the fire. -Footballer humanoid: a contest in which teams of humanoid robots compete in a game of football. These robots are controlled by humans who use sensors and technology to guide their movements. The goal is to see which team can build and operate the best robot. [20] -Speed: A competition in which teams of robots race to see which can move the fastest. These robots are designed for speed and agility, and are equipped with sensors and technology to navigate a course. The goal is to see which team can build and operate the fastest robot. 6 Terrain detection algorithm for the European Rover Challenge -Battle bots: a competition in which teams of robots designed for combat compete against each other. These robots are typically equipped with weapons and armour, and are controlled by human operators who use a combination of sensors, control logic, and actuators to guide the robot’s movements and actions in battle. The goal of the competition is to see which team can build and operate the best combat robot. [21] Moreover, due to this project main theme, it must be taken into account the exploration competitions as the European Rover Challenge. 2.5 European Rover Challenge The European Rover Challenge [22] is an international space and robotics event that combines competition with scientific and technological shows. It has been inspiring a new generation and bringing the cosmos closer to the general public since 2014, while also making people aware of the growing role of modern technologies in our lives. Additionally, it serves as a meeting place for representatives of the European science and business communities interested in the use of space and robotics technologies. The European Rover Challenge winner of the past year is presented below: Figure 2: AGH Space Systems is the winner of the ERC2022 edition. [23] The main part of the project is an international robotics competition, where academic teams from around the world present their mobile robot designs, competing in challenges based on real ESA and NASA missions. The competition takes place on the world’s largest artificial Martian track, that is directly derived from the surface of the Red Planet. Since 2021, the competition is held in both formulas: ON-SITE (teams compete with self-constructed robots on MarsYard in Poland) and REMOTE (competitors from several continents will remotely control the robot, physically moving along a track located in Poland, on the campus of the Kielce University of Technology). 7 Terrain detection algorithm for the European Rover Challenge The challenge is divided in five different tasks: -Science Task: the aim of the science task is to prepare and execute a simple sciencedriven exploration plan of the MarsYard. This task is divided in two parts: science planning to analyse the ”landing site” and design a scientific mission in this area and the scientific exploration where the hypothesis stated in the previous part must be verified in the MarsYard. -Probing Task: this task consists of collecting 3 surfaces samples from the given locations, defined by judges. The rover has to reach the locations, take photos and collect material -Maintenance Task: the task is intended to demonstrate the ability of rovers to operate with a variety of elements mounted on a panel. The team has to use the rover’s manipulating device to set switches to the required positions, measure electrical parameters, set other panel controls and observe indicators’ feedback. -Presentation Task: the team introduces themselves and present his project. The presentation should contain how the team worked the project, technical solutions and the approach to solve the tasks. A Q&A session is performed at the end of the presentation. -Navigation Task: the team navigates the rover on the terrain using AR Tag landmarks as reference points to arrive at different waypoints determined by the organisation. The navigation task is explained in detail below as it is the one on which this project is based. 2.5.1 Navigation Task This task is intended to demonstrate the system’s ability for semi to fully autonomous traversal. The Team shall develop a project which gradually evolves into a fully autonomous system, traversing and gathering important data on its way. At an early stage, the system can be decoupled with the operator in the loop, but all planning and parameter estimation must be done by the computer system itself. This limits the operator to navigate the rover blindly i.e., without access to visual or any other spatial information. However, any kind of data can be processed on-board, providing the operator with support information about the localisation and state of the system. A smart navigation strategy, sensor fusion and image data processing are essential in this task. The time to perform the whole task is 20 minutes. The references distributed on the MarsYard which allow the location are called landmarks. A landmark is composed by a cube with a wooden pole to elevate it above the ground. Each face consists of a white background, the landmark number and the ARTag square corresponding to the landmark number. 8 Terrain detection algorithm for the European Rover Challenge Figure 3: Dimensions of landmarks [24] The Marsyard is presented below in the Figure 4 with the landmarks pointed. Moreover, the axis are presented and will be mentioned as Marsyard axis or coordinates. It must be noted that from any point of the terrain at least two references should be visible. Figure 4: ERC22 Marsyard with landmark position. [24] 9 Terrain detection algorithm for the European Rover Challenge The position in the Marsyard coordinates are presented in the Table 1 where the 0-ID landmark is the start of the task and the fourteenth reference is not used due to competition selection. ID XX.XX (m) YY.YY (m) 0 00.00 00.00 1 10.00 00.00 2 10.00 10.00 3 28.35 00.04 4 21.83 02.80 5 18.71 17.19 6 26.95 07.44 7 15.97 -07.57 8 17.87 07.57 9 10.00 -10.00 10 29.26 14.52 11 18.41 25.83 12 23.34 14.11 13 08.18 18.63 14 ——— ——– 15 02.27 16.84 Table 1: Landmark’s positions. [24] The objective of the task is to navigate to four waypoints (Table 2) specified by the competition. The maximum score for reaching a waypoint is 15 points, and final points are calculated based on the distance using the following formula: round(15 −(3 ·d)) Waypoint XX.XX (m) YY.YY (m) WA 21.73 16.18 WB 25.38 -03.84 WC 19.00 03.67 WF 10.61 19.07 WG 05.54 10.63 WH 16.58 14.56 WL 22.98 07.43 WQ 12.75 -03.12 Table 2: Waypoint’s positions. [24] 10 Terrain detection algorithm for the European Rover Challenge 3 Theoretical framework 3.1 Computer Vision Computer vision is a multidisciplinary field that involves a range of scientific disciplines, including artificial intelligence, electrical engineering, and computer science. In addition to these fields, computer vision also integrates elements of optics, image processing, and machine learning to enable systems to interpret and analyze visual data. It is a rapidly evolving field that has applications in a wide variety of industries, including robotics, healthcare, manufacturing, and transportation. Computer vision appeared in the 1960s at universities pioneering AI. It was not until the 1970s that the foundations were laid for computer vision algorithms that are used today. The next decade was based on improving mathematical analysis. In 1990, a better understanding of camera calibration was achieved by studying 3D projective reconstructions. Finally, at the end of this decade there was a significant shift in the field of computer vision with increased interaction between the fields of computer graphics and computer vision. This included image-based rendering, image transformation, view interpolation, panoramic image stitching, and early representation of light fields[25] In recent years computer vision systems have become increasingly important, particularly in industrial automation systems where robots must grasp their distances and locations relative to the target in a manner that is close to human vision. Only stereo cameras can produce computer vision that comes close to human vision. In this study, a stereo camera system is built to measure object distances through a computer vision system. [26] 3.1.1 AR Tags An ARTag is a fiducial marker to support pose tracking in augmented reality and alignment, they are mainly used to ease the appearance of virtual objects within the real world. The relative camera’s position and orientation to markers can be computed with video tracking. This capability would be used in our study in order to obtain the global position of the robot. ARTag marker uses a coding theory that consists of a edge linking method, that provides a low false positive and inter-marker confusion rate with small marker size. They are formed by bitonal planar patterns that contains a unique ID number. Nowadays, others fiducial markers are becoming more popular such as the Aruco Tags. [27] 11 Terrain detection algorithm for the European Rover Challenge Figure 5: AR Tag 1. [24] 3.1.2 OpenCV OpenCV (Open Source Computer Vision) [28] is a free and open-source library of computer vision and machine learning algorithms. It was developed by Intel in 1999 and has since become one of the most widely used and well-respected computer vision libraries in the world. OpenCV is written in C++ and has interfaces for several programming languages, including Python, Java, and C#. It is designed to be highly modular and efficient, with a focus on real-time applications. One of the main strengths of OpenCV is its ability to process and analyze images and video streams in real time. It has a wide range of functions for image and video manipulation, such as filtering, thresholding, and edge detection. It also has functions for object detection, face recognition, and motion analysis. In addition to its image and video processing capabilities, OpenCV also has machine learning algorithms for tasks such as object classification, clustering, and regression. It has a robust set of tools for training and evaluating machine learning models, including support for deep learning frameworks such as TensorFlow and PyTorch. 3.1.3 Detection of markers To detect a marker in an image [29], the algorithm first uses edge detection to identify the black and white checkerboard pattern on the tag. It then uses thresholding to create a binary image, where the white squares on the tag are represented as white pixels and the black squares are represented as black pixels. Next, the algorithm uses contour detection to identify the individual squares on the tag and determine their positions relative to one another. It then uses this information to decode the unique ID encoded in the tag. This ID is represented as a series of black and white squares arranged in 12 Terrain detection algorithm for the European Rover Challenge 4.2.4 Cv Bridge Cv Bridge [34] is a ROS library that provides an interface between ROS and OpenCV. ROS uses image in its own format sensor msg/image, so this library converts this format to be used in OpenCV. Figure 10: Diagram of the function of Cv Bridge [34] 4.2.5 Numpy Numpy [35] is python library that provides a multidimensional array object, and various routines for fast operation of arrays. Nowadays, Numpy is the fundamental package for scientific computing in python. 4.3 Node and topics definition This section presents the definition of different topics related to ROS. -ROS node: A ROS node is an executable file within a ROS system that performs a specific function. It communicates with other nodes through publishing and subscribing to ROS topics, and can also provide or use ROS services. -ROS package: A ROS package is a collection of files that provide a specific set of functionalities. It can contain nodes, as well as other resources such as libraries, configuration files, and data files. -ROS message: A ROS message is a data structure used to send data between nodes. It defines the fields of the data and their types, and is used to transmit the data over a ROS topic. -ROS topic: A ROS topic is a named channel over which nodes can publish and subscribe to streams of data. When a node publishes data to a topic, all subscribed nodes will receive the data. The nodes used and the topics published and subscribed are explained in detail below. -image left: collects the image of the left webcam and publishes it as /camera/left/image raw. -image right: collects the image of the right webcam and publishes it with the name: /camera/right/image raw 19 Terrain detection algorithm for the European Rover Challenge -cam pos left: subscribe to the rostopic /camera/left/image raw and using a custom dictionary computes the position of the left webcam position in reference to the detected camera. This node publish the position in /left/pos webCam -cam pos right: this node follows an analogue method than the previous one but in the right webcam. -ang robot: collect the angle of the azimut angle compared with the angle when the robot switches on. This value is published in the rostopic ang -pos comp: this node receive the position, if exist, of the cameras and using a change of axis compute the centre of the robot knowing the global position of the landmarks and the relative relative to the robot. Finally, the global position of the robot is published. Figure 11: Diagram of nodes and rostopics. Own image 20 Terrain detection algorithm for the European Rover Challenge 5 Robot definition The GRover [36], as the GRASS group’s rover for the ERC 2022 competition is known, will be the platform on which the algorithm developed in this project will be applied and the different tests will be carried out. Its 3D model will also be used for the preliminary simulations. In the following, its different modules will be described. Figure 12: CAD model of the ERC22 robot. Own image 5.1 Structure The structure is made out of standardized aluminium profiles due to its stiffness, lightness and simplicity. The aluminium profiles allow a modular configuration of the inner modules such as battery and electronics. Moreover, machined carbon steel will be used as a joint with the suspension system. Figure 13: Structure of the robot next to a wheel. [36] 21 Terrain detection algorithm for the European Rover Challenge 5.2 Traction and suspension The rover uses a rocker-bogie configuration greatly improving the balancing and the behaviour in difficult terrains. The wheels are made using 3D printing, the rigid rims have been printed using rigid material while the tyre is flexible to improve ground adhesion. The pattern and structure are based on rovers such as the Perseverance. On the other hand, the traction system is powered by four DC motors and four steppers, which enable the steering of the driving wheels. The middle wheels are passive which reduce weight, cost and complexity whilst provides balance. Figure 14: Traction systems and wheels . [36] 5.3 Battery modules The battery of the rover is divided in two battery packs, the biggest one is designed for operating the main mechanical systems such as the robotic arm and driving wheels. This battery pack has been prepared to last each task and provide the power needed to move and work. On the other hand, the second battery module is the electronic power supply to ensure the correct functioning of the mobile electronics. It must be noted that the emergency button only disconnects the main battery pack in order to ensure the safety of the environment. However, the electronics is still connected to collect data. Figure 15: Battery module. [36] 22 Terrain detection algorithm for the European Rover Challenge 5.4 Robotic Arm The robotic arm presents five degrees of freedom and its structure is formed mainly by 3D printed and machined aluminium parts. The end effector is a modular gripper that can be changed depending the function that the task requires. Figure 16: Robotic arm extended. [36] 5.5 Electronics modules The electronics module is located inside the rover’s structure, in a series of modular shelf structures. The control shelf, which allocates the Jetson Nano, the Raspberry Pi and other drivers. Next to it, two shelves house the robotic arm and traction system drivers. 23 Terrain detection algorithm for the European Rover Challenge 5.6 Software The software system is distributed across multiple computers and actuators. At the base, a laptop is used to control the rover and to monitor its state, as well as to visualise the image from the cameras. Onboard the rover, the main software is installed on a Raspberry pi computer, which handles the control of the robot and the arm, and a Jetson Nano, which handles the perception. All computers are connected to a local network via Wi-Fi. The software is built around ROS framework, which handles the communication between hosts and makes it invisible to the different programs. Apart from the computers, two micro controllers in the form of Arduino boards are used to control the motors and steppers. Figure 17: Software scheme. Own image 24 Terrain detection algorithm for the European Rover Challenge The rover is guided using a Xbox controller connected to the control laptop when the robot is navigating. The joystick driver reads the position of all the axes and buttons while the robot is tested using specific nodes from the laptop without using the controller. The joystick teleoperation node maps these joystick positions onto rover velocity and robot arm position commands. To do so, this module implements three different states: The transition between the three states is controlled using a mode button on the joystick. As a safety feature, when transitioning from idle to any active state, the rover waits for five seconds before entering the new state, during which the indicator light onboard the rover is active to alert people nearby. Also, if connection with the joystick or with the control base is lost, or the rover stops receiving joystick updates for any other reason, it will transition to idle state automatically. Figure 18: Scheme of joystick control. [36] The drive module maps the rover velocity commands to the angular velocity of each wheel by taking into account the geometry of the rover and the diameter of the wheels. Rosserial library is used to send the angular velocity to the Arduino in charge of wheels control. An automatic control node implements a PID control of the velocity of each wheel by using the feedback provided by the encoders. If the connection to the raspberry pi is lost or the Arduino stops receiving velocity commands for whatever reason, the motors will return to default standby mode. Figure 19: Scheme of wheels control. [36] 25 Terrain detection algorithm for the European Rover Challenge The robot arm driver converts the position provided by the joystick node to an array of angles making use of inverse kinematics. Data is sent to the controller using the rosserial library. The Arduino then moves each stepper to the corresponding position, accounting for the offsets between the angle of the articulation and the angle of the stepper, and setting limits so that the arm can not collide with itself. Figure 20: Scheme of robotic arm control. [36] 5.7 Simulation model definition Once the physical robot is defined, it will be needed to convert the robot into a model to simulate the algorithm in ROS-Gazebo environment. The simplified model has removed some joints and relations such us the rocker-bogie differential drive because it is not necessary to test the code. Moreover, the number of components have been reduced in order to reduce the computational power of the simulations. The solids of the model are: Number Code Description 1 base link Structure with single legs 2 left leg double Left double wheel leg 3 right leg double Right double wheel leg 4 LF support Left front wheel support 5 LB support Left backward wheel support 6 RF support Right front wheel support 7 RB support Right backward wheel support 8 LF wheel Left front wheel 9 LM wheel Left middle wheel 10 LB wheel Left backward wheel 11 RF wheel Right front wheel 12 RM wheel Right middle wheel 13 RB wheel Right backward wheel Table 3: Solids of simplified model. Own table 26 Terrain detection algorithm for the European Rover Challenge To obtain the description of the robot in the necessary language to the selected environment, a plugin [37] which converts an Autodesk Fusion 360 assembly into a simulable robot has been used to agilize the process. The remaining constrains are presented in Table 4. It must be noted that all joints are revolute joints, they can rotate about the selected axis. The constrains starting with S have a stepper to control the angle, those starting with W have a motor and the others are free. ID Description Parent Child S LF Left front Stepper 1 4 S LB Left backward Stepper 2 5 S RF Right front Stepper 1 6 S RB Right backward Stepper 3 7 W LF Left front Wheel 4 8 W LM Left middle Wheel 3 9 W LB Left backward Wheel 5 10 W RF Right front Wheel 6 11 W RM Right middle Wheel 3 12 W RB Right backward Wheel 7 13 L DS Left double to single leg 1 2 R DS Right double to single leg 1 3 Table 4: Joints of the simulation model. Own table After removing the not necessary components and joints, the resultant model is presented in the Figure 21. The main differences compared to Figure 12 are the lack of robotic arm, differential rocker-bogie and the hollow body, things that are not necessary for the simulations. Figure 21: Simplified model of the ERC2022. Own image 27 Terrain detection algorithm for the European Rover Challenge After running the plugin in Autodesk Fusion 360, the robot definition is obtained to be used in rviz and gazebo. The model converted to URDF is presented in subsection A.7 and the model in rviz results as can be seen in Figure 22. For the simulation, cameras have been implemented in the model afterwards, these are placed at the front corners of the structure at 45 degrees to the structure. Figure 22: ERC22 model represented in rviz. Own image 28 Terrain detection algorithm for the European Rover Challenge 12 pos.angle =yaw 13 pub =rospy.Publisher('pos',Position, queue_size=100) 14 pub.publish(pos) The three necessary axes conversion are presented graphically with the equations below. Where the subscript rindicates relative to the robot, crelative to the camera, and grelative to global. Moreover, the 45 degrees angle is formed by the cameras and the horizontal of the robot, and the angle θis the angle formed between the axes of the robot and the global or terrain axes. Figure 25: Camera axes conversion to robot axes with formulas left side. Own image Figure 26: Camera axes conversion to robot axes with formulas right side. Own image 35 Terrain detection algorithm for the European Rover Challenge Figure 27: Robot axes conversion to terrain axes using the yaw angle (θ). Own image This code is presented in subsection A.4. Then, a visual map is presented to better comprehend the main loop: Figure 28: Diagram of the position package. Own image 36 Terrain detection algorithm for the European Rover Challenge 7 Results In this section, the different tests and simulations carried out during the development of the project and their results are presented. The different errors found and the changes and improvements applied to achieve their correct operation are also shown. 7.1 Camera calibration The first step in testing the developed algorithm is to calibrate the cameras that will be used on the robot in the ERC. As both cameras are Logitech C270, it will be considered that the calibration and distortion matrices are the same, although it will be tested this assumption below. The calibration process consists of taking several photographs of the 9x7-square ”chessboard” with 2.4 cm squares, as shown in Figure 29. Figure 29: Chessboard template and sample images. Own image Subsequently, the calibration code is executed and straight lines are drawn on the different images to connect the different points, as can be seen in Figure 30. 37 Terrain detection algorithm for the European Rover Challenge Figure 30: Chessboard template and sample images with the calibration pattern. Own image Using the differences between the straight lines drawn and the ones distorted by the camera, the calibration and distortion matrices presented in Tables 6 and 7 are calculated. 1.086·1030.000 3.195·102 0.000 1.091·1032.395·102 0.000 0.000 1.000 Table 6: Calibration matrix of the camera. Own table 0.1013 0.0279 0.0009 -0.0019 -0.7017 Table 7: Distortion coefficients of the camera. Own table 7.2 Custom dictionary generator Once the camera is calibrated, the next step is to display the markers that will be used as reference points during the Navigation Task. These are AR Tags with IDs 1 to 15, although number 14 is not used. To verify that the markers were the same and to obtain them in higher quality for detecting them in simulations, the code in subsection A.6 was used. This code, based on a custom dictionary presented in matrix form of zeros and ones as explained in Section 3.1.4, generates the markers. The images obtained after executing the code are shown in Figure 31. In this image it can be seen that all the markers are exactly the same as those presented in the Appendix B.1, with the 38 Terrain detection algorithm for the European Rover Challenge only difference being that the generated markers have a border formed by a single frame and the ones used by the organization have a double border. This difference is solved by changing the detection parameters, which will be explained below. Figure 31: Generated AR Tag used by the organisation. Own image 7.3 Marker detection After generating the markers and verifying that they are exactly the same as those used, the next step is to verify that the image dictionary functions correctly. To demonstrate this, the different markers will be tried to be detected. When a marker is detected, a frame will be superimposed on the camera image, indicating the corners of the marker, the center with a trio of axes, and the id. The resulting image of marker detection is presented below, it must be noted that in multiple detections a few of markers are not drawn: Figure 32: Detection of custom AR Tag. Own image During the development of the test for detecting different markers, an error was discovered. Specifically, every marker was being interpreted as ID-1. The OpenCV functions detect a marker when a 39 Terrain detection algorithm for the European Rover Challenge certain percentage of the marker coincides, even if part of the image is not visible. However, in this case, the custom markers had an extra border frame which caused them to be wrongly detected due to the outer ring increasing the similarity percentage and the inner drawings also having similarities. When the ID’s are similar, the changes are minimal. The parameter that determines the correct percentage to confirm a detection is the errorCorrectionRate. This problem was finally solved by using a 20% correction instead of the default 60%. 7.4 Model description movement Once it has been proven that the codes work in a real environment, the next step is to test it in a simulation environment because testing with a robot of such dimensions greatly complicates the iteration process. The first simulation consists of testing the robot in an obstacle-free environment and checking that the different actuators such as the steppers and motors can be controlled from the ROS environment and see the movement in the simulation. The first step in order to perform the simulation of the model is to define the properties of the model in Gazebo, the simulation environment. Solids are defined as follows: 1<gazebo reference="elementName"> 2<material>${body_color}</material> 3<mu1>staticFrictionCoefficient</mu1> 4<mu2>dynamicFrictionCoefficient</mu2> 5<selfCollide>true</selfCollide> 6</gazebo> The code that defines the robot in the simulation is presented in subsection A.7. It can be observed that the coefficients in the solids that represent the wheels have completely exaggerated and physically meaningless values. This is because in simulations with many controllers, the actual values of friction do not produce enough force to move the model. The next step in order to test the model is to define the controllers as follows: 1modelName: 2# Publish all joint states ----------------------------------- 3joint_state_controller: 4type: joint_state_controller/JointStateController 5publish_rate: 50 6 7# Position Controllers -------------------------------------- 8jointName_position_controller: 9type: effort_controllers/JointPositionController 10 joint: jointName 40 Terrain detection algorithm for the European Rover Challenge 11 pid: {p:proportional,i:integrative,d:derivative} 12 13 # Velocity Controllers -------------------------------------- 14 jointName_position_controller: 15 type: effort_controllers/JointVelocityController 16 joint: jointName 17 pid: {p:proportional,i:integrative,d:derivative} Position controllers are related to the steppers and velocity controllers are related to the traction motors. The definition of the model’s controllers is presented in subsection A.9. Once the model has been defined in the simulation environment and the controllers, the next step is to execute the simulations and load the controllers in order to use them with the codes presented in subsection A.8 and subsection A.10 respectively. Due to the use of ROS Noetic during the development of this simulation, several problems have been found with the version because most mobile robot simulations are developed in previous versions. This will be discussed in depth in the section on future improvements. The first problem during development was that the model collapsed on the origin (Figure 33) because the default values of the PID controllers were: (100, 0.01, 10) and the model became unstable. Therefore, the next step was to tune the PIDs. Since the six controllers are the same, it has been considered that by adjusting one, it can be replicated in the other similar controllers. The tool used for this has been rqt gui which allows you to easily publish messages and adjust the PID parameters while seeing the response in real-time Figure 34. Finally, the values that best adapted the response to changing values for position controllers are: (5.0, 0.1, 0.2) while for velocity controllers they are: (1.0, 0.0, 0.0). Figure 33: Model collapsing to origin. Own image 41 Terrain detection algorithm for the European Rover Challenge Figure 34: PID tunning using the real-time configuration. Own image It is possible to test the different controllers once the joints are stable and the model does not collapse. A photograph of the simulation with the steppers with zero turn and the motors braked is presented below: Figure 35: Simulation with brakes and rotatory wheels steady. Own image The rqt gui tool is then used to position the four rotary wheels in the rotation position in order to verify the operation of the steppers. Subsequently, the same speed is given to the six motors to see the straight movement of the robot. Finally, the previous two tests are carried out simultaneously changing the direction of turn on one side to test the rotation. The results of the tests are presented below: 42 Terrain detection algorithm for the European Rover Challenge Figure 36: Simulation of the stepper with the rqt command. Own image Figure 37: Simulation of rectilineal movement with the rqt command. Own image 43 Terrain detection algorithm for the European Rover Challenge Figure 38: Simulation of rotation with the rqt command. Own image 7.5 AR Tag implementation With the tested movement of the model, the different markers that will be used during the Navigation Task must be implemented in the simulation. To do this, the images presented in subsection B.1 will be used to model the different markers on the ground. The program used to prepare all the markers has been Blender (Figure 39) as it allows exporting the objects with the textures and thus visualising them in Gazebo. Figure 39: Model of the LandMark 1. Own image 44 Terrain detection algorithm for the European Rover Challenge -15 -10 -5 0 5 10 15 20 25 30 Y (m) -5 0 5 10 15 20 25 30 35 X (m) 1 2 3 4 5 6 7 8 9 10 11 12 13 15 A F G H Waypoint A calculated points Waypoint F calculated points Waypoint G calculated points Waypoint H calculated points Landmark Origin Waypoints Figure 46: Visual map of the terrain. Own image Once the positions are displayed, the distance of each calculated position to the waypoint and the causes of this error shall be analysed for each waypoint. 51 Terrain detection algorithm for the European Rover Challenge 7.9.1 Waypoint A A representation of the calculated points with the different angles is presented in Figure 47 where the triangles of the positions point in the direction in which the robot was arranged on the ground. The nearby landmarks that the robot has recognised in the positions have also been added. 8 10 12 14 16 18 Y (m) 18 20 22 24 26 28 X (m) 5 6 8 10 12 0 rad /4 rad /2 rad 3 /4 rad rad 5 /4 rad 3 /2 rad 7 /4 rad Waypoint A Landmarks Figure 47: Waypoint A calculated position with nearby landmarks. Own image Once the calculated points and nearby landmarks have been displayed, the absolute distance, the relative error on both axes and the total points that would be obtained are presented in Table 10. θd (m) Error X (%) Error Y (%) Points 0 0.46 1.24 2.34 14 π/41.46 6.71 0.12 11 π/20.54 1.97 2.03 13 3π/41.62 0.32 10.04 10 π1.53 5.10 6.55 10 5π/40.53 2.43 0.43 13 3π/20.31 0.78 1.60 14 7π/41.72 0.46 10.63 10 Table 10: Distance, relative error in both axes and points of Waypoint A. Own table This process will be followed for the rest of the waypoints. 52 Terrain detection algorithm for the European Rover Challenge 7.9.2 Waypoint F A representation of the calculated points with the different angles is presented in Figure 48. 10 12 14 16 18 20 22 24 26 Y (m) 4 6 8 10 12 14 16 18 20 22 X (m) 2 5 8 11 12 13 15 0 rad /4 rad /2 rad 3 /4 rad rad 5 /4 rad 3 /2 rad 7 /4 rad Waypoint F Landmarks Figure 48: Waypoint F calculated position with nearby landmarks. Own image Once the calculated points and nearby landmarks have been displayed, the absolute distance, the relative error on both axes and the total points that would be obtained are presented in Table 11. θd (m) Error X (%) Error Y (%) Points 0 1.92 13.10 6.97 9 π/41.63 15.26 1.05 10 π/21.88 14.79 5.40 9 3π/41.87 0.00 9.80 9 π1.11 0.57 5.82 12 5π/40.44 4.14 0.00 14 3π/21.90 11.88 7.50 9 7π/41.51 14.14 0.84 10 Table 11: Distance, relative error in both axes and points of Waypoint F. Own table 53 Terrain detection algorithm for the European Rover Challenge 7.9.3 Waypoint G A representation of the calculated points with the different angles is presented in Figure 49. 8 10 12 14 16 18 20 Y (m) 2 4 6 8 10 12 X (m) 2 13 15 0 rad /4 rad /2 rad 3 /4 rad rad 5 /4 rad 3 /2 rad 7 /4 rad Waypoint G Landmarks Figure 49: Waypoint G calculated position with nearby landmarks. Own image Once the calculated points and nearby landmarks have been displayed, the absolute distance, the relative error on both axes and the total points that would be obtained are presented in Table 12. θd (m) Error X (%) Error Y (%) Points 0 1.64 23.46 9.41 10 π/40.85 15.34 0.09 12 π/21.76 23.28 11.29 10 3π/41.02 1.26 9.59 12 π1.28 15.34 9.03 11 5π/41.93 2.16 18.15 9 3π/21.20 16.61 7.24 11 7π/42.29 11.19 20.69 8 Table 12: Distance, relative error in both axes and points of Waypoint G. Own table 54 Terrain detection algorithm for the European Rover Challenge 7.9.4 Waypoint H A representation of the calculated points with the different angles is presented in Figure 50. 8 10 12 14 16 18 20 Y (m) 10 12 14 16 18 20 22 24 X (m) 2 5 8 12 13 0 rad /4 rad /2 rad 3 /4 rad rad 5 /4 rad 3 /2 rad 7 /4 rad Waypoint H Landmarks Figure 50: Waypoint H calculated position with nearby landmarks. Own image Once the calculated points and nearby landmarks have been displayed, the absolute distance, the relative error on both axes and the total points that would be obtained are presented in Table 13. θd (m) Error X (%) Error Y (%) Points 0 0.56 2.71 2.26 13 π/41.36 8.20 0.07 11 π/21.86 6.33 10.51 9 3π/41.33 0.18 9.13 11 π1.46 6.69 6.59 11 5π/41.69 10.13 1.17 10 3π/21.19 2.77 7.55 11 7π/40.95 5.73 0.07 12 Table 13: Distance, relative error in both axes and points of Waypoint H. Own table 55 Terrain detection algorithm for the European Rover Challenge 7.9.5 Final judging To draw conclusions from the various scores obtained, a summary of the previously displayed information will be presented. The distribution of distance and points is shown in Figure 51 and Figure 52 respectively. Moreover, the mean distance and points for each waypoint in presented in Table 14 0/4 /2 3 /4 5 /4 3 /2 7 /4 (rad) 0 0.5 1 1.5 2 2.5 Distance (m) Waypoint A Waypoint F Waypoint G Waypoint H Figure 51: Distance distribution in function of yaw angle. Own image 0/4 /2 3 /4 5 /4 3 /2 7 /4 (rad) 8 9 10 11 12 13 14 Points Waypoint A Waypoint F Waypoint G Waypoint H Figure 52: Point distribution in function of yaw angle. Own image WA WF WG WH Distance (m) Points Distance (m) Points Distance (m) Points Distance (m) Points 1.02 11.875 1.53 10.250 1.50 10.375 1.30 11.000 Table 14: Mean values of distance and points for each waypoint. Own table As can be seen, in the previous table and in the maps presented for each waypoint (Figure 47, Figure 48, Figure 49 and Figure 50), the positions that show the best results are those that have various landmarks around the waypoint so that both cameras have detections, like Waypoint A, or have a nearby landmark like Waypoint H. 56 Terrain detection algorithm for the European Rover Challenge Errors can be introduced for various reasons, the first to consider is the previously mentioned camera error that is dragged, and the farther the landmark is, the greater the error becomes. Secondly, when a position is calculated using only detections from one of the two cameras as it can be seen in Figure 53, there is no data to compare with to mitigate the error introduced by the camera. Despite these issues, the final score of the waypoint test would be 43.5 out of 60 possible points, a very correct score compared to the best teams in previous competitions. Figure 53: Robot at πrad at Waypoint F. Own image Figure 54: Left camera of the position described in Figure 53. Own image 57 Terrain detection algorithm for the European Rover Challenge Figure 55: Right camera of the position described in Figure 53. Own image 7.10 European Rover Challenge 2021 In September, specifically on the 9th to 11th, the UPC Space Program association participated in the European Rover Challenge Figure 56), this being their second time participating. This edition was very marked by the weather due to the fact that it rained continuously for the three days of the competition, which greatly complicated the navigation of the robots. Figure 56: UPC Space Program in ERC22. Own image In this edition, 4 out of the 5 tests of the competition were carried out. This is an improvement compared to the 2021 edition, in which we were only able to present due to various technical and 58 Terrain detection algorithm for the European Rover Challenge design errors of the robot. The task in which we were unable to participate this year was the Probing task due to a problem with wheel control. Once this problem was solved, the maintenance test was carried out correctly, although the inverse kinematics did not work. It is worth noting that due to the rain, the navigation test, which is the subject of this project, was rescheduled to the morning instead of the afternoon as planned. The programming team’s decision was to spend the whole night testing the positioning algorithm, as can be seen in Figure 57. In the tests, everything seemed to work correctly. Figure 57: Testing the location algorithm at night. Own image During the test, the cameras were connected upside down and therefore, at the start, the position calculation algorithm did not work correctly. Changes were made to the code on site to change the position of the images, but when it was made to work, there was not enough time to complete the task correctly. The Science Task was successfully carried out and we were able to navigate to two positions, but an electronic component malfunctioned and did not allow us to continue with the development of the test. Later, the organization congratulated us on the presentation made about the project and the diffusion that the association achieved by doing interviews in various media such as InfoK [38] and appearing in newspapers [39]. Finally, the UPC Space Program achieved ninth place (Figure 58) out of 19 teams in the final and 64 participating teams. We hope to be able to participate in the next edition and achieve a better position in the final ranking. 59 Terrain detection algorithm for the European Rover Challenge Figure 58: Qualification of the UPC Space Program in ERC2022. Own image 60 Terrain detection algorithm for the European Rover Challenge [18] Trinity College Int’L Firefighting Home Robot Contest - Home.URL:https://trinityrobotcontest. org/. [19] El Robot-Sumo: la versi´ on rob´ otica de los campeonatos de sumo lleva realiz´ andose desde 1989.URL:https://www.20minutos.es/tecnologia/moviles-dispositivos/el-robot- sumola- versionrobotica- delos- campeonatosde- sumolleva- realizandosedesde-1989-5045144/. [20] RoboCup Federation official website.URL:https://www.robocup.org/. [21] BattleBots.URL:https://battlebots.com/. [22] About the ERC — European Rover Challenge 2021.URL:https://roverchallenge.eu/ en/about-the-erc/. [23] ERC 2022: Introducing the winners of the space competition! –.URL:https://roverchallenge. eu/en/erc-2022-introducing-the-winners-of-the-space-competition/. [24] ERC 2022 Rules OnSite. [25] Visi´ on por computador – HiSoUR Arte Cultura Historia.URL:https://www.hisour.com/ es/computer-vision-42799/. [26] Emre Dandil and Kerim Kursat Cevik. “Computer Vision Based Distance Measurement System using Stereo Camera View”. In: 3rd International Symposium on Multidisciplinary Studies and Innovative Technologies, ISMSIT 2019 - Proceedings (Oct. 2019). DOI:10.1109/ ISMSIT.2019.8932817. [27] Mark Fiala. “ARTag, a fiducial marker system using digital techniques”. In: Proceedings - 2005 IEEE Computer Society Conference on Computer Vision and Pattern Recognition, CVPR 2005 II (2005), pp. 590–596. DOI:10.1109/CVPR.2005.74. [28] OpenCV: Camera Calibration.URL:https://docs.opencv.org/4.x/dc/dbb/tutorial_ py_calibration.html. [29] S. Garrido-Jurado et al. “Automatic generation and detection of highly reliable fiducial markers under occlusion”. In: Pattern Recognition 47 (6 June 2014), pp. 2280–2292. ISSN: 00313203. DOI:10.1016/j.patcog.2014.01.005. [30] Ely Repiso and Jaume Figueras. Robot’s Odometry. Universitat Polit` ecnica de Catalunya, pp. 1–9. [31] rospy - ROS Wiki.URL:http://wiki.ros.org/rospy. [32] roscpp - ROS Wiki.URL:http://wiki.ros.org/roscpp. [33] About - OpenCV.URL:https://opencv.org/about/. [34] cv bridge - ROS Wiki.URL:http://wiki.ros.org/cv_bridge. [35] What is NumPy? URL:https://numpy.org/devdocs/user/whatisnumpy.html. [36] UPC Space Program. European Rover Challenge 2022: Final Design Report. 2022, pp. 1– 37. 67 Terrain detection algorithm for the European Rover Challenge [37] Toshinori Kitamura. Fusion2URDF.https://github.com/syuntoku14/fusion2urdf. 2020. [38] Estudiants de la UPC han creat un robot marci` a! - InfoK - SX3.URL:https://www.ccma. cat/tv3/sx3/estudiants-de-lupc-han-creat-un-robot-marcia/video/6174728/. [39] Un r` over espacial de l’Eseiaat competir` a a l’European Rover Challenge - Diari de Terrassa. URL:https://www.diarideterrassa.com/terrassa/2022/09/07/equip-eseiaat-upc- concurs-europeu-rover-espacials-mart/. [40] Factor de emisi´ on de la energ´ ıa el´ ectrica: el mix el´ ectrico. Cambio clim´ atico.URL:https: //canviclimatic.gencat.cat/es/actua/factors_demissio_associats_a_lenergia/. [41] ICAO Carbon Emissions Calculator.URL:https : / / www . icao . int / environmental - protection/Carbonoffset/Pages/default.aspx. [42] NISSAN QASHQAI 1.3 103 KW (140 CV) MHEV 12V 4X2 N-CONNECTA (2021) - Ficha T´ ecnica - - Autopista.es.URL:https://www.autopista.es/coches/nissan/qashqai/ qashqai-13-103-kw-140-cv-mhev-12v-4x2-n-connecta/. 68 Terrain detection algorithm for the European Rover Challenge A Code A.1 Camera publishers 1#!/usr/bin/env python3 2 3import rospy 4from sensor_msgs.msg import Image 5from cv_bridge import CvBridge, CvBridgeError 6import cv2 7 8cap =cv2.VideoCapture(1) 9print(cap.isOpened()) 10 bridge =CvBridge() 11 12 def talker(): 13 pub =rospy.Publisher('/camera/left/image_raw', Image, queue_size = 1) 14 rospy.init_node('image_left', anonymous =False) 15 rate =rospy.Rate(10) 16 while not rospy.is_shutdown(): 17 ret, frame =cap.read() 18 if not ret: 19 break 20 21 msg =bridge.cv2_to_imgmsg(frame, "bgr8") 22 pub.publish(msg) 23 24 if cv2.waitKey(1)& 0xFF == ord('q'): 25 break 26 27 if rospy.is_shutdown(): 28 cap.release() 29 30 if __name__ == '__main__': 31 try: 32 talker() 33 except rospy.ROSInterruptException: 34 pass Listing 1: Left camera node Python code 69 Terrain detection algorithm for the European Rover Challenge 1#!/usr/bin/env python3 2 3import rospy 4from sensor_msgs.msg import Image 5from cv_bridge import CvBridge, CvBridgeError 6import cv2 7 8cap =cv2.VideoCapture(0) 9print(cap.isOpened()) 10 bridge =CvBridge() 11 12 def talker(): 13 pub =rospy.Publisher('/camera/right/image_raw', Image, queue_size = 1) 14 rospy.init_node('image_right', anonymous =False) 15 rate =rospy.Rate(10) 16 while not rospy.is_shutdown(): 17 ret, frame =cap.read() 18 if not ret: 19 break 20 21 msg =bridge.cv2_to_imgmsg(frame, "bgr8") 22 pub.publish(msg) 23 24 if cv2.waitKey(1)& 0xFF == ord('q'): 25 break 26 27 if rospy.is_shutdown(): 28 cap.release() 29 30 if __name__ == '__main__': 31 try: 32 talker() 33 except rospy.ROSInterruptException: 34 pass Listing 2: Right camera node Python code 70 Terrain detection algorithm for the European Rover Challenge A.2 Custom dictionary 1import numpy as np 2import cv2 3 4def AR_landmark(): 5# define an empty custom dictionary with 6aruco_dict =cv2.aruco.custom_dictionary(0,5,1) 7# add empty bytesList array to fill with 3 markers later 8aruco_dict.bytesList =np.empty(shape =(15,4,4), dtype =np.uint8) 9 10 # Marker 1 11 mybits =np.array([[1,1,0,1,1], 12 [1,1,0,1,1], 13 [1,0,1,0,1], 14 [0,0,1,1,0], 15 [1,1,1,0,1]], dtype =np.uint8) 16 aruco_dict.bytesList[0]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 17 # Marker 2 18 mybits =np.array([[1,1,0,1,1], 19 [1,1,0,1,1], 20 [1,0,1,0,1], 21 [1,0,1,1,0], 22 [1,0,1,1,0]], dtype =np.uint8) 23 aruco_dict.bytesList[1]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 24 # Marker 3 25 mybits =np.array([[1,1,0,1,1], 26 [1,1,0,1,1], 27 [1,0,1,0,1], 28 [0,1,1,1,1], 29 [1,0,1,0,0]], dtype =np.uint8) 30 aruco_dict.bytesList[2]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 31 # Marker 4 32 mybits =np.array([[1,1,0,1,1], 33 [1,1,0,1,1], 34 [1,0,1,0,1], 35 [0,1,1,1,0], 36 [0,1,1,1,0]], dtype =np.uint8) 37 aruco_dict.bytesList[3]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 38 # Marker 5 39 mybits =np.array([[1,1,0,1,1], 71 Terrain detection algorithm for the European Rover Challenge 40 [1,1,0,1,1], 41 [1,0,1,0,1], 42 [1,0,1,1,1], 43 [0,1,1,0,0]], dtype =np.uint8) 44 aruco_dict.bytesList[4]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 45 # Marker 6 46 mybits =np.array([[1,1,0,1,1], 47 [1,1,0,1,1], 48 [1,0,1,0,1], 49 [0,0,1,1,1], 50 [0,0,1,1,1]], dtype =np.uint8) 51 aruco_dict.bytesList[5]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 52 # Marker 7 53 mybits =np.array([[1,1,0,1,1], 54 [1,1,0,1,1], 55 [1,0,1,0,1], 56 [1,1,1,1,0], 57 [0,0,1,0,1]], dtype =np.uint8) 58 aruco_dict.bytesList[6]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 59 # Marker 8 60 mybits =np.array([[1,1,0,1,1], 61 [1,1,0,1,1], 62 [1,0,1,0,1], 63 [0,0,1,0,1], 64 [1,1,1,1,0]], dtype =np.uint8) 65 aruco_dict.bytesList[7]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 66 # Marker 9 67 mybits =np.array([[1,1,0,1,1], 68 [1,1,0,1,1], 69 [1,0,1,0,1], 70 [1,1,1,0,0], 71 [1,1,1,0,0]], dtype =np.uint8) 72 aruco_dict.bytesList[8]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 73 # Marker 10 74 mybits =np.array([[1,1,0,1,1], 75 [1,1,0,1,1], 76 [1,0,1,0,1], 77 [0,1,1,0,0], 78 [1,0,1,1,1]], dtype =np.uint8) 79 aruco_dict.bytesList[9]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 80 # Marker 11 72 Terrain detection algorithm for the European Rover Challenge 81 mybits =np.array([[1,1,0,1,1], 82 [1,1,0,1,1], 83 [1,0,1,0,1], 84 [1,0,1,0,1], 85 [1,0,1,0,1]], dtype =np.uint8) 86 aruco_dict.bytesList[10]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 87 # Marker 12 88 mybits =np.array([[1,1,0,1,1], 89 [1,1,0,1,1], 90 [1,0,1,0,1], 91 [1,0,1,0,0], 92 [0,1,1,1,1]], dtype =np.uint8) 93 aruco_dict.bytesList[11]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 94 # Marker 13 95 mybits =np.array([[1,1,0,1,1], 96 [1,1,0,1,1], 97 [1,0,1,0,1], 98 [0,1,1,0,1], 99 [0,1,1,0,1]], dtype =np.uint8) 100 aruco_dict.bytesList[12]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 101 # Marker 14 102 mybits =np.array([[1,1,0,1,1], 103 [1,1,0,1,1], 104 [1,0,1,0,1], 105 [1,1,1,0,1], 106 [0,0,1,1,0]], dtype =np.uint8) 107 aruco_dict.bytesList[13]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 108 # Marker 15 109 mybits =np.array([[1,1,0,1,1], 110 [1,1,0,1,1], 111 [1,0,1,0,1], 112 [0,0,1,0,0], 113 [0,0,1,0,0]], dtype =np.uint8) 114 aruco_dict.bytesList[14]=cv2.aruco.Dictionary_getByteListFromBits(mybits) 115 116 return (aruco_dict) 117 Listing 3: Custom dictionary for OpenCV 73 Terrain detection algorithm for the European Rover Challenge A.3 Marker detection 1#!/usr/bin/env python3 2 3import sys 4import numpy as np 5import rospy 6import cv2 7from sensor_msgs.msg import Image 8from cv_bridge import CvBridge, CvBridgeError 9from geometry_msgs.msg import PoseStamped 10 import tf 11 from customDict import AR_landmark 12 from navigation.msg import Position 13 import math 14 15 16 17 bridge =CvBridge() 18 19 def listener(): 20 rospy.init_node('cam_pos_left', anonymous =False) 21 rospy.Subscriber("ERC22_URDF/left_camera/image_raw",Image, callback) 22 23 24 rospy.spin() 25 cv2.destroyAllWindows() 26 27 28 def callback(data): 29 cv_image =bridge.imgmsg_to_cv2(data) 30 pose_estimation(cv_image) 31 32 def pose_estimation(frame): 33 34 #pub = rospy.Publisher('/left/pos_webCam',Position, queue_size=100) 35 pub =rospy.Publisher('/left/pos_webCam',Position, queue_size=100) 36 pub2 =rospy.Publisher('/left/ARTag_det', Image, queue_size = 1) 37 38 gray =cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) 39 cv2.aruco_dict =AR_landmark() 74 Terrain detection algorithm for the European Rover Challenge 40 parameters =cv2.aruco.DetectorParameters_create() 41 parameters.markerBorderBits = 2 42 parameters.errorCorrectionRate = 0.2 43 matrix_coefficients =np.load("./calibration_matrix.npy") 44 distortion_coefficients =np.load("./distortion_coefficients.npy") 45 46 corners, ids, rejected_img_points =cv2.aruco.detectMarkers(gray, cv2.aruco_dict,parameters=parameters),→ 47 48 # If markers are detected 49 if len(corners) > 0: 50 for iin range(0,len(ids)): 51 # Estimate pose of each marker and return the values rvec and tvec---(different from those of camera coefficients),→ 52 rvec, tvec, markerPoints = cv2.aruco.estimatePoseSingleMarkers(corners[i], 0.15, matrix_coefficients, distortion_coefficients) ,→ ,→ 53 # Draw a square around the markers 54 cv2.aruco.drawDetectedMarkers(frame, corners) 55 56 pose =pose_comp(rvec[0][0], tvec[0][0], ids[i]) 57 58 59 pos_cam =Position() 60 pos_cam.x=pose.pose.position.x 61 pos_cam.z=pose.pose.position.z 62 pos_cam.id =ids[i][0]+ 1 63 64 pub.publish(pos_cam) 65 66 # Draw Axis 67 cv2.drawFrameAxes(frame, matrix_coefficients, distortion_coefficients, rvec, tvec, 0.01),→ 68 69 msg =bridge.cv2_to_imgmsg(frame, "bgr8") 70 pub2.publish(msg) 71 return frame 72 return frame 73 74 def pose_comp(rvec, tvec, ids): 75 75 Terrain detection algorithm for the European Rover Challenge 76 # we need a homogeneous matrix but OpenCV only gives us a 3x3 rotation matrix 77 rotation_matrix =np.array([[0,0,0,0], 78 [0,0,0,0], 79 [0,0,0,0], 80 [0,0,0,1]], 81 dtype=float) 82 rotation_matrix[:3, :3],_=cv2.Rodrigues(rvec) 83 84 # convert the matrix to a quaternion 85 quaternion =tf.transformations.quaternion_from_matrix(rotation_matrix) 86 87 # To visualize in rviz, you can, for example, publish a PoseStamped message: 88 pose =PoseStamped() 89 pose.header.frame_id ="camera_frame" 90 pose.pose.position.x=tvec[0] 91 pose.pose.position.y=tvec[1] 92 pose.pose.position.z=tvec[2] 93 94 pose.pose.orientation.x=quaternion[0] 95 pose.pose.orientation.y=quaternion[1] 96 pose.pose.orientation.z=quaternion[2] 97 pose.pose.orientation.w=quaternion[3] 98 99 100 return(pose) 101 102 103 104 if __name__ == '__main__': 105 try: 106 listener() 107 except rospy.ROSInterruptException: 108 pass Listing 4: Pose estimation for left camera 76 Terrain detection algorithm for the European Rover Challenge A.5 Camera calibration 1''' 2Sample Usage:- 3python calibration.py --dir calibration_checkerboard/ --square_size 0.024 4''' 5 6import numpy as np 7import cv2 8import os 9import argparse 10 11 12 def calibrate(dirpath, square_size, width, height, visualize=False): 13 """ Apply camera calibration operation for images in the given directory path. """,→ 14 15 # termination criteria 16 criteria =(cv2.TERM_CRITERIA_EPS +cv2.TERM_CRITERIA_MAX_ITER, 30,0.001) 17 18 # prepare object points, like (0,0,0), (1,0,0), (2,0,0) ....,(8,6,0) 19 objp =np.zeros((height*width, 3), np.float32) 20 objp[:, :2]=np.mgrid[0:width, 0:height].T.reshape(-1,2) 21 22 objp =objp *square_size 23 24 # Arrays to store object points and image points from all the images. 25 objpoints =[] # 3d point in real world space 26 imgpoints =[] # 2d points in image plane. 27 28 images =os.listdir(dirpath) 29 for fname in images: 30 img =cv2.imread(os.path.join(dirpath, fname)) 31 print(os.path.join(dirpath,fname)) 32 gray =cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) 33 # Find the chess board corners 34 ret, corners =cv2.findChessboardCorners(gray, (width, height), None) 35 # If found, add object points, image points (after refining them) 36 print(ret) 37 if ret: 38 objpoints.append(objp) 83 Terrain detection algorithm for the European Rover Challenge 39 40 corners2 =cv2.cornerSubPix(gray, corners, (11,11), (-1,-1), criteria),→ 41 imgpoints.append(corners2) 42 43 # Draw and display the corners 44 img =cv2.drawChessboardCorners(img, (width, height), corners2, ret) 45 46 if visualize: 47 cv2.imshow('img',img) 48 cv2.waitKey(0) 49 50 ret, mtx, dist, rvecs, tvecs =cv2.calibrateCamera(objpoints, imgpoints, gray.shape[::-1], None,None),→ 51 52 return [ret, mtx, dist, rvecs, tvecs] 53 54 55 if __name__ == '__main__': 56 57 dirpath ="./Checkerboard/" 58 square_size = 0.024 59 width = 8 60 height = 6 61 visualize =False 62 63 ret, mtx, dist, rvecs, tvecs =calibrate(dirpath, square_size, visualize=visualize, width=width, height=height),→ 64 65 print(mtx) 66 print(dist) 67 68 np.save("calibration_matrix", mtx) 69 np.save("distortion_coefficients", dist) Listing 7: Camera calibration code 84 Terrain detection algorithm for the European Rover Challenge A.6 Custom tag generator 1''' 2Sample Command:- 3python generate_aruco_tags.py --id 24 --type DICT_5X5_100 -o tags/ 4''' 5 6 7import numpy as np 8import argparse 9from utils import ARUCO_DICT 10 import cv2 11 import sys 12 13 14 ap =argparse.ArgumentParser() 15 ap.add_argument("-o","--output", required=True, help="path to output folder to save ArUCo tag"),→ 16 ap.add_argument("-i","--id",type=int, required=True, help="ID of ArUCo tag to generate"),→ 17 ap.add_argument("-t","--type",type=str, default="DICT_ARUCO_ORIGINAL", help="type of ArUCo tag to generate"),→ 18 ap.add_argument("-s","--size",type=int, default=200, help="Size of the ArUCo tag"),→ 19 args =vars(ap.parse_args()) 20 21 22 # Check to see if the dictionary is supported 23 if ARUCO_DICT.get(args["type"], None)is None: 24 print(f"ArUCo tag type '{args['type']}' is not supported") 25 sys.exit(0) 26 27 arucoDict =cv2.aruco.Dictionary_get(ARUCO_DICT[args["type"]]) 28 29 print("Generating ArUCo tag of type '{}' with ID '{}'".format(args["type"], args["id"])),→ 30 tag_size =args["size"] 31 tag =np.zeros((tag_size, tag_size, 1), dtype="uint8") 32 cv2.aruco.drawMarker(arucoDict, args["id"], tag_size, tag, 1) 33 34 # Save the tag generated 85 Terrain detection algorithm for the European Rover Challenge 35 tag_name =f'{args["output"]}/{args["type"]}_id_{args["id"]}.png' 36 cv2.imwrite(tag_name, tag) 37 cv2.imshow("ArUCo Tag", tag) 38 cv2.waitKey(0) 39 cv2.destroyAllWindows() Listing 8: Custom tag generator A.7 Robot model definition 1<?xml version="1.0" ?> 2<robot name="ERC22_URDF" xmlns:xacro="http://www.ros.org/wiki/xacro"> 3 4<xacro:include filename="$(find ERC22_URDF_description)/urdf/materials.xacro" /> 5<xacro:include filename="$(find ERC22_URDF_description)/urdf/ERC22_URDF.trans" /> 6<xacro:include filename="$(find ERC22_URDF_description)/urdf/ERC22_URDF.gazebo" />,→ 7 8<link name="base_link"> 9<inertial> 10 <origin xyz="0.009312479330910419 0.0008928693179026247 0.4508429285266153" rpy="0 0 0"/>,→ 11 <mass value="1.729680238629788"/> 12 <inertia ixx="0.122469" iyy="0.093078" izz="0.197526" ixy="-5.1e-05" iyz="1.2e-05" ixz="0.006038"/>,→ 13 </inertial> 14 <visual> 15 <origin xyz="000"rpy="0 0 0"/> 16 <geometry> 17 <mesh filename="package://ERC22_URDF_description/meshes/base_link.stl" scale="0.001 0.001 0.001"/>,→ 18 </geometry> 19 <material name="silver"/> 20 </visual> 21 <collision> 22 <origin xyz="000"rpy="0 0 0"/> 23 <geometry> 24 <mesh filename="package://ERC22_URDF_description/meshes/base_link.stl" scale="0.001 0.001 0.001"/>,→ 25 </geometry> 26 </collision> 86 Terrain detection algorithm for the European Rover Challenge 27 </link> 28 29 <link name="WLF_supp_1"> 30 <inertial> 31 <origin xyz="-0.0005722202916380592 0.04456811672884131 -0.06998013314667545" rpy="0 0 0"/>,→ 32 <mass value="0.040963207008450755"/> 33 <inertia ixx="0.000114" iyy="9.6e-05" izz="3e-05" ixy="-0.0" iyz="1.6e-05" ixz="-1e-06"/>,→ 34 </inertial> 35 <visual> 36 <origin xyz="-0.391355 0.383158 -0.356565" rpy="0 0 0"/> 37 <geometry> 38 <mesh filename="package://ERC22_URDF_description/meshes/WLF_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 39 </geometry> 40 <material name="silver"/> 41 </visual> 42 <collision> 43 <origin xyz="-0.391355 0.383158 -0.356565" rpy="0 0 0"/> 44 <geometry> 45 <mesh filename="package://ERC22_URDF_description/meshes/WLF_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 46 </geometry> 47 </collision> 48 </link> 49 50 <link name="Left_leg_double_1"> 51 <inertial> 52 <origin xyz="-0.017610729784847123 -0.06278452284012215 -0.07487224121996011" rpy="0 0 0"/>,→ 53 <mass value="0.1583068780205665"/> 54 <inertia ixx="0.00075" iyy="0.003257" izz="0.002638" ixy="-0.000164" iyz="-3.5e-05" ixz="0.000733"/>,→ 55 </inertial> 56 <visual> 57 <origin xyz="0.252653 0.310658 -0.453036" rpy="0 0 0"/> 58 <geometry> 59 <mesh filename="package://ERC22_URDF_description/meshes/Left_leg_double_1.stl" scale="0.001 0.001 0.001"/> ,→ ,→ 87 Terrain detection algorithm for the European Rover Challenge 60 </geometry> 61 <material name="silver"/> 62 </visual> 63 <collision> 64 <origin xyz="0.252653 0.310658 -0.453036" rpy="0 0 0"/> 65 <geometry> 66 <mesh filename="package://ERC22_URDF_description/meshes/Left_leg_double_1.stl" scale="0.001 0.001 0.001"/> ,→ ,→ 67 </geometry> 68 </collision> 69 </link> 70 71 <link name="WLB_supp_1"> 72 <inertial> 73 <origin xyz="0.0011204573839502796 0.031881968364872504 -0.06607317272822505" rpy="0 0 0"/>,→ 74 <mass value="0.05726725763420208"/> 75 <inertia ixx="0.000209" iyy="0.000168" izz="5.9e-05" ixy="-1e-06" iyz="5.6e-05" ixz="2e-06"/>,→ 76 </inertial> 77 <visual> 78 <origin xyz="0.427929 0.392158 -0.371607" rpy="0 0 0"/> 79 <geometry> 80 <mesh filename="package://ERC22_URDF_description/meshes/WLB_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 81 </geometry> 82 <material name="silver"/> 83 </visual> 84 <collision> 85 <origin xyz="0.427929 0.392158 -0.371607" rpy="0 0 0"/> 86 <geometry> 87 <mesh filename="package://ERC22_URDF_description/meshes/WLB_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 88 </geometry> 89 </collision> 90 </link> 91 92 <link name="WLB_1"> 93 <inertial> 88 Terrain detection algorithm for the European Rover Challenge 94 <origin xyz="-0.000157582105088927 -0.04853467078008089 -2.617517294800642e-06" rpy="0 0 0"/>,→ 95 <mass value="0.821177966951147"/> 96 <inertia ixx="0.002537" iyy="0.004162" izz="0.002536" ixy="6e-06" iyz="0.0" ixz="0.0"/>,→ 97 </inertial> 98 <visual> 99 <origin xyz="0.425007 0.373675 -0.213634" rpy="0 0 0"/> 100 <geometry> 101 <mesh filename="package://ERC22_URDF_description/meshes/WLB_1.stl" scale="0.001 0.001 0.001"/>,→ 102 </geometry> 103 <material name="silver"/> 104 </visual> 105 <collision> 106 <origin xyz="0.425007 0.373675 -0.213634" rpy="0 0 0"/> 107 <geometry> 108 <mesh filename="package://ERC22_URDF_description/meshes/WLB_1.stl" scale="0.001 0.001 0.001"/>,→ 109 </geometry> 110 </collision> 111 </link> 112 113 <link name="WLM_1"> 114 <inertial> 115 <origin xyz="-7.105685515228222e-07 -0.05483339443238944 1.1425396012620936e-07" rpy="0 0 0"/>,→ 116 <mass value="0.8017382692848779"/> 117 <inertia ixx="0.002476" iyy="0.004159" izz="0.002476" ixy="0.0" iyz="0.0" ixz="0.0"/>,→ 118 </inertial> 119 <visual> 120 <origin xyz="0.02448 0.380158 -0.210124" rpy="0 0 0"/> 121 <geometry> 122 <mesh filename="package://ERC22_URDF_description/meshes/WLM_1.stl" scale="0.001 0.001 0.001"/>,→ 123 </geometry> 124 <material name="silver"/> 125 </visual> 126 <collision> 127 <origin xyz="0.02448 0.380158 -0.210124" rpy="0 0 0"/> 89 Terrain detection algorithm for the European Rover Challenge 128 <geometry> 129 <mesh filename="package://ERC22_URDF_description/meshes/WLM_1.stl" scale="0.001 0.001 0.001"/>,→ 130 </geometry> 131 </collision> 132 </link> 133 134 <link name="WLF_1"> 135 <inertial> 136 <origin xyz="0.00034755415545323354 -0.04824687617687501 -1.7828776904815768e-07" rpy="0 0 0"/>,→ 137 <mass value="0.8211285553800025"/> 138 <inertia ixx="0.002536" iyy="0.004162" izz="0.002535" ixy="-1.2e-05" iyz="0.0" ixz="-0.0"/>,→ 139 </inertial> 140 <visual> 141 <origin xyz="-0.391222 0.364675 -0.216565" rpy="0 0 0"/> 142 <geometry> 143 <mesh filename="package://ERC22_URDF_description/meshes/WLF_1.stl" scale="0.001 0.001 0.001"/>,→ 144 </geometry> 145 <material name="silver"/> 146 </visual> 147 <collision> 148 <origin xyz="-0.391222 0.364675 -0.216565" rpy="0 0 0"/> 149 <geometry> 150 <mesh filename="package://ERC22_URDF_description/meshes/WLF_1.stl" scale="0.001 0.001 0.001"/>,→ 151 </geometry> 152 </collision> 153 </link> 154 155 <link name="WRF_supp_1"> 156 <inertial> 157 <origin xyz="-0.0004356849889970982 -0.037844265968987545 -0.09650313579211883" rpy="0 0 0"/>,→ 158 <mass value="0.06594197827899752"/> 159 <inertia ixx="0.000199" iyy="0.000176" izz="3.9e-05" ixy="0.0" iyz="3e-06" ixz="-0.0"/>,→ 160 </inertial> 161 <visual> 90 Terrain detection algorithm for the European Rover Challenge 162 <origin xyz="-0.391354 -0.386841 -0.356561" rpy="0 0 0"/> 163 <geometry> 164 <mesh filename="package://ERC22_URDF_description/meshes/WRF_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 165 </geometry> 166 <material name="silver"/> 167 </visual> 168 <collision> 169 <origin xyz="-0.391354 -0.386841 -0.356561" rpy="0 0 0"/> 170 <geometry> 171 <mesh filename="package://ERC22_URDF_description/meshes/WRF_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 172 </geometry> 173 </collision> 174 </link> 175 176 <link name="WRB_supp_1"> 177 <inertial> 178 <origin xyz="0.0010379712309944722 -0.03184148815717791 -0.06649153329813762" rpy="0 0 0"/>,→ 179 <mass value="0.05751878988929576"/> 180 <inertia ixx="0.000212" iyy="0.000171" izz="5.9e-05" ixy="1e-06" iyz="-5.6e-05" ixz="2e-06"/>,→ 181 </inertial> 182 <visual> 183 <origin xyz="0.427806 -0.396591 -0.371346" rpy="0 0 0"/> 184 <geometry> 185 <mesh filename="package://ERC22_URDF_description/meshes/WRB_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 186 </geometry> 187 <material name="silver"/> 188 </visual> 189 <collision> 190 <origin xyz="0.427806 -0.396591 -0.371346" rpy="0 0 0"/> 191 <geometry> 192 <mesh filename="package://ERC22_URDF_description/meshes/WRB_supp_1.stl" scale="0.001 0.001 0.001"/>,→ 193 </geometry> 194 </collision> 195 </link> 196 91 Terrain detection algorithm for the European Rover Challenge 197 <link name="WRF_1"> 198 <inertial> 199 <origin xyz="0.00022231321115867564 0.030856418914129602 6.118055645987219e-07" rpy="0 0 0"/>,→ 200 <mass value="0.7923140233383783"/> 201 <inertia ixx="0.002447" iyy="0.004158" izz="0.002447" ixy="1.2e-05" iyz="0.0" ixz="-0.0"/>,→ 202 </inertial> 203 <visual> 204 <origin xyz="-0.39127 -0.375303 -0.216561" rpy="0 0 0"/> 205 <geometry> 206 <mesh filename="package://ERC22_URDF_description/meshes/WRF_1.stl" scale="0.001 0.001 0.001"/>,→ 207 </geometry> 208 <material name="silver"/> 209 </visual> 210 <collision> 211 <origin xyz="-0.39127 -0.375303 -0.216561" rpy="0 0 0"/> 212 <geometry> 213 <mesh filename="package://ERC22_URDF_description/meshes/WRF_1.stl" scale="0.001 0.001 0.001"/>,→ 214 </geometry> 215 </collision> 216 </link> 217 218 <link name="WRM_1"> 219 <inertial> 220 <origin xyz="-7.423233885535396e-07 0.04421440445825414 -8.285402313679135e-07" rpy="0 0 0"/>,→ 221 <mass value="0.8108718866431287"/> 222 <inertia ixx="0.002505" iyy="0.004161" izz="0.002505" ixy="0.0" iyz="0.0" ixz="0.0"/>,→ 223 </inertial> 224 <visual> 225 <origin xyz="0.024115 -0.384591 -0.21047" rpy="0 0 0"/> 226 <geometry> 227 <mesh filename="package://ERC22_URDF_description/meshes/WRM_1.stl" scale="0.001 0.001 0.001"/>,→ 228 </geometry> 229 <material name="silver"/> 230 </visual> 92 Terrain detection algorithm for the European Rover Challenge 42 <selfCollide>true</selfCollide> 43 </gazebo> 44 45 <gazebo reference="WLM_1"> 46 <material>${body_color}</material> 47 <mu1>10</mu1> 48 <mu2>5</mu2> 49 <selfCollide>true</selfCollide> 50 </gazebo> 51 52 <gazebo reference="WLF_1"> 53 <material>${body_color}</material> 54 <mu1>10</mu1> 55 <mu2>5</mu2> 56 <selfCollide>true</selfCollide> 57 </gazebo> 58 59 <gazebo reference="WRF_supp_1"> 60 <material>${body_color}</material> 61 <mu1>0.2</mu1> 62 <mu2>0.2</mu2> 63 <selfCollide>true</selfCollide> 64 </gazebo> 65 66 <gazebo reference="WRB_supp_1"> 67 <material>${body_color}</material> 68 <mu1>0.2</mu1> 69 <mu2>0.2</mu2> 70 <selfCollide>true</selfCollide> 71 </gazebo> 72 73 <gazebo reference="WRF_1"> 74 <material>${body_color}</material> 75 <mu1>10</mu1> 76 <mu2>5</mu2> 77 <selfCollide>true</selfCollide> 78 </gazebo> 79 80 <gazebo reference="WRM_1"> 81 <material>${body_color}</material> 82 <mu1>10</mu1> 99 Terrain detection algorithm for the European Rover Challenge 83 <mu2>5</mu2> 84 <selfCollide>true</selfCollide> 85 </gazebo> 86 87 <gazebo reference="WRB_1"> 88 <material>${body_color}</material> 89 <mu1>10</mu1> 90 <mu2>5</mu2> 91 <selfCollide>true</selfCollide> 92 </gazebo> 93 94 <gazebo reference="Right_leg_double_1"> 95 <material>${body_color}</material> 96 <mu1>0.2</mu1> 97 <mu2>0.2</mu2> 98 <selfCollide>true</selfCollide> 99 </gazebo> 100 101 <!-- camera --> 102 <gazebo reference="camera_link_left"> 103 <sensor type="camera" name="left"> 104 <update_rate>30.0</update_rate> 105 <camera name="left"> 106 <horizontal_fov>1.2217304</horizontal_fov> 107 <image> 108 <width>640</width> 109 <height>480</height> 110 <format>R8G8B8</format> 111 </image> 112 <clip> 113 <near>0.02</near> 114 <far>300</far> 115 </clip> 116 <noise> 117 <type>gaussian</type> 118 <!-- Noise is sampled independently per pixel on each frame. 119 That pixel's noise value is added to each of its color 120 channels, which at that point lie in the range [0,1]. --> 121 <mean>0.0</mean> 122 <stddev>0.007</stddev> 123 </noise> 100 Terrain detection algorithm for the European Rover Challenge 124 </camera> 125 <plugin name="camera_controller" filename="libgazebo_ros_camera.so"> 126 <alwaysOn>true</alwaysOn> 127 <updateRate>0.0</updateRate> 128 <cameraName>ERC22_URDF/left_camera</cameraName> 129 <imageTopicName>image_raw</imageTopicName> 130 <cameraInfoTopicName>camera_info</cameraInfoTopicName> 131 <frameName>camera_link_left</frameName> 132 <hackBaseline>0.07</hackBaseline> 133 <distortionK1>0.0</distortionK1> 134 <distortionK2>0.0</distortionK2> 135 <distortionK3>0.0</distortionK3> 136 <distortionT1>0.0</distortionT1> 137 <distortionT2>0.0</distortionT2> 138 </plugin> 139 </sensor> 140 </gazebo> 141 142 <gazebo reference="camera_link_right"> 143 <sensor type="camera" name="right"> 144 <update_rate>30.0</update_rate> 145 <camera name="right"> 146 <horizontal_fov>1.3962634</horizontal_fov> 147 <image> 148 <width>800</width> 149 <height>800</height> 150 <format>R8G8B8</format> 151 </image> 152 <clip> 153 <near>0.02</near> 154 <far>300</far> 155 </clip> 156 <noise> 157 <type>gaussian</type> 158 <!-- Noise is sampled independently per pixel on each frame. 159 That pixel's noise value is added to each of its color 160 channels, which at that point lie in the range [0,1]. --> 161 <mean>0.0</mean> 162 <stddev>0.007</stddev> 163 </noise> 164 </camera> 101 Terrain detection algorithm for the European Rover Challenge 165 <plugin name="camera_controller" filename="libgazebo_ros_camera.so"> 166 <alwaysOn>true</alwaysOn> 167 <updateRate>0.0</updateRate> 168 <cameraName>ERC22_URDF/right_camera</cameraName> 169 <imageTopicName>image_raw</imageTopicName> 170 <cameraInfoTopicName>camera_info</cameraInfoTopicName> 171 <frameName>camera_link_right</frameName> 172 <hackBaseline>0.07</hackBaseline> 173 <distortionK1>0.0</distortionK1> 174 <distortionK2>0.0</distortionK2> 175 <distortionK3>0.0</distortionK3> 176 <distortionT1>0.0</distortionT1> 177 <distortionT2>0.0</distortionT2> 178 </plugin> 179 </sensor> 180 </gazebo> 181 182 </robot> Listing 10: Gazebo robot definition 1<?xml version="1.0" ?> 2<robot name="ERC22_URDF" xmlns:xacro="http://www.ros.org/wiki/xacro" > 3 4<transmission name="S_LF_tran"> 5<type>transmission_interface/SimpleTransmission</type> 6<joint name="S_LF"> 7 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 8</joint> 9<actuator name="S_LF_actr"> 10 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 11 <mechanicalReduction>1</mechanicalReduction> 12 </actuator> 13 </transmission> 14 15 <transmission name="L_DS_tran"> 16 <type>transmission_interface/SimpleTransmission</type> 17 <joint name="L_DS"> 102 Terrain detection algorithm for the European Rover Challenge 18 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 19 </joint> 20 <actuator name="L_DS_actr"> 21 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 22 <mechanicalReduction>1</mechanicalReduction> 23 </actuator> 24 </transmission> 25 26 <transmission name="S_LB_tran"> 27 <type>transmission_interface/SimpleTransmission</type> 28 <joint name="S_LB"> 29 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 30 </joint> 31 <actuator name="S_LB_actr"> 32 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 33 <mechanicalReduction>1</mechanicalReduction> 34 </actuator> 35 </transmission> 36 37 <transmission name="W_LB_tran"> 38 <type>transmission_interface/SimpleTransmission</type> 39 <joint name="W_LB"> 40 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 41 </joint> 42 <actuator name="W_LB_actr"> 43 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 44 <mechanicalReduction>1</mechanicalReduction> 45 </actuator> 46 </transmission> 47 48 <transmission name="W_LM_tran"> 49 <type>transmission_interface/SimpleTransmission</type> 50 <joint name="W_LM"> 51 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 103 Terrain detection algorithm for the European Rover Challenge 52 </joint> 53 <actuator name="W_LM_actr"> 54 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 55 <mechanicalReduction>1</mechanicalReduction> 56 </actuator> 57 </transmission> 58 59 <transmission name="W_LF_tran"> 60 <type>transmission_interface/SimpleTransmission</type> 61 <joint name="W_LF"> 62 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 63 </joint> 64 <actuator name="W_LF_actr"> 65 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 66 <mechanicalReduction>1</mechanicalReduction> 67 </actuator> 68 </transmission> 69 70 <transmission name="S_RF_tran"> 71 <type>transmission_interface/SimpleTransmission</type> 72 <joint name="S_RF"> 73 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 74 </joint> 75 <actuator name="S_RF_actr"> 76 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 77 <mechanicalReduction>1</mechanicalReduction> 78 </actuator> 79 </transmission> 80 81 <transmission name="S_RB_tran"> 82 <type>transmission_interface/SimpleTransmission</type> 83 <joint name="S_RB"> 84 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 85 </joint> 86 <actuator name="S_RB_actr"> 104 Terrain detection algorithm for the European Rover Challenge 87 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 88 <mechanicalReduction>1</mechanicalReduction> 89 </actuator> 90 </transmission> 91 92 <transmission name="W_RF_tran"> 93 <type>transmission_interface/SimpleTransmission</type> 94 <joint name="W_RF"> 95 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 96 </joint> 97 <actuator name="W_RF_actr"> 98 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 99 <mechanicalReduction>1</mechanicalReduction> 100 </actuator> 101 </transmission> 102 103 <transmission name="W_RM_tran"> 104 <type>transmission_interface/SimpleTransmission</type> 105 <joint name="W_RM"> 106 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 107 </joint> 108 <actuator name="W_RM_actr"> 109 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 110 <mechanicalReduction>1</mechanicalReduction> 111 </actuator> 112 </transmission> 113 114 <transmission name="W_RB_tran"> 115 <type>transmission_interface/SimpleTransmission</type> 116 <joint name="W_RB"> 117 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 118 </joint> 119 <actuator name="W_RB_actr"> 120 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 105 Terrain detection algorithm for the European Rover Challenge 121 <mechanicalReduction>1</mechanicalReduction> 122 </actuator> 123 </transmission> 124 125 <transmission name="R_DS_tran"> 126 <type>transmission_interface/SimpleTransmission</type> 127 <joint name="R_DS"> 128 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 129 </joint> 130 <actuator name="R_DS_actr"> 131 <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>,→ 132 <mechanicalReduction>1</mechanicalReduction> 133 </actuator> 134 </transmission> 135 136 </robot> Listing 11: Transmission robot definition A.8 Simulation launcher 1<launch> 2<param name="robot_description" command="$(find xacro)/xacro $(find ERC22_URDF_description)/urdf/ERC22_URDF.xacro"/>,→ 3<node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-param robot_description -urdf -model ERC22_URDF"/>,→ 4<include file="$(find gazebo_ros)/launch/empty_world.launch"> 5<arg name="world_name" value="worlds/Nav_task.world"/> 6<arg name="paused" value="true"/> 7<arg name="use_sim_time" value="true"/> 8<arg name="gui" value="true"/> 9<arg name="headless" value="false"/> 10 <arg name="debug" value="false"/> 11 </include> 12 </launch> 13 14 <!-- --> Listing 12: Gazebo launcher simulation 106 Terrain detection algorithm for the European Rover Challenge A.9 Controllers definition 1ERC22_URDF: 2# Publish all joint states ----------------------------------- 3joint_state_controller: 4type: joint_state_controller/JointStateController 5publish_rate: 50 6 7# Position Controllers -------------------------------------- 8S_LF_position_controller: 9type: effort_controllers/JointPositionController 10 joint: S_LF 11 pid: {p:5.0,i:0.1,d:0.2} 12 S_LB_position_controller: 13 type: effort_controllers/JointPositionController 14 joint: S_LB 15 pid: {p:5.0,i:0.1,d:0.2} 16 W_LB_velocity_controller: 17 type: effort_controllers/JointVelocityController 18 joint: W_LB 19 pid: {p:1.0,i:0.0,d:0.0} 20 W_LM_velocity_controller: 21 type: effort_controllers/JointVelocityController 22 joint: W_LM 23 pid: {p:1.0,i:0.0,d:0.0} 24 W_LF_velocity_controller: 25 type: effort_controllers/JointVelocityController 26 joint: W_LF 27 pid: {p:1.0,i:0.0,d:0.0} 28 S_RF_position_controller: 29 type: effort_controllers/JointPositionController 30 joint: S_RF 31 pid: {p:5.0,i:0.1,d:0.2} 32 S_RB_position_controller: 33 type: effort_controllers/JointPositionController 34 joint: S_RB 35 pid: {p:5.0,i:0.1,d:0.2} 36 W_RF_velocity_controller: 37 type: effort_controllers/JointVelocityController 38 joint: W_RF 39 pid: {p:1.0,i:0.0,d:0.0} 107 Terrain detection algorithm for the European Rover Challenge 40 W_RM_velocity_controller: 41 type: effort_controllers/JointVelocityController 42 joint: W_RM 43 pid: {p:1.0,i:0.0,d:0.0} 44 W_RB_velocity_controller: 45 type: effort_controllers/JointVelocityController 46 joint: W_RB 47 pid: {p:1.0,i:0.0,d:0.0} 48 L_DS_position_controller: 49 type: effort_controllers/JointPositionController 50 joint: L_DS 51 pid: {p:5.0,i:0.1,d:0.2} 52 R_DS_position_controller: 53 type: effort_controllers/JointPositionController 54 joint: R_DS 55 pid: {p:5.0,i:0.1,d:0.2} Listing 13: Controller definition A.10 Controllers launcher 1<launch> 2 3<rosparam file="$(find ERC22_URDF_description)/launch/controller.yaml" command="load"/>,→ 4<node name="controller_spawner" pkg="controller_manager" type="spawner" respawn="false" output="screen",→ 5args="ERC22_URDF/S_LF_position_controller 6ERC22_URDF/S_LB_position_controller 7ERC22_URDF/S_RF_position_controller 8ERC22_URDF/S_RB_position_controller 9ERC22_URDF/W_LB_velocity_controller 10 ERC22_URDF/W_LM_velocity_controller 11 ERC22_URDF/W_LF_velocity_controller 12 ERC22_URDF/W_RF_velocity_controller 13 ERC22_URDF/W_RM_velocity_controller 14 ERC22_URDF/W_RB_velocity_controller 15 ERC22_URDF/L_DS_position_controller 16 ERC22_URDF/R_DS_position_controller 17 ERC22_URDF/joint_state_controller "/> 108 Terrain detection algorithm for the European Rover Challenge Figure 67: Landmark 9. [24] Figure 68: Landmark 10. [24] 115 Terrain detection algorithm for the European Rover Challenge Figure 69: Landmark 11. [24] Figure 70: Landmark 12. [24] 116 Terrain detection algorithm for the European Rover Challenge Figure 71: Landmark 13. [24] Figure 72: Landmark 14. [24] 117 Terrain detection algorithm for the European Rover Challenge Figure 73: Landmark 15. [24] B.2 Camera view Figure 74: Left camera view in Waypoint A at 0 rad yaw. Own image 118 Terrain detection algorithm for the European Rover Challenge Figure 75: Right camera view in Waypoint A at 0 rad yaw. Own image Figure 76: Left camera view in Waypoint A at π 4rad yaw. Own image 119 Terrain detection algorithm for the European Rover Challenge Figure 77: Right camera view in Waypoint A at π 4rad yaw. Own image Figure 78: Left camera view in Waypoint A at π 2rad yaw. Own image 120 Terrain detection algorithm for the European Rover Challenge Figure 79: Right camera view in Waypoint A at π 2rad yaw. Own image Figure 80: Left camera view in Waypoint A at 3π 4rad yaw. Own image 121 Terrain detection algorithm for the European Rover Challenge Figure 81: Right camera view in Waypoint A at 3π 4rad yaw. Own image Figure 82: Left camera view in Waypoint A at πrad yaw. Own image 122 Terrain detection algorithm for the European Rover Challenge Figure 83: Right camera view in Waypoint A at πrad yaw. Own image Figure 84: Left camera view in Waypoint A at 5π 4rad yaw. Own image 123 Terrain detection algorithm for the European Rover Challenge Figure 85: Right camera view in Waypoint A at 5π 4rad yaw. Own image Figure 86: Left camera view in Waypoint A at 3π 2rad yaw. Own image 124 Terrain detection algorithm for the European Rover Challenge Figure 99: Right camera view in Waypoint F at πrad yaw. Own image Figure 100: Left camera view in Waypoint F at 5π 4rad yaw. Own image 131 Terrain detection algorithm for the European Rover Challenge Figure 101: Right camera view in Waypoint F at 5π 4rad yaw. Own image Figure 102: Left camera view in Waypoint F at 3π 2rad yaw. Own image 132 Terrain detection algorithm for the European Rover Challenge Figure 103: Right camera view in Waypoint F at 3π 2rad yaw. Own image Figure 104: Left camera view in Waypoint F at 7π 4rad yaw. Own image 133 Terrain detection algorithm for the European Rover Challenge Figure 105: Right camera view in Waypoint F at 7π 4rad yaw. Own image Figure 106: Left camera view in Waypoint G at 0 rad yaw. Own image 134 Terrain detection algorithm for the European Rover Challenge Figure 107: Right camera view in Waypoint G at 0 rad yaw. Own image Figure 108: Left camera view in Waypoint G at π 4rad yaw. Own image 135 Terrain detection algorithm for the European Rover Challenge Figure 109: Right camera view in Waypoint G at π 4rad yaw. Own image Figure 110: Left camera view in Waypoint G at π 2rad yaw. Own image 136 Terrain detection algorithm for the European Rover Challenge Figure 111: Right camera view in Waypoint G at π 2rad yaw. Own image Figure 112: Left camera view in Waypoint G at 3π 4rad yaw. Own image 137 Terrain detection algorithm for the European Rover Challenge Figure 113: Right camera view in Waypoint G at 3π 4rad yaw. Own image Figure 114: Left camera view in Waypoint G at πrad yaw. Own image 138 Terrain detection algorithm for the European Rover Challenge Figure 115: Right camera view in Waypoint G at πrad yaw. Own image Figure 116: Left camera view in Waypoint G at 5π 4rad yaw. Own image 139 Terrain detection algorithm for the European Rover Challenge Figure 117: Right camera view in Waypoint G at 5π 4rad yaw. Own image Figure 118: Left camera view in Waypoint G at 3π 2rad yaw. Own image 140