Conclusions Recommendations MSD16: Difference between revisions
(Created page with '<div STYLE="float: left; width:80%"> </div><div style="width: 35%; float: right;"><center>{{:Content_MSD16_small}}</center></div> __TOC__ = Conclusions = = Recommendations =') |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 4: | Line 4: | ||
= Conclusions = | = Conclusions = | ||
In this section, the conclusions from different aspects are drawn and listed. | |||
'''Generic architecture''' | |||
In this project, a generic architecture is designed based on the given project objects. The generic | |||
architecture is not effected by what hardware to be chosen. How system works is described layer by | |||
layer with the gradient of detail level. The implementation of project is also visible for designer. | |||
''' Implemented in Simulink''' | |||
To prove the concept of the generic architecture, a prototype is built and integrated in Simulink. Every | |||
hardware components are connected and communicate with each other via the integration file in | |||
Simulink. | |||
''' Drone can follow ball''' | |||
Some skills are achieved via built prototype. The drone can follow the ball automatically by using the ball | |||
information from world model. Even when the ball is out of the field of view, the drone can still estimate | |||
the ball position with particle filter. | |||
= Recommendations = | = Recommendations = | ||
'''S-function based implementation''' | |||
Convert all coders into S – functions. As different components use different programming languages to | |||
communicate with controller, integrating all of them into Simulink increases the computing time and | |||
causes errors of compatibility. Hence, all coders are recommended to convert into S-Function if the | |||
integration is implemented in Simulink environment. | |||
'''Robust hardware''' | |||
The hardware used in prototype showed unreliable behavior which consumed a lot of time and slowed | |||
down the project progress. Hence, more robust hardware are required. Some recommendations | |||
respected to every hardware component are discussed and listed. | |||
*''Drone position system'' | |||
The drone position information is measured via the camera on the top of field. The camera | |||
captures the image of the field from top and the laptop will do image processing to estimate the | |||
coordinates of drone. However, the position information provided by image processing is not | |||
reliable all the time. Around 25% of the data shows empty. Also, the brightness of the room can | |||
influence the correctness of camera and even make it stop working. Therefore, an Ultra Width | |||
Band System (UWBS) is recommended to replace the camera. | |||
*''Parrot AR Drone'' | |||
The parrot AR Drone used in this project behaved unreliable, especially when the battery is low. | |||
A more powerful drone with Intel NUC is recommended to replace the AR drone. | |||
*''TechUnited Turtle as line referee'' | |||
The communication system of TechUnited Turtle works in Ubuntu operation system instead of | |||
windows, which makes the integration process complicated and inconvenient. Obviously, Turtle | |||
being line referee is not a wise choice. So, using a Omni-bot with a Kinect as line referee is | |||
recommended. | |||
Latest revision as of 08:00, 15 May 2017
Conclusions
In this section, the conclusions from different aspects are drawn and listed.
Generic architecture
In this project, a generic architecture is designed based on the given project objects. The generic
architecture is not effected by what hardware to be chosen. How system works is described layer by
layer with the gradient of detail level. The implementation of project is also visible for designer.
Implemented in Simulink
To prove the concept of the generic architecture, a prototype is built and integrated in Simulink. Every
hardware components are connected and communicate with each other via the integration file in
Simulink.
Drone can follow ball
Some skills are achieved via built prototype. The drone can follow the ball automatically by using the ball
information from world model. Even when the ball is out of the field of view, the drone can still estimate
the ball position with particle filter.
Recommendations
S-function based implementation
Convert all coders into S – functions. As different components use different programming languages to
communicate with controller, integrating all of them into Simulink increases the computing time and
causes errors of compatibility. Hence, all coders are recommended to convert into S-Function if the
integration is implemented in Simulink environment.
Robust hardware
The hardware used in prototype showed unreliable behavior which consumed a lot of time and slowed
down the project progress. Hence, more robust hardware are required. Some recommendations
respected to every hardware component are discussed and listed.
- Drone position system
The drone position information is measured via the camera on the top of field. The camera
captures the image of the field from top and the laptop will do image processing to estimate the
coordinates of drone. However, the position information provided by image processing is not
reliable all the time. Around 25% of the data shows empty. Also, the brightness of the room can
influence the correctness of camera and even make it stop working. Therefore, an Ultra Width
Band System (UWBS) is recommended to replace the camera.
- Parrot AR Drone
The parrot AR Drone used in this project behaved unreliable, especially when the battery is low.
A more powerful drone with Intel NUC is recommended to replace the AR drone.
- TechUnited Turtle as line referee
The communication system of TechUnited Turtle works in Ubuntu operation system instead of
windows, which makes the integration process complicated and inconvenient. Obviously, Turtle
being line referee is not a wise choice. So, using a Omni-bot with a Kinect as line referee is
recommended.