Date:
8/5-2014
Duration of activity:
10:00 - 15:00
Group members:
Benjamin Grønlund
Christina Gøttsche
Levi á Torkilsheyggi
Initial Description of End Course Project
Group members:
Initial Description of End Course Project
As given by the lab session specification [1].
The purpose of this labsession was to make an initial effort to come up with a description of the end course project that we wanted to do. In the group we discussed different projects from the suggested list and discussed possible new projects.
For each proposal we considered the hardware/software platform, the overall software architecture and the software architecture on each component and we tried to point out the most difficult problems to be solved in each project.
We used this lab session to choose a project between the three described projects below.
Project 1: Supermarket
Scenario a
Location and actors:
Super market with goods divided into aisles, a cleaning assistant and a messy customer.
Description:
The messy customer knocks goods of the shelves and goes to tell the cleaning assistent which isle it made a mess in. The cleaning assistant goes to that aisle, finds the mess and transports it to the storage area.
Material: 2 NXT robots, aisles(Lego or some other material), track.
From curriculum: Linefollower, bluetooth communication, Behavior based with arbitrator.
The most difficult problems to be solved:
- to knock things down from a ‘shelf’
- to know if the cleaning robot has cleaned everything up
Scenario b
Location and actors: 
Supermarket with a theft alarm, a thief and a police man.
Description:
The thief triggers an alarm in the supermarket, causing the police manto go to the supermarket and chase the thief. The police man looks around for the thief that tries to escape, and if the police man touches the thief, the thief is caught and taken to jail.
Material: 2 NXT robots, aisles(Lego or some other material), track, touch sensor, 
From curriculum: Linefollower, bluetooth communication, Subsumption.
The most difficult problems to be solved:
- to program the behavior of the police man searching for the thief
- to make the robots drive around the supermarket following the aisles
Project 2: M&M’s sorting machine
Description: A machine for recognising the color of an M&M should push the M&M onto the truck bed of a truck, telling the car what color the M&M is. The truck then drives to a container that holds this color of M&Ms and unloads the M&M that it carries, to the container. It then drives back to the sorting machine getting ready for having a new M&M’s put onto the truck bed, and tells the machine when it is ready.
Material:
2 NXT robots, motors for pushing M&M onto truck bed, color sensor, motor for tilting truck bed, M&M’s, bluetooth communication, possibly: colored tape (for line following)
Software platform/architecture:
The color recognizing device (called the dispenser station) should have a reactive strategy that conveys an M&M from a container to the station where the color is recognized if no M&M is already there, and then it should push the M&M forward if its color has been recognized AND if the truck is ready to receive it.
The truck also should have a reactive strategy because is should deliver the M&M in its truck bed to the correct container, if a such has been placed there. Otherwise it should return to the station and be prepared for receiving an M&M.
Because the two components (dispenser station and truck) are dependent on knowing the status of each other to provide/receive the M&Ms, some communication is necessary. Since we potentially want to incorporate an extra robot for delivery that also is dependent on communication (about which color M&M to pick up), we could benefit from a star topology, where a computer acts as a hub delivering messages to the different terminals (robots).
Possible expansions of project:
- A collecting robot could be told (by the push of a physical button or a button on a computer) to pick up a certain color M&M and bring it to a certain drop-off place (where we can eat it).
- The sorting machine only wants three colors to be sorted. All other colors than these three should be dumped in the garbage; the three color containers are found by the truck by line following of colored lines to the containers, and the garbage container is navigated to by finding a waypoint.
- The sorting machine sorts many different-colored M&M’s in different color containers, before the truck itself unloads the M&M’s that’s in the most full container onto its own truck bed, and then driving them to the correct container.
The most difficult problems to be solved:
- getting the communication up and running as it should (maybe not as hard as we think),
- building an arrangement that makes it possible to recognise the M&M’s color correctly at all times no matter what size the M&M has (they sometimes vary a great deal in size)
Project 3: WRO-projekt
Description: As presented on the WRO specifications, the robot should drive out from its starting point, and complete two tasks, both in relation to a set of sun panels. First off it has to find the sun panels who has the wrong orientation, and then turn them around. Second it has to replace broken sun panels with new ones which are located back in the reserve parts storage. There are black lines between the different areas as well as between the sun panels, which can be utilized as road markers. Furthermore the broken sun panels are black, and working ones are blue on one side and red on the other.
Material:
1 NXT driven robot on wheels; 1/2 light sensor(s) to able to follow lines on the table; 1 color sensor (to distinguish between red, blue and black color on the solar panels), motors for picking up solar panels, motors for rotating the solar panels, possibly motors for moving sensors/getting them out of the way when having to ‘go over’ solar panels.
Software platform/architecture:
Only one component; the 1 NXT, is on the field and so no communication has to happen. 
The car driving around the field could use a sequential strategy, but in that it has to perform a great deal of activities, if just one thing goes wrong it could potentially mess up the whole rest of the sequential activities planned. This could be solved using ‘checkpoints’ or even better; a reactive strategy could be used.
The field has black tracks that can be followed with a line follower strategy. The solar panel’s orientation could be identified using a color sensor in that the color on e.g. the left side identifies if the solar panel is broken (black)/turning the right way (blue) of turning the wrong way (red). Then the vehicle would have to turn them to the right orientation. The car will have to identify which solar panels are black, and remember their location if it is to return with a functioning solar panel, and take the black one home/bring the faulty panel home and replacing it with a new one.
As speed is a factor and in order to save time, one strategy for the car could be to load the black solar panels onto itself, remember their location and then go ‘home’; unloading all the black ones and load the working ones, before returning to the locations of the black solar panels and place them there.
The most difficult problems to be solved:
- we believe that the most difficult problem would be replacing the black/broken solar panels. Our (limited) previous experience with the waypoint tracker is that after a few turns the robot can become too imprecise, and thus mistake a point for a different point. This means that we most likely have to utilize a line follower, but then we would have to somehow count the amount of turns and lines passed, so we can remember where we picked up the broken solar panel in order to be able to replace it accordingly
- completing the tasks within the time frame, because this means that there isn’t time to visit solar panels more times than necessary, but that it is important to somehow remember which panels already have been visited and checked/rotated or is to be replaced.
A more detailed description of our project, also with notes of how to accomplish the different actions in the system, is here.
Conclusion
We have chosen the project of constructing the M&Ms sorting factory as we find this the most interesting and because we can see the opportunities in that project. The reason is also that we think it is realistic for us to complete the project to an extent where we will actually have something to show, that is working, at the presentation point.
A more detailed description of our project, also with notes of how to accomplish the different actions in the system, is here.
Goal
Our goal is to create the following:
A dispenser station that is a lego construction that recognizes the color of an M&M (via a color sensor). This station pushes the M&M onto the bed of a delivery truck by rotating a conveyor belt, and then tells this truck what color the M&M is, via Bluetooth communication.
The delivery truck then drives to the distant container holding the matching color M&Ms by using the Navigator class to travel to a certain coordinate, and continues on with a linefollowing algorithm. The truck follows the line up to a colored marker, which it recognizes, then stops and turns around until it’s orientation is approximately perpendicular to the container. It then unloads to the container the M&M that it has carried, by tipping it’s motorized truck bed.
The truck then drives back to the dispenser station (through a series of traveling to different coordinates) and tells the dispenser station, via Bluetooth, that it is ready to receive a new M&M (or load of same-colored M&Ms).
Plan
Our plan is to start with having one person work on getting the bluetooth to work, and to divide the work on the delivery truck and the dispenser station between two people. As we progress the labor will be divided in the way that is most appropriate depending on where it is most critical.
At some point, and along the way, we will get the different parts combined and fitted to interact with each other so the system will function with all the parts in play.
References
[1] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson11.dir/Lesson.html
References
[1] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson11.dir/Lesson.html
 
Ingen kommentarer:
Send en kommentar