Conclusions Recommendations MSD19: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
 
(12 intermediate revisions by 2 users not shown)
Line 6: Line 6:
__TOC__
__TOC__


=Conclusion=
=Conclusions=
The project was not completed to the expected state because of the coronavirus outbreak. We were able to get most of the subsystems working, but we had to stop before everything was fully integrated and tested. As experienced with previous groups, the drone hardware proved to be temperamental, and fire-fighting small technicalities related to this took up large chunks of the time. There were also unavoidable project bottlenecks resulting from setting up the drone that meant that many things could not be worked on in parallel. For the future, it is advised to invest in more Crazy Flie hardware as this will allow more scope for working in parallel, and it is often the case that things break on the drone because it often crashes. Purchasing the replacement equipment during the project can significantly impact the project plan, and it is our experience that replacement parts will indeed most likely be needed.  
* The project was not completed to the expected state because of the coronavirus outbreak.


Initial steps on the computer vision aspects of the project have been undertaken, and the ball position relative to the pitch has been determined. More effort should be focused on the computer vision to realize the main aim of autonomously refereeing the game of football, as it will mean that many of the issues relating to drone hardware and controls would most likely be unnecessary anyway. In retrospect, a more precise scope is also needed. While the suggested strategy of a flying drone is fine for a robot game inside a drone cage, for an outdoor game between humans, a more powerful drone would be required to overcome adverse weather conditions. It would not be safe to have this drone near the players or the crowd. Notwithstanding safety, it would also distract the players. This would heavily restrict options for drone movement. For the indoor pitch at TU/e specifically, the football pitch is small enough that a single static camera from a mobile phone can pick up most of the events on the field with little latency. It is estimated that a combination of at least 4 cameras would provide full coverage, certainly good enough for an external referee to base a decision on for the vast majority of cases. People tend to carry mobile phones around with them anyway, so the improved cost efficiency is also a moot point.
* We were able to get most of the subsystems working, but we had to stop before everything was fully integrated and tested.
'''Crazyflie'''
 
'''Simulator'''
* As experienced with previous groups, the drone hardware proved to be temperamental, and fire-fighting small technicalities related to this took up large chunks of the time.
'''Perception'''
 
* There were also unavoidable project bottlenecks resulting from setting up the drone that meant that many things could not be worked on in parallel.
 
* The ball position relative to the field has been determined using computer vision.
 
* While the suggested strategy of a flying drone is fine for a robot game inside a drone cage, for an outdoor game between humans, a more powerful drone would be required to overcome adverse weather conditions. It would not be safe to have this drone near the players or the crowd.
 
* Notwithstanding safety, it would also distract the players. This would heavily restrict options for drone movement.
 
* For the indoor field at TU/e specifically, the football field is small enough that a single static camera from a mobile phone can pick up most of the events on the field with little latency.
 
* People tend to carry mobile phones around with them anyway, so the improved cost efficiency is also a moot point.


=Recommendations=
=Recommendations=
'''Crazyflie'''
* For the future, it is advised to invest in more Crazyflie hardware as this will allow more scope for working in parallel, and it is often the case that things break on the drone because it often crashes.
 
* More effort should be focused on the computer vision to realize the main aim of autonomously refereeing the game of football, as it will mean that many of the issues relating to drone hardware and controls would most likely be unnecessary anyway.


'''Simulator'''
* In retrospect, a more precise scope is also needed.


'''Perception'''
* It is estimated that a combination of at least 4 cameras would provide full coverage, certainly good enough for an external referee to base a decision on for the vast majority of cases.


=Points to consider=
=Points to consider=
Line 31: Line 44:
* LPS and Flowdeck together when used especially with TWR mode the Loco deck crashes after a while. The issue also raised in [https://forum.bitcraze.io/viewtopic.php?t=3150 ticket] and [https://forum.bitcraze.io/viewtopic.php?t=3836 another]. If encountered, [https://github.com/bitcraze/crazyflie-firmware/issues/368 re-flash the drone].
* LPS and Flowdeck together when used especially with TWR mode the Loco deck crashes after a while. The issue also raised in [https://forum.bitcraze.io/viewtopic.php?t=3150 ticket] and [https://forum.bitcraze.io/viewtopic.php?t=3836 another]. If encountered, [https://github.com/bitcraze/crazyflie-firmware/issues/368 re-flash the drone].


* While testing it has sometimes been observed that beacons on ground level do not communicate with Client at start of connection. A [https://forum.bitcraze.io/viewtopic.php?f=16&t=4215 ticket] has been opened concluding some alternative solutions in the forum.  
* While testing it has sometimes been observed that beacons on ground level do not communicate with Client at the start of the connection. A [https://forum.bitcraze.io/viewtopic.php?f=16&t=4215 ticket] has been opened concluding some alternative solutions in the forum.  


* Some parameter setting could be changed to test in the CF Firmware in cases which EKF is getting confused with conflicting data from flow and the LPS at the same time. Things to try could be to increase the standard deviation: [https://github.com/bitcraze/crazyflie-firmware/blob/0c26532/src/deck/drivers/src/flowdeck_v1v2.c#L94-L95 For Flow sensor], [https://github.com/bitcraze/crazyflie-firmware/blob/866903e/src/deck/drivers/src/zranger2.c#L47-L50 For Range sensor], [https://github.com/bitcraze/crazyflie-firmware/blob/2019.09/src/deck/drivers/src/lpsTwrTag.c#L260 For UWB data parameter]
* Some parameter setting could be changed to test in the CF Firmware in cases which EKF is getting confused with conflicting data from the flow and the LPS at the same time. Things to try could be to increase the standard deviation: [https://github.com/bitcraze/crazyflie-firmware/blob/0c26532/src/deck/drivers/src/flowdeck_v1v2.c#L94-L95 For Flow sensor], [https://github.com/bitcraze/crazyflie-firmware/blob/866903e/src/deck/drivers/src/zranger2.c#L47-L50 For Range sensor], [https://github.com/bitcraze/crazyflie-firmware/blob/2019.09/src/deck/drivers/src/lpsTwrTag.c#L260 For UWB data parameter]


'''Perception'''
'''Visualizer and Simulator'''
* Visualizer and Simulator only works with Ubuntu 16.04.


'''Simulator'''
* Simulator only works with Ubuntu 16.04.
* The username for the system on which Ubuntu is installed should be ¨robocup¨, or else later issues will pop up. Please all use the computer name as ¨devpc1¨ for purpose of consistency.
* While installing smartSVN, use the secure protocol i.e. https://robocup.wtb.tue.nl/svn/techunited, instead of http://robocup.wtb.tue.nl/svn/techunited when required. Else results in error.
* While installing smartSVN, use the secure protocol i.e. https://robocup.wtb.tue.nl/svn/techunited, instead of http://robocup.wtb.tue.nl/svn/techunited when required. Else results in error.
* In a terminal execute ¨sudo apt-get install libxml2-dev¨ before running make_all_install. Else MATLAB will give error relating to missing header file (libxml/tree.h).
* In a terminal execute ¨sudo apt-get install libxml2-dev¨ before running make_all_install. Else MATLAB will give error relating to missing header file (libxml/tree.h).
* Follow steps only till "make_all_install". After that run "build_sim_all".

Latest revision as of 08:03, 16 April 2020

Conclusions

  • The project was not completed to the expected state because of the coronavirus outbreak.
  • We were able to get most of the subsystems working, but we had to stop before everything was fully integrated and tested.
  • As experienced with previous groups, the drone hardware proved to be temperamental, and fire-fighting small technicalities related to this took up large chunks of the time.
  • There were also unavoidable project bottlenecks resulting from setting up the drone that meant that many things could not be worked on in parallel.
  • The ball position relative to the field has been determined using computer vision.
  • While the suggested strategy of a flying drone is fine for a robot game inside a drone cage, for an outdoor game between humans, a more powerful drone would be required to overcome adverse weather conditions. It would not be safe to have this drone near the players or the crowd.
  • Notwithstanding safety, it would also distract the players. This would heavily restrict options for drone movement.
  • For the indoor field at TU/e specifically, the football field is small enough that a single static camera from a mobile phone can pick up most of the events on the field with little latency.
  • People tend to carry mobile phones around with them anyway, so the improved cost efficiency is also a moot point.

Recommendations

  • For the future, it is advised to invest in more Crazyflie hardware as this will allow more scope for working in parallel, and it is often the case that things break on the drone because it often crashes.
  • More effort should be focused on the computer vision to realize the main aim of autonomously refereeing the game of football, as it will mean that many of the issues relating to drone hardware and controls would most likely be unnecessary anyway.
  • In retrospect, a more precise scope is also needed.
  • It is estimated that a combination of at least 4 cameras would provide full coverage, certainly good enough for an external referee to base a decision on for the vast majority of cases.

Points to consider

Crazyflie

  • It is vital to have sensors operating in proper environmental conditions. Such as non-reflective floor surface for (Flowdeck) laser ranger, textured surface for (Flowdeck) camera/ laser ranger, empty room for clear radio signalling to (LPS) UWBs.
  • For packaging purposes of the battery, Flowdeck and LPS deck it is better to use long pins such that proper power and signal distribution is supported. If not, the contact pins for mounting these devices becomes only marginally sufficient and at some points will not power the devices properly.
  • Stable flight can be achieved if at least 4 anchors are identified so to make sure there is sufficient coverage over the (Tech United) field it is best to use 8 anchors. With this set up there is a better chance that range data will be continuously pinged from the Crazyflie 2.0 deck and back.
  • LPS and Flowdeck together when used especially with TWR mode the Loco deck crashes after a while. The issue also raised in ticket and another. If encountered, re-flash the drone.
  • While testing it has sometimes been observed that beacons on ground level do not communicate with Client at the start of the connection. A ticket has been opened concluding some alternative solutions in the forum.
  • Some parameter setting could be changed to test in the CF Firmware in cases which EKF is getting confused with conflicting data from the flow and the LPS at the same time. Things to try could be to increase the standard deviation: For Flow sensor, For Range sensor, For UWB data parameter

Visualizer and Simulator

  • Visualizer and Simulator only works with Ubuntu 16.04.
  • In a terminal execute ¨sudo apt-get install libxml2-dev¨ before running make_all_install. Else MATLAB will give error relating to missing header file (libxml/tree.h).