Controllers, be it for quadrotors or industrial manipulators or any electromechanical system for that matter, are implemented as hierarchies. Controllers that directly drive the hardware are low-level controllers whereas those that implement logical decision-making are high-level controllers. The terms "high" and "low" are relative. Nested controllers ensure abstraction and code modularity.
In the context of a quadrotor, the controller for the motor driver(s) that actually makes the rotors spin would be a low-level controller, whereas another controller that tells the quadrotor to move forward/backward etc. could be a high-level controller. The low-level controller has abstracted away all the details on how exactly to drive the rotors. All the high-level controller does is instruct the low-level controllers that a particular action is desired. It's now the low-level controllers' job to actually spin the rotors in such a way that the quadrotor executes the desired action.
"in the platform of the robot it has to be present a low level
Think of making your quadrotor execute actions like
translate_forward(distance). Great, you've called those functions and have passed the arguments. What then? If the control architecture is implemented as a hierarchy, then these functions would call low-level controllers to actuate the rotors:
# high-level controller
# another high-level controller
# low-level controller
# code that actually drives the motors
Note that the low-level controller can again call another lower-level controller which is even closer to the "metal". Likewise, the high level controllers can be called by an even higher level controller, for eg.
go_above_obstacles() which utilizes
translate_forward(). High-level controllers thus are for high-level logic and are generally not concerned with the low-level mechatronic actuation.
Here's another answer that might be useful.