Desired flight mode control flow

Mavlink receiver

     By July 21th, roscopter could send only mavlink message #76 to PX4. Few days after July 21, the reason of failing to send other mavlink messages was found. The problem was that there are no handle functions for other mavlink messages in current PX4 firmware version. In mavlink_reciever app as shown above, only mavlink message #76, #100, #11, #104, #61, #109, #69, #0, #66 and #131 handle functions were implemented.

Mavlink message #32 was implemented successfully, and it was displayed in QGC 

      QGC shows that local position data (right window from roscopter) were successfully sent to PX4 (shows in QGC on the left window).

   As a result, to enable the communication between ROS and PX4, subscriber functions of missing mavlink messages need to be implemented in roscopter node, and handle functions and topics of missing mavlink messages need to be implemented in mavlink_receiver app. In other words, PX4 firmware was hacked to enable the communication.

 
Desired flight mode control flow

   After the communication problem between roscopter and PX4 was solved, further firmware hacking was planned for modifying the original PX4 flight mode control to achieve automated landing.

     The diagram below shows the desired flight mode control:

     Originally, POSCTL (position control mode) and MANUAL (manual mode) are two separated modes, and they needed to be switched by a controller into each other.

    In the desired control, the switching between POSCTL and MANUAL would become autonomous. In other words, as soon as the camera detect the landing pattern, MANUAL would be switched into POSCTL, and the quadcopter hovers autonomously above the landing pattern in POSCTL.

    In this flow, mavlink message #32 was used to send the local position (x, y, z, yaw) from roscopter to PX4. Receiving #32 indicates the camera detects the landing pattern, so #32 is the key data to switch PX4 into POSCTL.


Position control diagram

     To implement the desired flight mode control , a clear diagram of the original position control flow software chain was made. The current version (v1.0) of diagram is shown below:

      This diagram indicates that mc_pos_control app is the beginning of the control software chain, and it subscribe the topic, vehicle_local_position, which is from position_estimator_inav app, is correspond to mavlink massega #32.

     As a result, position_estimator_inav should be disabled publishing vehicle_local_position, and local position from #32 (from camera) should be published to vehicle_local_position instead in POSCTL. Also, modifications should be done for autonomous switching from MANUAL to POSCTL, and it will be discussed in following posts.