I wanted to analyze some data from a tlog file and figured that Excel would be the most flexible way so I created a little utility to extract the data I was interested in and save it as a comma separated value (CSV) file. Each selected parameter is in a separate column, and Excel can open the csv directly.
Note that it can't open the tlog file directly. You must use the Mission Planner to convert it to txt format. so:
1. From the APM Mission Planner Flight Data page select "Telemetry Logs", then "Tlog > Kml or Graph", then "Convert to Text".
2. Select the tlog file you are interested in, and the Mission Planner will create a txt file in its log folder.
3. Open the txt file in this program and it will parse the file and list the available parameters in the left tree control. Double click on the parameters you are interested in and they will be selected and displayed in the right tree control. If you want to remove a parameter from the selected list, double click it.
4."Save As" and provide an output file name. This will produce the csv file that you can open in Excel and plot as desired. The file will look like this, where each row was produced from one packet in the input file that contained at least one of the selected parameters.
If you want to re-use the list of parameters you can save and re-load them from the "configure" menu. These are simple text files you can edit directly if you like.
I am not familiar with the deloyment process for C# programs, so I have placed the entire project folder here.
Comments
Thanks, I would have not been able to find out that information on my own.
I keep on documenting.
More doubts:
1. mavlink_attitude_t.yaw, as it is in rad, should I assume that the 0 is pointing E and goes counterclokwise?
2. mavlink_vfr_hud_t : have not been able to find any definition. There es a field mavlink_vfr_hud_t.heading, what's the relationship to mavlink_global_position_int_t.hdg, which is also a heading?
Is there any place where I can upload the table, so that people can see it, use it and correct it?
Agus
Check GCS_Mavlink.pde for the data that is being transferred:
The mavlink_gps_raw_int has, amongst other data, the position direct from the GPS.
static void NOINLINE send_gps_raw(mavlink_channel_t chan)
{
uint8_t fix = g_gps->status();
if (fix == GPS::GPS_OK) {
fix = 3;
}
mavlink_msg_gps_raw_int_send(
chan,
g_gps->last_fix_time*(uint64_t)1000,
fix,
g_gps->latitude, // in 1E7 degrees
g_gps->longitude, // in 1E7 degrees
g_gps->altitude * 10, // in mm
g_gps->hdop,
65535,
g_gps->ground_speed, // cm/s
g_gps->ground_course, // 1/100 degrees,
g_gps->num_sats);
}
The mavlink_global_position returns position from "current_loc" instead. That, in turn, comes from the ahrs code. There is a comment there that refers to dead reckoning although at present it just copies the gps data over as long as the gps has a fix. Someone must have an idea for adding dead reckoning at some point in the future. So, as long as the gps has a fix the two sets of data returned are equivalent for latitude/longitude, and return different sets of other parameters,
static void NOINLINE send_location(mavlink_channel_t chan)
{
uint32_t fix_time;
// if we have a GPS fix, take the time as the last fix time. That
// allows us to correctly calculate velocities and extrapolate
// positions.
// If we don't have a GPS fix then we are dead reckoning, and will
// use the current boot time as the fix time.
if (g_gps->status() == GPS::GPS_OK) {
fix_time = g_gps->last_fix_time;
} else {
fix_time = millis();
}
mavlink_msg_global_position_int_send(
chan,
fix_time,
current_loc.lat, // in 1E7 degrees
current_loc.lng, // in 1E7 degrees
g_gps->altitude * 10, // millimeters above sea level
(current_loc.alt-home.alt) * 10, // millimeters above ground
g_gps->velocity_north() * 100, // X speed cm/s (+ve North)
g_gps->velocity_east() * 100, // Y speed cm/s (+ve East)
g_gps->velocity_down() * -100, // Z speed cm/s (+ve up)
ahrs.yaw_sensor);
}
Andrew,
You forgot including the AM/PM field in your program, times are not in 24h format in the input txt files (unfortunately)
Actually, it would be better writing YYYY/MM/DD HH:MM:SS.xxx in 24h in your csv files.
Agus
I'm using arduplane, but I assume that for this purpose the variables are the same.
I'm finding most of the variables I need defined in
ArduCopter- 2.9.1/libraries/GCS_MAVLink/include/mavlink/v1.0/common/*.h
Some doubts persist, though. For example, what's the difference between:
mavlink_gps_raw_int_t
and
mavlink_global_position_int_t
?
Not sure I'll be able to make a table for all variables. Perhaps we put the table somewhere
and people can fill the meaning of a variable when they find out about it.
Agus
Agus,
You have two choices for getting the code. If all you want is to get the current version and don't need to keep it up to date, download Arducopter-2.9.1.zip from here. It has everything in 2.9.1. If you want to keep up to date then you can install a git client and clone the repository. Some info on that is here.
Andrew
ok, I'll try to contribute a table...
I understand I must check the mavlink_msg*.h files in
GCS_MAVLink/include/mavlink/v1.0/ardupilotmega and common
right?
http://svn.mikrokopter.de/listing.php?repname=Projects&path=%2F...
Agus
Agus,
That makes sense. I will have a look.
You need to download and look at the code. There are generally comments in the header files. So, in this case, the header file is mavlink_msg_sensor_offsets.h, and the parameters are as follows:
typedef struct __mavlink_sensor_offsets_t
{
float mag_declination; ///< magnetic declination (radians)
int32_t raw_press; ///< raw pressure from barometer
int32_t raw_temp; ///< raw temperature from barometer
float gyro_cal_x; ///< gyro X calibration
float gyro_cal_y; ///< gyro Y calibration
float gyro_cal_z; ///< gyro Z calibration
float accel_cal_x; ///< accel X calibration
float accel_cal_y; ///< accel Y calibration
float accel_cal_z; ///< accel Z calibration
int16_t mag_ofs_x; ///< magnetometer X offset
int16_t mag_ofs_y; ///< magnetometer Y offset
int16_t mag_ofs_z; ///< magnetometer Z offset
} mavlink_sensor_offsets_t
Unfortunately, no units specified, so back to the code again. The mavlink processing is generally handled by GCS_Mavlink.pde, and I found the following
// m/s/s
Vector3f accels;
accels.x = (float)packet.xacc / 1000.0;
accels.y = (float)packet.yacc / 1000.0;
accels.z = (float)packet.zacc / 1000.0;
It is the accels.x,y,z that end up in the mavlink packet, so units are m/s/s.
You can also find generic mavlink documentation here. Units are often mentioned, but in this case it is in "sensor's raw units" which doesn't help much.
Andrew
Is there any place where the actual definition of the parameters is documented? For example,
what's mavlink_sensor_offsets_t.accel_cal_z ?
Thanks
Andrew,
Would it be possible that in a new version the program will have a default output filename automatically set using
the prefix of the input filename + .csv? The user could always modify this filename, but
most often this default would be valid.
Also, when processing several files, what happens if you select "Save" instead of "Save As"? Do you
actually rewrite the previous output file? I guess so, but would like to confirm. In such a case, in order to avoid
accidental overwriting, perhaps yo could eliminate the Save option and just leave "Save as" (which you could
relabel as "Save and Run" (or add an additional Run button?)).
Agus
Well, at least we would decrease the error in a 50%. Also, newer gps models to be connected to the APM will be
able to transfer info at higher rates. Some of the current bluetooth gps units transmit at 10Hz right now. So having
the time as accurate as possible in the software makes a lot of sense.
Thanks for your efforts and please keep us posted on any news regarding this issue.
Agus
-
1
-
2
-
3
-
4
-
5
of 6 Next