From a great discussion group post by DroneRanger:
I have been working to implement a plugin for STK (Systems Tool Kit) for importing a flight log, recreating the flight, altering some sensor models to depict the camera and camera mode (i.e. field of view). I can pull the flight data in, overlay the captured video from the flight, compare with a "simulated" view of modeled sensor in the software, and do some pretty cool analysis with other tools in the software (reports/graphs, propagate GPS satellites and analyze and/or predict DOP values, calculate distances to other objects/ areas/ volumes.... the list goes on.
I also have been working to put in a RealTime capability so i can link up to my 3DR radio and monitor the flight of my IRIS+. You can see some demonstration of what i have working so far here:
Let me know what you think! I am still trying to wrap my head around the whole MAVLINK world, but i have made some progress! Thanks to a few folks on here who have given some guidance as well.
Comments
I am still working on putting some additional features on this plugin. I started to include some additional data from the flight logs so I could pull the data in and then sync things up, analyze multiple data sets, etc. Here is one really interesting thing I stumbled upon while testing some of my flight logs.
I had loaded two flight in to visualize them both. This was actually data from when both I and a friend were flying our IRIS+'s together. I thought it would be interesting to calculate ranges and angles between the two of them, but when I loaded in the RADIO data from the log file and graphed some of the values, I noticed the 'RxErrors' were basically zero until one point during the flight when they all of a sudden started to build up. You can see this in the graph. What happened at the time when the RxErrors started to grow? That is exactly when the second IRIS+ was turned on!
Anyway, I thought that was pretty interesting to see things like the RSSI, Noise, and other radio parameters during the flight, but I didnt expect to see the RxErrors start building after the 2nd drone was turned on and took off.
Fantastic!
It could be because of a number of things, but for that particular test, i had the camera fixed (no gimbal). So misalignment between the actual video and the 'simulated/expected' video is probably due to the video timing. I had to trim out the beginning and ending portions of the video file to try and match it up with the beginning and ending of the log file. So, that is a much more manual process than i would like and is not very accurate....more of an eyeball approximation of 'yup, that lines up about right'. If the gopro had GPS, and would save the data to the video file or had SMTP timing code i could line up with real world time in some way, then i could probably slice it up to be exactly starting and stopping to line up with the log file. That could be another feature i look into.
I am also going to be adding some additional analysis tools that could be used for pre-flight checks like GPS DOP prediction over an area, comm links between xmit/rcvr to look at expected link quality or maybe swap/test different antenna types (dipole vs cloverleaf vs skew planar etc. and different polarizations). These sort of things would be interesting to look at in the event you have the luxury of choosing between different antenna types/polarizations before flying in a particular area or where you know some other signals MIGHT be a potential interference. Then look at some link parameters visually like C/N or BER, something like this:
So, that shows using a simple dipole, pointed up at some angle and the C/N colored throughout a volume area where I might want to fly.
If there are other things anyone thinks might be useful, let me know!
Interesting development. It's curious how far off the attitude of the camera is from that estimated by the software. I assume this is because of poor stabilization of the gimbal? (ie: the software doesn't know how far off the camera really is).