Group 1:
Tim: The waypoints are pruned if they are unneeded, if we have uninteresting sections, our pruning function will combine it. We are also looking at the section size. If the size is too big, just going into the section is not enough. If it is too big, now have the lights do a loop around the section. If the number of lights exceed the lights randomly, if not, place them on the sections based on distance from collector. No current code to check if going to the section if beneficial (if there are no mosquitos). On small holes: Need to think about what the purpose is going through the hole, getting to mosquitos? or bringing mosquitos back? On placement of collector: If the lights arrive at the collector a lot before other lights, maybe the collector is not optimally.
Franklin: Have waypoints that are spaced out for the light to got to. The lights will go from the outside and then converge on the collector. Each of the lights move along their waypoints. The collector moves around based on the waypoints. The collector will be in the middle of the graph of the sections. Vishwa is working on the greedy behavior, if a light is already in a section, do not send another light there.
Vishwa <excused absence>
Group 2:
Jinesh:
Tieram: On Approach for small holes: we are ignoring it and also having problems with it. On sweeping: we are having the collector in the corner and have all the lights move towards the collector. Was concerned about the graphs doubling back on itself. Now, generating waypoints around edges, boxing around it to avoid loosing mosquitos. Second idea, how to handle areas in between. Are currently putting waypoints in between boxed in spaces from wall. Are only pruning nodes in wide open spaces, not around obstacles. Need to prune nodes at a corner. Thinking of pruning the waypoints around walls, or disconnect graph and use A* to get around them. Also having problems with small openings. Right now, putting nodes on each side and “hope for the best”. Thinking of adding a weight to make the lights go slower. Thinking of having a very sparse graph, where we will not get all mosquitos on the first path, or have a very comprehensive graph, and not go out. Our pruning strategy is not thinking about how big the light is. Need to adjust the nodes for line of sight from the light.
Di:
Group 3
Harjot: Have not done a lot of big improvements. Added preemptive stopping around the corners. The lights wait at the waypoints. The lights do not go to the targets that other lights are going to. The light are not placed very optimally, same code from the first week, Dividing the board into horizontal regions and places the lights in each section. The collector is placed on a modified minimum spanning tree using A*.
Tanveer: Satan takes a while to load since it is trying to find the best position for the collector based on the A* of all the walls. On Satan’s beard: When the mosquitos are too near the obstacles, the destination is the waypoint and not the mosquito itself
Hao:
Group 4
Sam: Collector is at the middle. It always is. If there is a wall, the program will try and place it as close to the middle as possible. The lights are placed on the corners. The lights are assigned to the sections they are assigned in the beginning, once done, it will go to the closest section. Had trouble getting around the walls, created a buffer and waiting. Now, the lights will pause when moving to get all the mosquitos to come. Problem with implementation is that there are too many sections. Will now, check if there are mosquitos within 5 from light. If not, then the section is marked as finished/claimed, if not, the light will go it it. Lights will abort early (stop sweeping) if it does not need to sweep section. The sweeping motion is predetermined based on the shape of the section. Might have been better if sweep was based on the locations of the mosquitos. Will have a hunter light to go out and get mosquitos that have been missed. The simulator is slow because of the buffer around the walls causing A* to be slow. The sweeping algorithm will start from the left and go down.
Patrick: The lights will pause after 30 movements, for about 5 rounds. This can be tweaked.
Hari: The lights only visit the collector once, after they have swept the sections to avoid duplicate work. The lights would get stuck in the sections because the sweeper was not handling very small sections well. Going forward, adjust the position of the collector.
Group 5
Marcus: Attempted to find the best way to get to through the board through minimum spanning tree. but the graph has too many leaves and is not as good as what we had before. Going to tweak the way to calculate the way to get the path between the nodes. Going to discard the graph, while keeping the the nodes.
Tanay: The collector is placed,
Lauren: Experimented with new approaches, but none were beneficial. Improved the efficiency of A*. Our lights firstly get most of the mosquitos, but then loose some getting back. The greedy is not very good, as it will take a while to get the last few mosquitos.
Group 6
Yigit: <not in class>
Yang: Did not change a lot about the algorithm, but changed the efficiency. Calculate the lie of sight between two points and hash the results. Looking at the small gaps and how the lights go through them. Go through the slightly larger gap, or the slightly smaller gap between the wall the the edge of the board. Determined that going next to the end of the board is the better option. In the cute drawing board, the opening is too small for the lights to see, so the area is invisible, and will only see the mosquitos in to once they leave. In placing the lights, always look at the positions farthest away from the collector
No comments:
Post a Comment