Insight of paparazzi architecture

From PaparazziUAV
Revision as of 04:01, 23 November 2012 by Koudshoorn (talk | contribs) (explanation about how we could use the paparazzi architecture for future additions)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

In an attempt to understand the connections of the different C files, we've made a few UML sequence diagrams to show what happens where. Note that these diagrams are only a part of the whole program.

Sequence diagram of the data acquisition in the Airborne

The First part of the diagram is the initialisation of the subsystems. This mostly consists out of setting all the fields to a startvalue. Names of certain files and methods with <...> in it, mean that there are different kinds. For instance, your data_subsystem could be gps and the type of gps nmea. This would lead to the use of gps_nmea.c and it's method gps_nmea_init(). data_subsystems are the subsystems that acquire data. Like: gps, gyroscope, barometer etc. filter_subsystems are the subsystems that use these data to estimate things like velocity and such. Examples are: ins, imu, ahrs. To create the diagram we looked at the gps and ins usage. Other subsytems might work a bit different, but the idea is about the same.

The second part shows the control loop of main.c. main.c continuously checks if the subsystems on events and sends a callback function with it, so that the subsystem can reply if an event occured. If an event occured, the subsystem would have parsed the data into a usefull format. This data will be acquired by the filter_subsystem by telling it to update or something similair. These updated estimations can then be used again in the navigation of the airborne (this is not shown).

Sequence diagram about the airborne actions when a message from datalink arrives

This second diagram is about what the airborne does when he receives a datalink message. Since actions differ a lot depending on the kind of message, we've used the message that tells the airborne to go to a new block (according to flightplan). In the first part is shown what the airborne does when no message is received: it continuously checks for messages. The second part is where the airborne receives a message of type DL_Block (note that this isn't exactly a function call, it's just there for clarity). Since there now is a message, <datalink_type>.h parses the message to a readable format for datalink.c and notifies datalink.h about it by setting dl_msg_available to true. datalink.c reads the message and makes sure the adequate actions are performed.

Future additions

Now that we know how the important parts of paparazzi work, we can add new features more easily. Since it's better to leave the architecture unchanged, we'd have to implement features in a similair way as they've been done so far. If, for example, we'd like to add a new sensor it should work like the other sensors: a subsystem that can see if there's new data from the sensor and parse it and perhaps a new subsystem to transform that data into something usefull.

In case we wanted to do something like indoor flight (this can be derived from the second diagram), we'd need to add a new flightplan block that can be send through data link, make sure the datalink.c can parse it and what method needs to be called from navigation. Lastly navigation.c needs a new method to be able to fly indoors.