Proposal 3: Developmentally Learning the Support Affordance of a Platform The proposal should be consider for the Best Proposal Prize. On a scale of 1 to 10 for clarity the proposal rates a 9. On a scale of 1 to 10 the actual project idea rates a 9. Overall, is the proposal clear, concise, and well-organized? The proposal appears to be clear, concise, and well orgainized. Most of the sections seem to flow into one another really well. Some nits that might help it to look at little better or perhaps be a little clear. Justifying the text would help to fill the space and not make it look so ragged at the end of lines. It might be useful to go into more detail about the Software Libaries you are using and why they were selected over other choices. Some of the figures seems relatively large for the amount of value they provide. This gives the feel that their primary purpose is to take up space and not provide additional information. The proposal might be better served having the Team Qualifications earlier in document. Does the proposal meet the posted proposal guidelines? The proposal appears to meet the posted guidlines. If anything could be considered missing it would be a more detailed experimental setup. It would be useful to have diagrams of how testing would be complete and more detailed description of how the team plans to do cross-validation. How does the project idea fit within the framework of Developmental Robotics? The project seems to fit relatively well into the framework of Developemental Robotics. There is definiltey a lot of value in having a robot that is capable of learning the support affordance of objects of various objects. The proposed research is definitely a good start towards definining the necessary behaviors. Describe what you like BEST about the project idea. The best liked aspect of the project idea is the learning of object support affordances. The idea of having robots that are capable of learning the support characteristics of an object is just frankly really cool. Describe what you like LEAST about the project idea. The lease liked aspect of the project idea is the ramp and the limiting it to the platform. It feels like the whole purpose of the ramp is get around a limitation with the method that has been chosen to track the objects. The orignial presentation for the project dealt with stacking objects on top of one another and the platform is obviously a simplifcation of the much more difficult problem. While it easy to understand why the simplification is necessaru given the time constraints of the projects the stacking seems like it would be the more fun problem. Do you have any concerns about the project? The main area of concern with this project are the use of the Robot and OpenCV. It does not appear as any of the team members have prior experience with either which could prove problematic. This is only a mild concern since with multiple team members each one can focus on learning a different new technology and there appears to be enough prior programing experience within the group to make it feasible that they can pick it up fast enough to complete the project. Does it seem doable in the remaining time? The project timeline is definitely going to be tight, though it should be doable in at least part in the remaining amount of time. While they did not explicitly plain for a phased developement that would allow them to stop early if necessary they do have the option of only implementing one or two of the learning algorithms mentioned in stage 3. It should be pointed out that this is just one of many project that are planning to use the robot, so it is possible they might find themselve fighting over a scarse resource. Does it seem too difficult? The project seems to have about the right amount of complexity to it. The team is definitely in for some challenge with having to learn both how to to use the Robot and OpenCV, but they appear to have the right mix of skills to make it possible. The experimental setup itself is quite simple and should pose limited to difficulty in putting it together. Are there any major details left out? The proposal does not appear to cover the starting position of the object before being pushed. Will it always be placed in the center of the platform or is it going to more random. If not random how does the group propose to ensure that it is always placed in the same place. The proposal does not appear to denote how long the robot will push for. Does it stop pushing at the edge of the platform or does it keep going? If it keeps going what guards are being considered to ensure that the velocities of the object and the hand diverge once it is on the ramp? Further is the velocity such that it is guaranteed that if the hand stops before the end of the ramp the object will stop as well? The proposal does not seem to cover any potential error cases. What happens if the object become detached from the hand as it being pushed or what happens if the object stops on the ramp rather than sliding down it? Does the idea rely upon technologies that are not currently available? The proposal seems reasonable and utilizes technology that is available today though some of it is definitely not available to the average person. The proposed software libraries are readily available on the web and therefore easily obtained. The robot while not readily available, is something that is reasonable for a student taking developmental robotics to expect to have at least limited access. It is worth pointing out again that many teams are planning to the use the robot and therefore the teams may find themselves fighting over a scarse resource. Do you have any suggestions for improvement? Addressing the issues identified above would go along way towards improving an already really good proposal. Do you have any suggestions for related work that should be cited? It might be worth mentioning the paper "The learning and use of traverability affordance using range image on a mobile robot" that was written by Emre Ugur et. al. at the Middle East Technical University. It looks at shapes affordances relative to traversabilty which one would think might have a lot of parallels to supporability. An object that is easily moved is probably not a good support object (e.g. A Cylinder laying on its side). Any other comments or suggestions? Two pearls of wisdow: Plan to use the robot early. If the team is sticking to their timeline this should already be the case. Its better to have a working system that implements most of the functionality than a non working that almost implements all the functionality. It might be worthwhile to run one of the machine algorithms to ground and then come back and finish the other two so as ensure that you have at least some results when it comes time for the final report.