This web app allows you to easily estimate the parameter of a quadrotor based on just short flight data. You need to provide the easy to measure parameters: mass, rotor-positions (FLU frame!), rotor thrust directions (usually all in z direction: [0, 0, 1]) and rotor torque directions (usualy +-[0, 0, 1] depending on the direction of the propeller).

You just need to perform some flights to excite the linear acceleration dynamics (up and down accelerations) and the angular acceleration dyanmics (roll/pitch accelerations and yaw accelerations). Note that only the accelerations are important so these maneuvers can be more or less executed in place (in particular the angular acceleration ones).

For exciting maximum linear accelerations in constraint spaces we recommend to go high, then let it accumulate downwards velocity and then go for the maximum throttle that the space allows. Be careful because it can be easy to underestimate the fact that you can not accelerate downwards faster than gravity. If you have too much upward velocity you might hit the ceiling, even with zero throttle. You can see some example maneuvers in the following video: Note that currently only the PX4 ULog format is supported. To collect the log data the uORB topics vehicle_acceleration, vehicle_angular_velocity and actuator_motors should be logged at high rates. For that please configure the high-rate and system identification topics using the SDLOG_PROFILE PX4 parameter (cf. PX4 Parameter Reference).

Note that currently (as of v1.14) the vehicle_acceleration can not be configured to be logged at a high rate just by setting parameters. To accomplish this you can add it to the system identification topics as shown in this commit and then build PX4 from source. If you can not do the latter you can enable the default logging parameters (which log vehicle_acceleration at 50 Hz). This system identification method should be able to compensate for to some degree for the low frequency of the acceleration observations because it can use interpolation.

After collecting the logs you can select them in the following selection step. Note that all processing is done in your browser, no data is uploaded to any server (in fact this page is statically hosted at github.io). After selecting the files and specifying the model you should be able to pick the time ranges for the thrust curve estimation. The selector will present you all the log files and you should select the parts where you excited the linear acceleration dynamics.

You can use the shown motor outputs and also the excitation metrics (Thrust, Torque Roll/Pitch and Torque Yaw) to help you select the right timeframes. After confirming the selection, you can start the motor model estimation. Here you can select the exponents (zeroth-, first- and second-order) for the thrust curve estimation as well as the range for the MAP estimate of the time constant and the resolution/number of steps. If your linear acceleration data covers the full range from zero to full throttle you should be able to fit a good thrust curve using all three components. Sometimes, if the data does not cover e.g. the low thrust regime well, it can make sense to only fit the second order component (or first and second order). This effectively places a prior at f(0) = 0 to make up for the lack of data. After confirming the setup, the motor time constant is estimated and then the thrust curve parameters are presented.

Once you have estimate the motor model you can pick the timeframes where you excited the angular dynamics (roll/pitch) and it will use the motor model and the selected data to estimate the roll and pitch inertia as well as extrapolate the yaw intertia.

In the same manner you can select the timeframes where you excited the yaw dynamics and estimate the torque coefficient of the motors which is based on all the other estimated values. The dependencies are shown in the following, using the same color convention as in the paper: