Details (Internal students) Assignment 2
The assignment is to be done in pairs for internal students, but individually for those studying externally. Accordingly there is an alternative version of the assignment for external students. In working in pairs you are expected to try the paired programming approach from Extreme Programming, and in both cases to work to the principles of XP. That means:
- Clear and concise code, removing the need for documentation
- Code designed to be easy to refactor
- User tests should be designed prior to starting (Unit testing won’t be required until the third assignment)
- No planning for future iterations – focus on meeting these requirements, rather than pushing further
- Code using the principles of SOLID, as covered in the lectures
If you have contacted me previously about who you want to work with, you will have been paired with that person. Otherwise pairs have been assigned based on a combination of factors that should match practical groups, and emails will be sent out informing everyone as to who they are working with.
Background
The First Robotics Competition (FRC) is a contest in which teams of students build robots that compete to finish a complex series of challenges. A new challenge is announced each year, and teams are then given six weeks to design, build and program a robot that is capable of completing some or all of the tasks. On completion teams compete in a regional competition (in our case, the default regional is held in Sydney each year) and, (if successful), are invited to compete at the World Championships in Houston and New Orleans.
In recent years, challenges have included designing robots to play a version of volleyball; creating robotic forklifts to stack crates; making robots that can cross a variety of terrains while shooting balls through a goal; and having the robots both deliver gears and climb ropes (although not at the same time). However, although the challenges vary each year, one common element has been that the challenges are team based – rather than perform individually, the robots compete in “alliances” with two other teams. In the qualifying rounds the alliances are created randomly by the competition organisers, but in the finals the teams are expected to form their own alliances with other competitors. This, however, means that each team needs to scout the capabilities of their rivals in order to make the best selections for their alliances.
That is where this program comes in. The purpose of this program is to allow the team’s head scout to record significant
details about each robot at a competition and to generate meaningful reports to help with alliance selection.
BACK TO TOP
Game Rules
In 2014, the game was a mix between basketball, soccer and volleyball. There were two goals at either end of the field, consisting of a high goal (about six feet off the ground) and a low goal. Robots, competing in teams of three, would try to score points by either throwing the ball through the high goal (typically with a catapult) or by pushing the ball through the low goal. On the way they would score extra points if the passed the ball to another robot on their team and if they threw the ball over a bar in the middle of the field. There was also an autonomous period, in which the robot was not under human control, and in that period they could score points via a goal or simply by driving forward a set distance.
Thus teams could score points in one of five ways. In autonomous mode:
- Driving forward: 5 points
- Low goal: 6 points
- High goal: 15 points
When operated by a driver (TeleOp mode):
- High goal: 10 points
- Low goal: 1 point
- Throwing the ball over the middle bar: 10 points
- Catching the ball: 10 points
- First successful pass: 10 points
- Second successful pass: 20 points
For example, let’s say that a team consists of three robots, A, B, & C. In autonomous mode, A & B drive forward for 5 points each. C drives forward and successfully shoots a high goal, for 2O points (5 points for driving forward, 15 points for the goal). Thus at the end of autonomous, the team’s score is 30 points. When the operators take control, (TeleOp mode), B passes the ball to A, (10 points), which then throws the ball over the center bar (10 points). The ball is collected by C (second pass, 20 points) who then scores a high goal (10 points). Thus the first play scores 50 points, for a total of 80 points including autonomous. In the second play A is on defense, so B passes the ball to C who catches the ball (10 points for the pass, 10 points for the catch). C misses the high goal, but is able to push it through for a low goal (1 point), for a total of 21 points in the play, and an overall score of 101 points.
BACK TO TOP
Initial VB.NET Application
Initially, scouts were to visit each team outside of the competition and ask them about the robot’s respective abilities. Thus they asked each team a series of questions and recorded the answers in a small app. When complete, they read out each team’s responses to the head scout, who entered the values in a spreadsheet. The questions were:
- What is the team’s number?
- What is the team’s name?
- Can the robot drive forward in autonomous?
- Can the robot score a low goal in autonomous?
- Can the robot score a high goal in autonomous?
- Can the robot pass the ball?
- Can the robot catch a ball?
- Can the robot pick up a loose ball?
- Can the robot throw the ball over the center bar?
- Can the robot score a low goal?
- Can the robot score a high goal?
The application to collect this data was written in VB.NET, and will be provided to you.
Tasks Conversion
The first task is to convert the attached code from VB.NET to C#. The code meets the initial scouting requirements. It has been lightly commented, but the code should be clear overall.
BACK TO TOP
Although you will be expected to refactor, initially it would be worth just handling the conversion as is, rather than recoding from scratch or trying to modify the code while you convert it. You will need to submit the new C# version of the provided code as part of your assignment.
Refactoring
The code will need to be extensively refactored. Not all of these features are required to pass, but all of these will be required to get maximum marks.
Persistence
A few people did this in the first assignment, but it is certainly necessary in the second. You’ll need to save the data. When a user enters data about a robot, the data should be saved so that it is there next time.
Note this should not be automatic – it should be possible for the user to maintain details for multiple robots. Thus they should be allowed to save to more than one file.
Use case: Sam opens the program and enters the initial scouting details for team 6007. She then selects save, and saves her data as “6007”. The next time she opens the program, she selects load, chooses “6007”, and her data is loaded into the program for additional editing and reporting.
In-Match Performance
The biggest change is to record the performance of each robot during a match. Each scout will be assigned one robot each match, (so they will need six scouts to gather data on all of the robots). At the start of the match they will either a) open an existing file for that robot, or b) start and new record for the robot. They will then enter the match number, basic team details if not already present (if the user hasn’t entered data for that robot before) and record the answer to a series of questions about the match performance:
- Did the robot move forward in autonomous?
- Did the robot score a low goal in autonomous?
- Did the robot score a high goal in autonomous?
- Did the robot pass the ball?
- Did the robot collect a ball?
- Did the robot catch a ball?
- Did the robot throw a ball over the high bar?
- Did the robot score a low goal?
- Did the robot score a high goal?
In addition, the user will need to rate the robot’s performance on four factors:
- Overall Defense
- Maneuverability
- Speed
- High Goal Accuracy
- Overall Attack
BACK TO TOP
No decision has been made as to the rating method, but you could use a scale between 1 and 5, or rate them as “terrible, bad, average, good, excellent”, or use some other method.
Use case: John has been assigned to record data on team 4382 during match 6. John has not recorded data for 4382, so starts a new record, entering 4382 and 6 as the team and match number. John does not know the name of the team, so leaves that blank. During the match, John records that the robot did score at least one low goal, passed the ball, and moved forward in autonomous. John rates the robot as a 6/10 for defense, 4/10 for maneuverability, 7/10 for speed, 0/10 for high goal accuracy, and 5/10 for overall attack.
Exporting
When the match is completed (if only one match is recorded at a time) or at the end of the day (if you can support multiple matches), the user needs to export the data as a CSV file so it can be added by the head scout to their spreadsheet. Note that there are two sets of data to be exported – pre-match scouting data, and match data.
Use case: At the end of the match, Sam exports the match data as a CSV file and emails it to the head scout.
Use case: John handled the pre-game scouting and the matches for team 6008. At the end of the day, John exports the data as two files – 6008 pre-game.csv and 6008 matches.csv.
Importing
If exporting is working, it would be nice if importing was possible. If so, allow the user to import from a file the pre- game scouting data before the match starts. This is only necessary if you do not do the following task.
Use case: Paula has been assigned team 6008 for match 43. John initially collected this data, so Paula is emailed the pre-game file for 6008, and loads it into her application before the match starts.
Pre-Existing Team Details
So far it has been assumed that the data will be created for each team when the team is scouted. However, it is possible to generate a list of teams in the competition in advance. As an alternative to the previous task, allow the user to have a file containing the details (team number and name) of every robot in the competition. When they scout or watch a match, they select the team from a list and start entering data.
Use case: John opens up the program to score the 4165 in match 27. He starts by selecting team 4165 from a list, which pre-populates the team number and name.
Data Validation
The head coach is getting a lot of CSV files, and it could take a while to import each one. To make things easier we could develop an application which combines the CSV files into two (which later will be two sheets in Excel). The first combines all of the pre-game scouting data, noting that there can only be one record per team. Thus if twoBpAeCoKpTlOe ThOaPve
scouted the same team, the data will be flagged. The second combines all of the match data for all of the teams. As there can only be one record per team per match, any situation where the same team has two entries for the same match should also be flagged. Once imported and combined, all of the data should be exported.
Use case: Sam scouts team 6008 pre-match, and doesn’t realise that Jo has scouted the same team. Both send their CSV files to the head scout, who tries to import them using this application. When it detects a conflict, it flags the two files. The head coach deletes the file provided by Jo, as Sam has been the better scout.
Use case: Jo and John both collect data. In match 27, Jo watches team 6008, and John watches team 4567. In match 56, Jo and John both watch team 4567 (John was assigned 4367, but made a mistake, and thought 4567 was his). At the end of the day both submit their exported match data to the head coach. All the data is imported from both users, but match 56 raises a flag due to the double team numbers. The head coach selects the option to delete the second (John’s) set of data for that round, and the application continues to import the data.
Pictures and description
To make it easier to recognise robots, uses can add a picture and description to the robot details. These do not need to be in the CSV file, but it would be nice if they could be shared via other means.
Use case: Jo has been assigned robot 4567 for match 56. 4567 was scouted earlier by Sam. The head scout sends Jo a file containing the robot number, recorded description and a photo. When the match is about to start, Jo selects this file and confirms that the robot she can see is the one described and photographed.
Other Specifications
- You must use C# as the programming language
- Do not use a dedicated external database. Databases will be included in the third assignment.
- Assignments must be developed with Visual Studio.NET 2017 (both Professional and Express editions are fine)
- The completed code needs to be able to be run in a lab.
- You need to specify user tests for the UI classes.
- This is an Agile programming assignment. So coding in order to allow for refactoring later is essential.
- Saving data can be through object serialisation or a different means, as you see fit.
- There is room for creativity if you feel you can add extra features that will make a better application.
Deliverables
You will need to provide:
- Working code as a zipped archive containing all source files
- Version of the provided code rewritten in C#
- A document containing a list of user tests and expected results
- 500 word reflective report on the process. There is no mark attached to this – it is just your thoughts on extreme
programming as attempted for the project.
BACK TO TOP
Marking Scheme
The marking scheme is based on:
- Does it work: 40%
- How well does it meet the requirements: 20%
- How well is it written: 40%
Last modified: Tuesday, 10 April 2018, 11:22 AM
BACK TO TOP