Revision as of 08:27, 28 March 2020

Internal Navigation

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.

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.

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.

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.

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

Visualizer and Simulator

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).

@@ Line 15: / Line 15: @@
 * 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 pitch has been determined using computer vision.
+* 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.
@@ Line 21: / Line 21: @@
 * 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.
+* 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.