In the last few years an increasing demand in multicopter vehicle applications is taking place. Almost all of them involve autonomous trajectory following and collision avoidance as a security measure. Although commonly used flight controller software foresees sophisticated solutions to those problems, advanced implementations are still rare. In this bachelor project, carried out with Michael Rimondi, we elaborate those issues in a specific use case regarding a coverage flight for agricultural purposes. The currently used technologies are exploited to implement tracking of a general trajectory defined up to the first order derivative as well as a rudimentary collision avoidance approach, applied to the inner multicopter control loops. The higher level control is performed by an on-board companion computer and implemented in Robot Operating System (ROS), which opens up the possibility of modular extensions. The collision avoidance in contrast, is implemented directly in the Flight Control Unit (FCU) firmware to provide fast reactive evasion maneuvers. The achieved performances are evaluated and compared with simulation results.
Fawn in agriculture fields
As the featured image shows, in grassland surrounded by forests, it is a common problem, that wild animals hide in cultivated fields. The work with mowing machines then involuntary leads to thousands of fatalities. The project aims to tackle this issue by scanning agriculture fields with a thermal camera before the harvest. Interesting engineering questions have thereby been addressed, such as coverage path planning (CPP), trajectory following and obstacle avoidance. Michael then presented and elaborated the first, i.e. planning part of the project, while I was focusing on the control part. The joint bachelor presentation is attached below.
Trajectory generation
In the project the simplest approach of trajectory generation was implement, i.e. a constant velocity method. The geometric trajectory was simply sampled at equidistant points to then obtain a constant velocity trajectory.
Although a constant velocity trajectory is all but ideal for a quadcopter vehicle, we achieved reasonable tracking results using velocity feed forward control.
Collision avoidance
A low level rudimentary collision avoidance approach was implemented, directly in Pixhawk’s firmware.
Realizations and Tests
The project has started slowly with a custom build drone, frame design, components acquisition and assembly. In two intensive weeks, the major development took place, including all theoretical aspects, and implementation in C++ and ROS. The picture on the right might convey the spirit.
The most important lesson learned is perhaps to always ensure safety and have a fallback method: PID tuning on a custom build drone can be dangerous, making us GEO-fencing and having options such as Return to Launch (RTL) is crucial.
Documentation and source code
For the complete discussion and results please have a look at the bachelor thesis below.
The source code is publicly available on Github:
You are dividing the path into equidistant trajectory points and then you are publishing only the position of the trajectory points(m_pPositionTrajectoryENU). Then what is the purpose of setpoint.velocity? You are not sending it to the PX4, then why is this section ( taking a first order derivative to get velocity values) being used?
Thanks in advance
Hi Ramkumar,
thanks for your interest in this project and for the heads-up with the contact form – it should be working now. If I understood you well, the code you’re referring to is in trajectorygeneratornode.cpp:250 (https://github.com/BambiSaver/bambi/blob/71a8acbe724cdda40e1965a670783e2904ed333d/src/bambi/bambi/src/trajectory_generator/lib/trajectorygeneratornode.cpp#L250). Setting the velocity at that point actually changes the content of the mavros PositionTarget message, since it is a reference to the list entry. Therefore it should be properly send to the PX4 controller.
I remember that we got better results with the velocity feed-forward control mode in simulation, so it definitely had an impact on the control performance. Acceleration as a fast-forward control path was not supported at that time by PX4, so we limited our implementation to the first-order derivative.
Please let me know if this helps.
Best whishes,
Florian
Hi Florian,
Thanks for your reply. Below is my understanding. Correct me if I am wrong.
So when you say with and without velocity feed forward,
without velocity FF – sending only position setpoints to PX4 ( mavros_msgs/PositionTarget – geometry_msgs/Point position)
with velocity FF – sending both position and velocity setpoints to PX4 ( mavros_msgs/PositionTarget – geometry_msgs/Point position & geometry_msgs/Vector3 velocity)
Using velocity feed forward helps in reducing the deviation error and better trajectory following.
Yes exactly, this is the right intuition! Implementation-wise you also have to set the type_mask in the PositionTarget to the appropriate values, i.e. enable IGNORE_VELOCITY_VX and such, when you do not want to use the velocity targets. If not, it might happen that 0 velocity values are used as a desired velocity and will degrade tracking performance.
Cheers,
Florian