AutoRef Honors2019 timeline
AutoRef Honors 2019 - Timeline
Thought Process
- Research and selection of drone
- Control test + hover mode using flowdeck
- Decision on relative positioning system instead of absolute
- Thinking of implementation of rules
- reflection on midterm presentation
- Motion commands through python script
- Ball detection with python + opencv, tested using digital phone camera and wifi connection
- Test with 2 analog fpv cameras and radio transmission-> issues with image flicker due to noise made color-based ball detection unreliable
- Decision to use raspberry Pi with digital camera for image capture and processing and wifi connection to pc runnning bitcraze client
- Drone upscale: issues with ESCs and controller tuning
- Transfer to Coppeliasim due to quarantine: Drone control + ball and line detection implemented and tested in real game scenario & ROS
The project began with a brief research period of 2-3 weeks in which the team made a shortlist of possible drones which could be used for the project and evaluated the strengths and weaknesses of each model. The final decision was to purchase a Crazyflie 2.1 with several accessories; including a Flowdeck unit, a USB radio signal receiver, replacement batteries and spare parts in case the drone broke during testing.
As soon as the drone was delivered to the university the basic functions of the drone were tested. The drone did not require many installations on the PC and the addition of the Flowdeck was plug and play. With the Flowdeck connected to the bottom of the drone it was able to hover relatively steady at a fixed height with some minor lateral drift at the click of a button.
With the drone fully set up the next step was to decide how to program the drone in order to operate as a referee during a robot football game. It was decided to use a relative positioning system for the drone instead of an absolute one in order to make the system scalable to any size field. The goal was to make the drone detect the ball and maintain it within its field of view, since most of the interactions between robots during a game are likely to occur in the vicinity of the ball.
Once the goals for the project were set a presentation was given to Dr. van de Molengraft in which the team outlined the decisions made, the project goals, assumptions and future steps to take throughout the remainder of the year. Some of the feedback received includes [insert feedback from minutes].
The team was split into 2 main subgroups to increase efficiency. One group focused on developing a motion command script with which the drone could be controlled remotely by passing arguments through preset functions in python continuously while the drone was flying. The other group focused on developing a python script which could detect the ball based on color using the OpenCV cv2 library. While the code developed by the team was functional, a code was found online which gave the option to alter more parameters (Rosebrock, A, 2015). The previous code was abandoned and the team focused on implementing a mask around the previous position of the ball in order to reduce false positive detections. The final code was tested by capturing images with a digital smartphone camera and sending them to the PC running the code through Wi-Fi. The ball was always detected correctly as long as the images were clear.
The team decided to try capturing images with an analog FPV (First Person View) camera, as these are commonly used by drone owners to control their drones at a distance due to their low latencies, which is a characteristic that seemed desirable to make the drone referee react faster to ball movements. Additionally, the drone referee could be operated in areas with no Wi-Fi connection available. Two different analog cameras were tested yielding the same result: The latency was indeed very low. However, due to the radio transmission noise the image colors were very unstable and the flicker made the color-based ball detection too unreliable to make the use of analog cameras viable.
hardware
cf bolt flowdeck also pid tuning of bigquad somewhere
Q1
//
Q2
//
Q3
Q4
//