EE50237 Robotics Software
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
EE50237 Robotics Software – Assessed Project 2022:
The assessed project is presented in the form of a challenge. A competition will take place during the lab session of week 11. The competition provides a focussed objective within which you can learn about ROS and the intelligent control of a robot. It also provides a vehicle to demonstrate your new skills for the purposes of assessment.
The Robot Challenge
Your ROSBot robot must navigate an obstacle course that will be setup in the lab . An example obstacle course from the simulator is shown below. The robot must start at the coke can (left of image), and end on the other side of the obstacles, at the position shown by the person (right of image).
Your control software should also be tested in the simulation environment provided as you go.
You should assume there will be no direct line of sight path from start to finish, but that a path is possible. You can assume that the course itself will remain fixed throughout the challenge. No map of the course or other parametric data will be provided in advance.
In the lab you will work in groups, with one robot per group. You can take turns to test your software and then enter whatever software configuration you decide upon in the group challenge.
Each student group will have three attempts to complete the course, and you can modify your code or configuration parameters between each attempt. However, we must complete the challenge for all students within the time available.
The final score will be the total over the three trials. The lowest score wins. The judges’ decision is final.
Your competition score will be calculated from a combination of:
1. Distance travelled
2. Total Time taken
3. Penalty for each object hit by the robot, and
4. Each occurrence of manual intervention (for example if the robot tips over or gets stuck.)
Your software design should consider these competing metrics. Your robot must also measure and report distance travelled and time taken (real-time, not simulated time). Distance travelled can be measured via wheel rotation.
Note: Failure to report distance travelled will result in a manual calculation of distance travelled based on total time taken and the maximum speed achievable by the robot platform.
You can use any or all of the robot’s sensors, but are not allowed to access sensory data external to the robot, for example via an additional camera within the simulation. No off-robot processing is allowed, however logging of data and monitoring is allowed. The robot software design may optionally include ‘learning’ across the trials.
Package Name and Launch File Requirements
On the day of the competition, the entire ROS environment must be launched from a single launch file command of the form
roslaunch userid_rosbot userid_rosbot.launch
where userid is your Bath username e.g. abc123. This launch file should also produce a trace of easily human-readable data to show distance travelled and total time taken.
It is important that you follow the naming requirements for your package so that multiple students can use one ROSbot without risk of conflict.
Assessed Report
Your competition result is not taken into consideration in the marking of your project work. However, your project must meet all the requirements of the challenge, and you should refer to the performance of your software on the physical ROSBot as part of your report.
Your individual project report of up to 5000 words forms the sole assessment for this unit.
The report should be organised into six sections as follows
1. Problem Analysis. This section should analyse the design criteria, and arrive at a high level design approach. The rationale for the design approach should be explained and justified. For example, explain why you decided to use certain sensors, or use a specific control strategy. If you altered your design during the project , explain why.
2. Software Architecture. This section should explain and document the detailed software architecture, particularly including a ROS Graph for the robot.
3. Software implementation. This section should document the implementation of code, providing sufficient detail for someone previously uninvolved with the project, but competent with Linux and ROS, to undertake code maintenance or enhancements. Include details of dependencies.
4. Testing Approach. This section should document how you intend to test your robot code, and particularly what test harnesses, tools or other methods you will use during testing.
5. Test results. This section documents the results of your robot testing in simulation and on the ROSBot hardware.
6. Conclusions & Further Work. In this section you should summarise the outcome of the project in relation to the problem specification. You should also suggest potential improvements to your design and/or code.
You may attach parts, or all of your code as an appendix to the report. Only small code snippets should be included within the body of the report. The report must be your own individual work.
Marking Scheme
The marking scheme is as follows:
1. Problem Analysis
a. Analysis of design criteria (10)
b. Synthesis of design (15)
2. Software Architecture (20)
3. Software Implementation (20)
4. Testing Approach (10)
5. Test Results (15)
6. Conclusions & Further Work (10)
For each section, consideration will be given to
1. Clarity
2. Presentation
3. Use of diagrams, photos, screen shots and other relevant figures
2023-01-05