UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 1 of 18 MTRN2500 20T3 C++ Assignment Task Descriptions (Updated 05/10/2020) Changelog • 05/10: First release 1. Overview of the C++ Assignment: The main assignment of the C++ part of MTRN2500 20T3 is a robotics-simulation project based on the Webots simulator. You will be given a Webots world file containing two robots and a racing setup. You are required to develop ONE controller using C++ that enables BOTH robots to complete a series of tasks in the given setup. The assignment is worth 35% of your total marks in this course. The marks will include two components: 25 marks for the functionality of your program and 10 marks for the quality. The due date of this assignment is 12:00 29th Oct 2020 (Midday Thursday Week 7). You should complete this assignment individually. 1.1. Expectations: By the end of the assignment, you are expected to have been able to: • understand the basic features of C++ and use them appropriately in developing a robot controller, • use Object-Oriented programming techniques to design a C++ program, • make appropriate use of common standard libraries (including STL), • be familiar with file I/O, and • follow good programming styles and practices. 1.2. Learning Outcomes Associated with this Assignment: • LO1: Be well versed with structured and modular programming using C/CPP and to have appreciated the use of software to communicate with external devices. • LO2: Be able to understand how to interface to an external device through a computer program to effect control action. • LO3: Be able to develop prototype user interfaces to assist in the development of controlled Mechatronic systems. UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 2 of 18 2. Task Descriptions: In this assignment you will be given a Webots world file as shown in Fig. 1. The setup contains a set of walls and two robots. The robot on the left has the name “ROBOT_RED” and the one on the right is named “ROBOT_BLUE”. Both robots have the same characteristics except for the name and colour (see section 3.1). Fig. 1. The setup of the assignment (MTRN2500.wbt) You are required to develop ONE controller, named “Robot_Controller_z1234567”, that will be added to BOTH robots. Here z1234567 should be replaced by your zID. The controller should complete the following tasks: 2.1. Display a list of commands at the start of the simulation (1 mark): Once the simulation is started, the controller should display a list of commands in the console (you do not need to follow the indentation shown in the example): The controller should then wait for the user’s input. The user will need to click on the simulation window (so that the window can capture keyboard messages) and press a key. The user may input any key at this stage: TASK_MANAGER: Please select the command: TASK_MANAGER: [1] run ROBOT_RED in manual-control mode and write data to ROBOT_RED.csv TASK_MANAGER: [2] run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv TASK_MANAGER: [3] run ROBOT_RED and ROBOT_BLUE in wall-following mode TASK_MANAGER: [4] run ROBOT_RED or ROBOT_BLUE in shortest-time mode TASK_MANAGER: [5] read data from ROBOT_RED.csv and process TASK_MANAGER: [6] read data from ROBOT_BLUE.csv and process UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 3 of 18 • If the user input was ‘1’, the controller should display the following message and execute the tasks defined in section 2.2 • If the user input was ‘2’, the controller should display the following message and execute the tasks defined in section 2.3 • If the user input was ‘3’, the controller should display the following message and execute the tasks defined in section 2.4 • If the user input was ‘4’, the controller should display the following message and execute the tasks defined in section 2.5 • If the user input was ‘5’, the controller should display the following message and execute the tasks defined in section 2.6 • If the user input was ‘6’, the controller should display the following message and execute the tasks defined in section 2.7 • If the user input was any key else, the controller should display nothing Note 1, the above applies to the controllers of both robots (both robots will be added with the same controller). Therefore, there could be duplicate messages displayed by the TASK_MANAGER of the two controllers as both controllers can capture the key input from the user. Note 2, throughout the program, it is fine if there are duplicate messages output by TASK_MAGAGER because two identical controllers are running simultaneously. 2.2. Run ROBOT_RED in manual-control mode and write data to ROBOT_RED.csv (3 marks): In this subtask, the controller should allow the user to control ROBOT_RED manually using the keyboard. Once entering this mode, if the robot is ROBOT_RED, the controller should display the following messages in the console (if the robot is ROBOT_BLUE, the controller should do nothing until the end of the program): TASK_MANAGER: Your input was 1 - now run ROBOT_RED in manual-control mode and write data to ROBOT_RED.csv TASK_MANAGER: Your input was 2 - now run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv TASK_MANAGER: Your input was 3 - now run ROBOT_RED and ROBOT_BLUE in wall- TASK_MANAGER: Your input was 4 - now run ROBOT_RED or ROBOT_BLUE in shortest-time TASK_MANAGER: Your input was 5 - now read data from ROBOT_RED.csv and process TASK_MANAGER: Your input was 6 - now read data from ROBOT_BLUE.csv and process UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 4 of 18 The controller should now start writing data to “ROBOT_RED.csv” and wait for the user’s input. 2.2.1. Write data to ROBOT_RED.csv The controller should write the following data to the file: Virtual_Time,Raw_Reading_ds0,Raw_Reading_ds1,Raw_Reading_ds2,Raw_Reading_ds3 Here Virtual_Time is the simulated time of a running simulation (link), and the raw readings are the raw measurement values generated by the four distance sensors of the robot. Example data stored in ROBOT_RED.csv are shown in Fig. 2. The data are separated by commas. There is no need to add a header to the first line. Fig. 2. Example data stored in ROBOT_RED.csv The file should be stored in the same folder that contains “Robot_Controller_z1234567.exe”/”Robot_Controller_z1234567”.[To Check: what is the extension on MacOS?]. The file should be opened in “append” mode, i.e., adding new data to the end if the file exists or create a new file if it does not exist. 2.2.2. Run ROBOT_RED in manual-control mode While the controller writes data to ROBOT_RED.csv, the controller should also wait for user’s input to manually control the robot: • When the user clicks on the simulation window and presses the ‘W/w’ key, the robot should move forward until a further and different command is received. • When the user clicks on the simulation window and presses the ‘S/s’ key, the robot should move backward until a further and different command is received. • When the user clicks on the simulation window and presses the ‘A/a’ key, the robot should turn left until a further and different command is received. • When the user clicks on the simulation window and presses the ‘D/d’ key, the robot should turn right until a further and different command is received. TASK_MANAGER: Your input was 1 - now run ROBOT_RED in manual-control mode and write data to ROBOT_RED.csv ROBOT_RED: Starting writing data to ROBOT_RED.csv ROBOT_RED: Please use the following commands to control the motion: ROBOT_RED: [W] Move forward ROBOT_RED: [S] Move backward ROBOT_RED: [A] Turn left ROBOT_RED: [D] Turn right ROBOT_RED: [SPACE] Stop UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 5 of 18 • When the user clicks on the simulation window and presses the ‘SPACE’ key, the robot should stop until a further and different command is received. In all the cases above, the speed of the motors can be decided by you. However, the speed of the motors should never exceed the maximum speed (in both directions) as specified in section 3.1 at any time. An example scenario when ROBOT_RED is run in manual-control mode is shown in Fig. 3. Fig. 3. An example scenario when ROBOT_RED is run in manual-control mode 2.2.3. Termination of the mode The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to detect whether the robot has reached the target or not in this mode. You do not need to return to the initial state after the mode is terminated by the user. 2.3. Run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv (3 marks): In this subtask, the controller should allow the user to control ROBOT_BLUE manually using the keyboard. Once entering this mode, if the robot is ROBOT_ BLUE, the controller should display the following messages in the console (if the robot is ROBOT_ RED, the controller should do nothing until the end of the program): UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 6 of 18 The controller should now start writing data to “ROBOT_BLUE.csv” and wait for the user’s input. 2.3.1. Write data to ROBOT_BLUE.csv The controller should write the following data to the file: Virtual_Time,Raw_Reading_ds0,Raw_Reading_ds1,Raw_Reading_ds2,Raw_Reading_ds3 Here Virtual_Time is the simulated time of a running simulation (link), and the raw readings are the raw measurement values generated by the four distance sensors of the robot. Example data stored in ROBOT_BLUE.csv are shown in Fig. 4. The data are separated by commas. There is no need to add a header to the first line. Fig. 4. Example data stored in ROBOT_BLUE.csv The file should be stored in the same folder that contains “Robot_Controller_z1234567.exe”/”Robot_Controller_z1234567”.[To Check: what is the extension on MacOS?]. The file should be opened in “append” mode, i.e., adding new data to the end if the file exists or create a new file if it does not exist. 2.3.2. Run ROBOT_BLUE in manual-control mode While the controller writes data to ROBOT_BLUE.csv, the controller should also wait for user’s input to manually control the robot: • When the user clicks on the simulation window and presses the ‘UP’ key, the robot should move forward until a further and different command is received. • When the user clicks on the simulation window and presses the ‘DOWN’ key, the robot should move backward until a further and different command is received. • When the user clicks on the simulation window and presses the ‘LEFT’ key, the robot should turn left until a further and different command is received. • When the user clicks on the simulation window and presses the ‘RIGHT’ key, the robot should turn right until a further and different command is received. TASK_MANAGER: Your input was 2 - now run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv ROBOT_BLUE: Starting writing data to ROBOT_BLUE.csv ROBOT_BLUE: Please use the following commands to control the motion: ROBOT_BLUE: [UP] Move forward ROBOT_BLUE: [DOWN] Move backward ROBOT_BLUE: [LEFT] Turn left ROBOT_BLUE: [RIGHT] Turn right ROBOT_BLUE: [SPACE] Stop UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 7 of 18 • When the user clicks on the simulation window and presses the ‘SPACE’ key, the robot should stop until a further and different command is received. Note, Webots has defined the above four control keys as webots::Keyboard::UP, webots::Keyboard::DOWN, webots::Keyboard::LEFT, webots::Keyboard::RIGHT, respectively. In all the cases above, the speed of the motors can be decided by you. However, the speed of the motors should never exceed the maximum speed (in both directions) as specified in section 3.1 at any time. An example scenario when ROBOT_BLUE is run in manual-control mode is shown in Fig. 5. Fig. 5. An example scenario when ROBOT_BLUE is run in manual-control mode 2.3.3. Termination of the mode The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to detect whether the robot has reached the target or not in this mode. You do not need to return to the initial state after the mode is terminated by the user. 2.4. Run ROBOT_RED and ROBOT_BLUE in wall-following mode (8 marks): In this subtask, the controller should control BOTH robots to run automatically from the start position to the respective target position using a wall-following strategy. The controller should show the following messages at the start of this mode (the starting time is the Virtual Time when the robot starts moving; it is fine if there are duplicate messages from TASK_MANAGER) TASK_MANAGER: Your input was 3 - now run ROBOT_RED and ROBOT_BLUE in wall- following mode ROBOT_RED: Starting wall-following mode at 3.296 s ROBOT_BLUE: Starting wall-following mode at 3.296 s UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 8 of 18 The controller should adopt a wall-following strategy, i.e., ROBOT_RED should always follow the walls on its left, and ROBOT_BLUE should always follow the walls on its right. The two robots should automatically stop at the target positions illustrated in Fig. 6, respectively. Along the way, the two robots should always remain in their respective lane and do not cross the middle line. Fig. 6. Lanes and target positions for the two robots (illustrative, not marked in the world file) An example scenario when both robots are run in wall-following mode is shown in Fig. 7. Fig. 7. An example scenario when both robots are run in wall-following mode An example scenario when both robots reach the target position is shown in Fig. 8. UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 9 of 18 Fig. 8. An example scenario when both robots reach the target position Once the robot reaches the target position (fully within the target square), the robot should stop its motion and immediately report the virtual time: The controller should not display any other message during the subtask. The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to return to the initial state after the mode is terminated by the user. 2.5. Run ROBOT_RED or ROBOT_BLUE in shortest-time mode (4 marks): In this subtask, the controller should control EITHER robot to run automatically from the start position to the respective target position using the shortest-time strategy. You can choose which robot to run in this mode and set it in the code. The other robot should do nothing until the end of the program. The controller should show the following messages at the start of this mode (the starting time is the Virtual Time when the robot starts moving; here suppose ROBOT_RED is set to run in this mode) The controller can adopt ANY strategy, including wall-following, to achieve the shortest-time. However, the controller should NOT use any Webots node that directly enables the acquisition/manipulation of the location of the robot (e.g., the Supervisor node). There is no constraint that the robot must remain in its lane in this mode (i.e., the robot can cross the middle line). The robot should reach the target position automatically and report the virtual time immediately when it arrives at the target: ROBOT_RED: Reaching target position in wall-following mode at 51.328 s ROBOT_BLUE: Reaching target position in wall-following mode at 51.328 s TASK_MANAGER: Your input was 4 - now run ROBOT_RED or ROBOT_BLUE in shortest-time mode ROBOT_RED: Starting shortest-time mode at 3.296 s UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 10 of 18 An example scenario when ROBOT_RED reaches the target position in shortest-time mode is shown in Fig. 9. Fig. 9. An example scenario when ROBOT_RED reaches the target position in shortest-time mode The controller should not display any other message during the subtask. The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to return to the initial state after the mode is terminated by the user. 2.6. Read data from ROBOT_RED.csv and process (3 marks): In this subtask, the controller should read all the data from ROBOT_RED.csv and process the data. If the robot is ROBOT_RED, the controller should display a message (if the robot is ROBOT_BLUE, it should do nothing until the end of the program): The controller should then read all the data into the program (e.g., a 2D vector of double). If reading was successful, display: Otherwise (e.g., the file did not exist), display: If reading was successful, calculate the maximum, minimum, and average of each column of the data. For example, if the data stored in ROBOT_RED were: ROBOT_RED: Reaching target position in shortest-time mode at 43.520 s TASK_MANAGER: Your input was 5 - now read data from ROBOT_RED.csv and process ROBOT_RED: Reading data from ROBOT_RED.csv succeeded! ROBOT_RED: Reading data from ROBOT_RED.csv failed! UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 11 of 18 Fig. 10. Example data stored in ROBOT_RED.csv Then display the following messages (all the data displayed should have three digital numbers for the fraction part): The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to return to the initial state after the mode is terminated by the user. 2.7. Read data from ROBOT_BLUE.csv and process (3 marks): In this subtask, the controller should read all the data from ROBOT_BLUE.csv and process the data. If the robot is ROBOT_BLUE, the controller should display a message (if the robot is ROBOT_RED, it should do nothing until the end of the program): The controller should then read all the data into the program (e.g., a 2D vector of double). If reading was successful, display: Otherwise (e.g., the file did not exist), display: If reading was successful, sort the data based on the last column (from smallest to largest). Store the new data to a new file “ROBOT_BLUE_sorted.csv” and display a message: For example, if the data stored in “ROBOT_BLUE.csv” were: ROBOT_RED: The maximum values are – 3.424, 804.717, 135.805, 483.515, 797.188 ROBOT_RED: The minimum values are – 3.296, 782.649, 132.131, 477.599, 785.276 ROBOT_RED: The average values are – 3.360, 792.803, 133.789, 480.334, 790.877 TASK_MANAGER: Your input was 6 - now read data from ROBOT_BLUE.csv and process ROBOT_BLUE: Reading data from ROBOT_BLUE.csv succeeded! ROBOT_BLUE: Reading data from ROBOT_BLUE.csv failed! ROBOT_BLUE: Writing data to ROBOT_BLUE_sorted.csv succeeded! UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 12 of 18 Fig. 10. Example data stored in ROBOT_BLUE.csv Then the data written to “ROBOT_BLUE_sorted.csv” should be: Fig. 11. Example data written to ROBOT_BLUE_sorted.csv The user will terminate the mode by ending the whole simulation (e.g., clicking the pause button and resetting the simulation). You do not need to return to the initial state after the mode is terminated by the user. 2.8. Task summary: Table 1. Task summary Task Description 1 Display a list of commands at the start of the simulation (1 mark) 2 Run ROBOT_RED in manual-control mode and write data to ROBOT_RED.csv (3 marks) 3 Run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv (3 marks) 4 Run ROBOT_RED and ROBOT_BLUE in wall-following mode (8 marks) 5 Run ROBOT_RED or ROBOT_BLUE in shortest-time mode (4 marks) 6 Read data from ROBOT_RED.csv and process (3 marks) 7 Read data from ROBOT_BLUE.csv and process (3 marks) UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 13 of 18 3. Specifications and Hints: 3.1. Specifications: 1. The Webots world file provided with the description will also be used for assessment. You should NOT change the world file. 2. You should create ONE controller named “Robot_Controller_z1234567” where z1234567 is your zID and add the controller to BOTH robots for test. 3. Both robots have the SAME characteristics as follows: Table 2. Characteristics of both robots Devices Characteristics Values Motor Left Motor Name “left wheel motor” Right Motor Name “right wheel motor” Maximum Speed 10 rad/s Distance Sensor Distance Sensor Number 4 Distance Sensor Name “ds0”, “ds1”, “ds2”, “ds3” Obstacle detection threshold around 800.0 (tunable) Camera Camera Name “camera” Image width 80 pixels Image height 60 pixels 4. The distribution of the devices on the robot: Fig. 12. Device distribution 5. Ideally you should separate implementations and interfaces into multiple cpp and hpp files. However, for the sake of assessment, you are required to implement the program in ONE cpp file. 6. Your controller should use C++14 as the standard of C++ version. 3.2. Hints: 1. Consult the lecturer/demonstrators if you are unclear about anything. 2. When asking for help, post your error messages so that the problems are better understood 3. Refer to the example projects provided by Webots ds0 ds1 ds2 ds3 camera left wheel motor right wheel motor UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 14 of 18 4. Refer to the hpp and cpp files provided by Webots 5. Have a careful thought on the whole structure of the program 6. Divide the problem into subproblems and solve them one by one 7. Try using the concepts of object-oriented programming (classes, inheritance, etc.) as much as possible 8. If the structure is not clear at the beginning, try writing your program in a procedural structure first, and then optimise your program by restructuring/refactoring, etc. 9. Follow the style guide as much as possible (style matters!) UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 15 of 18 4. Assessment: 4.1. Marking criteria: This assignment will contribute 35% to your final mark. The marks will include two components: 25 marks for the functionality of your program and 10 marks for the quality. 4.1.1. Functionality (25 marks): The functionality of your program will be marked by following the criteria below: Table 3. Marking of the functionality (25 marks) Task Description Marking 1 Display a list of commands at the start of the simulation (1 mark) +0.5 if the display is correct +0.5 if the response of key input is correct 2 Run ROBOT_RED in manual- control mode and write data to ROBOT_RED.csv (3 marks) +1.5 if remote control is correct +1.5 if writing data is correct 3 Run ROBOT_BLUE in manual-control mode and write data to ROBOT_BLUE.csv (3 marks) +1.5 if remote control is correct +1.5 if writing data is correct 4 Run ROBOT_RED and ROBOT_BLUE in wall- following mode (8 marks) +2 if ROBOT_RED wall following is correct +2 if ROBOT_RED reaching target is correct +2 if ROBOT_BLUE wall following is correct +2 if ROBOT_BLUE reaching target is correct 5 Run ROBOT_RED or ROBOT_BLUE in shortest- time mode (4 marks) The marking of this section is explained in section 4.1.1.1 6 Read data from ROBOT_RED.csv and process (3 marks) +1 if reading and error handling is correct +2 if max, min, and average are correct 7 Read data from ROBOT_BLUE.csv and process (3 marks) +1 if reading and error handling is correct +2 if sorting and writing are correct 4.1.1.1. Marking of task 5 Marking of this component will be based on the performance of each submission against the best of all the submissions. Suppose is the best (shortest) time achieved from all the submissions, = 30 is the baseline, and is the time achieved by a submission. The mark for the submission will be calculated by: = min ( , ) = − − × 4 UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 16 of 18 As two extreme examples, the best submission ( = ) will get full 4 marks, while a submission having a time worse than the base line ( ≥ ) in the shortest-time mode gets 0 marks. 4.1.2. Quality (10 marks): The quality of your code will be marked by following the criteria below. Note that the mark for this part will be capped by a proportional mark of your performance in the functionality. For example, if your mark for functionality is X (out of 25) marks, then the maximum mark you can get for the quality is X/25*10 marks (make sure your program works!). Table 4. Marking of the quality (10 marks) Items Description Marking Good format Neat and tidy code. Consistent and appropriate use of indentation, braces, spaces, etc. 1 Good documentation and comments Functions should have comments document its interface. Critical or complex section of code should have comment explaining the logic to future maintainers of your code. Comments should explain the thinking behind the code and just restating the code that is obvious. Trivial/obvious items do not need to be commented. 1 Good choice of names Good variable names should answer the important questions another developer might have about the variable or function. 1 Use of functions Consistent use of functions to break program into small fragments will make the program more manageable, easier to understand, and avoid repeating yourself (DRY principle). 1 Use of constants Magic values in the code should be replaced by constants to both give a name to the value and make changing the value in the future easier. Reference parameters and member functions should be made constant wherever possible to avoid unintended modifications. 1 Use of references and auto References are used in function parameters where it is appropriate to avoid overhead of cloning. Auto is used for long types to improve readability. 1 OOP design Design of classes and hierarchy is rational and appropriate, achieving good modularity, reusability, data hiding etc. 4 4.2. Submission of your work You should save a copy of the cpp file of your controller and rename it as “MTRN2500_Robot_Controller_z1234567.cpp” where z1234567 is your zID. Submit this cpp file (only this file) via Moodle. 4.3. Submission deadline The submission deadline is 12:00 AEST 29 Oct 2020 (Midday Thursday Week 7). If your assignment is submitted after this time, each 1 hour it is late reduces the maximum mark it can achieve by 1% (out of 100%). For example, if an assignment worth 74% were submitted 10 UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 17 of 18 hours late, the late submission would have no effect. If the same assignment were submitted 30 hours late, it would be awarded 70%, the maximum mark it can achieve at that time. 4.4. Progress check You will have your progress checked with your demonstrator in a 5 min meeting on the afternoon of Friday Week 5 (or another time on weekdays Week 5 by appointment; you should contact your demonstrator to make an appointment in advance). To pass the progress check, you must demonstrate that you are able to display the messages in task 1 AND manually control the movement of at least one of the robots in task 2/3 (no need to show data writing). UNSW MTRN2500 20T3 Computing for Mechatronic Engineers Page 18 of 18 5. Additional Resources: • Webots user guide: https://cyberbotics.com/doc/guide/index • Webots reference manual: https://cyberbotics.com/doc/reference/index • Webots official tutorial 1: https://cyberbotics.com/doc/guide/tutorial-1-your-first-simulation-in- webots • Webots official tutorial 4: https://cyberbotics.com/doc/guide/tutorial-4-more-about-controllers • Webots robot node: https://www.cyberbotics.com/doc/reference/robot • Webots motor node: https://cyberbotics.com/doc/reference/motor • Webots distance sensor node: https://cyberbotics.com/doc/reference/distancesensor • Webots camera node: https://www.cyberbotics.com/doc/reference/camera • Webots keyboard node: https://www.cyberbotics.com/doc/reference/keyboard • Webots virtual time: https://www.cyberbotics.com/doc/reference/glossary • Example Webots project: Webots->Menu->File->Open Sample World->languages->cpp- >example.wbt • MTRN2500 Style Guide: https://moodle.telt.unsw.edu.au/pluginfile.php/6101784/mod_resource/content/1/StyleGuide. pdf • Sort 2D vectors on basis of a particular column: https://www.geeksforgeeks.org/sorting-2d- vector-in-c-set-1-by-row-and-column/
欢迎咨询51作业君
