Conclusions Recommendations MSD19
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.
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.
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 start of 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 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
Simulator