Running Files MSD16: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
{{:Content_MSD16_small}} | <div STYLE="float: left; width:80%"> | ||
</div><div style="width: 35%; float: right;"><center>{{:Content_MSD16_small}}</center></div> | |||
__TOC__ | |||
= Risk Analysis = | = Risk Analysis = |
Latest revision as of 10:24, 14 March 2017
Risk Analysis
Line Referee: TURTLE vs Omnibot
The first idea was to use a TURTLE robot as a line referee while two Omnibots would be playing on the field. However, the communication with the TURTLE seems to be a difficult task which is not yet achieved. Also, there are only two Omnibots currently present to test with and we are not the only team who want to use them. Now a choice needs to be made whether it would be better to switch the role of the different robots: two TURTLEs as players and one Omnibot as a line referee. The switching should be possible due to our implementation of the System Architecture. To make a decision about this, this risk analysis is made.
Choice 1: TURTLE as line-referee and Omnibots as players
pros:
- this was the first idea for the project
- the TURTLEs already possess algorithms to detect a ball and players
- the TURTLEs already are able to locate themselves
- TURTLE has a large field of view
cons:
- the communication with the TURTLEs is still not working
- if the comm is working, we should still adapt the code to use our set-points
- in order to use comm we need at least one laptop with Ubuntu and run everything on there or link it to the base laptop
- the TURTLEs are quite big, maybe too big to drive next to the field
Choice 2: TURTLE as player and Omnibots as line-referee
pros:
- comm with Omnibot is already working (arrows to control the bots)
- we only need one Omnibot to test with
- we don't necessarily need to equip the Omnibots with any protective gear
- TURTLEs are already programmed and designed as players
cons:
- still not able to receive data from the Omnibot (but also not with TURTLE)
- we need to develop localization for the Omnibots, possibly there is some software to do this based on LED strips (it was indicated by TV that this is quite a challenging and time-consuming task)
- Kalman filtering: identification of model and implementation on the bot. (SW is still working to implement this on the Drone)
- implement ball and object detection on the Omnibot (but approach is already made)
- field of view is probably limited and much lesser when compared with the Turtle's FoV.
- change control algorithm for the Omnibot
Conclusions and Recommendations
Based on the implications of the above two choices, some recommendations or a Choice #3 can be made.
Completing the demonstration with the fully autonomous drone
- System integration should be completed for this.
- Since the UWBS system shall be installed by the time this project is continued next year, localization of refereeing agents shall be easier, compared to the current situation which uses the Top Camera. Currently, due the complexity of the image processing (Cons #2 in Choice #2), having fully autonomous multi-0agent referee system can not be guaranteed.
- Later on, if two refereeing agents are used, to extend the field-of-view of the (preferred) Omnibot, a Kinect could be attached on top of it and thus allowing it to have a FoV comparable to the TechUnited Turtle.
Player robots breaking while bumping
When player with the player robots they might bump into each other. This can damage the robots, for instance the omniwheels which are sticking out of the body. To overcome this problem we need to make a cover for the robots.
Simple cardboard box
We could put a cardboard box over the robots and paint this black.
Pros:
- Simple
- Fast
Cons:
- Can break easily
- Does not look nice
- Image processing issues
Make more fancy cover
We could make a more fancy cover for the robots
Pros:
- Make it as we want it to be
- Make it robust
- Design right shape for image processing
Cons:
- Time consuming