Running Files MSD16: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
No edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{:Content_MSD16_small}}
<div STYLE="float: left; width:80%">
__NOTOC__
</div><div style="width: 35%; float: right;"><center>{{:Content_MSD16_small}}</center></div>
__TOC__


= Risk Analysis =
= Risk Analysis =
Line 32: Line 33:
cons:
cons:
* still not able to receive data from the Omnibot (but also not with TURTLE)
* 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
* 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 bod.
* 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)
* implement ball and object detection on the Omnibot (but approach is already made)
* field of view is probably limited
* 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

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