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