Userbox --- What is it?

Moderator: shawnf

Post Reply
VAdroneflier
Ready for take off
Posts: 41
Joined: 15 Sep 2012, 23:58
Drone Type: AR.Drone 2

Userbox --- What is it?

Post by VAdroneflier » 21 Dec 2013, 21:24

Questions for the developer.
In the MyFiles/storage/sdcard0/ARDroneFlight/flights folder, there are "userbox_xxxxxxxxxx" files saved for each flight. After a while these files accumulate and take up appreciable storage space on the sdcard. What are these files? What is the basis of their numbering system which differs from the numbering system used for flight video files? Can these userbox files be deleted without affecting access to stored flight videos and/or "mesures" navigation data files?

Jayson Hanes
Spying is fun
Posts: 666
Joined: 23 May 2013, 14:42
Drone Type: AR.Drone 2
Location: Tampa, FL USA
Contact:

Re: Userbox --- What is it?

Post by Jayson Hanes » 22 Dec 2013, 04:20

They are basically log files of each flight. When you have the GPS installed the gps coordinates are among the many metrics stored in that file. There is a ruby program that was posted here that I use to pull out the gps data and make it useable as gpx data for google earth, etc. They are safe to delete. I'm willing to bet it's the data in these files that is uploaded to the Parrot Drone Academy to show flight altitude/speed, etc..

VAdroneflier
Ready for take off
Posts: 41
Joined: 15 Sep 2012, 23:58
Drone Type: AR.Drone 2

Re: Userbox --- What is it?

Post by VAdroneflier » 23 Dec 2013, 13:03

Thanks for your reply, Jayson. I take it then that userbox files (typically under 1 MB in size) must contain some sort of abridged version of the total set of navigation data that is recorded in mesures files (which are typically one or two orders of magnitude larger). Since access to the contents of userbox files is a bit involved and requires techniques and codes that are not within the knowledge and skill set of most ARDrone pilots (including me), I wonder whether I can prevail upon you to list the variables that are recorded in them? It would be helpful to know exactly what types of potentially useful information they contain before I delete them all from my phone's clogged-up memory.

Lately, I've been working with "mesures" files from a number of flights on different battery types in order to generate and compare Battery Voltage versus Time plots and Battery Level versus Time plots in hopes of gaining some insight into the Rapid Battery Drain Syndrome (RBDS) that so many ARDrone pilots have been complaining about. The voluminous "mesures" files record something like 248 fields (columns) of data that seem to cover every conceivable aspect of the drone's state of health, flight performance and navigation history during a given flight, with a new line of data being recorded at about 5 millisecond intervals from takeoff to landing. As pointed out by 3nslav3 elsewhere in this forum, the data in a mesures file can be accessed conveniently by importing the file into Microsoft Excel (or other spreadsheet program) as a semicolon-delimited text file. The graphing engine in Excel can then be used to generate any kind of plot that you like. As an example, I've attached a pair of voltage and battery level plots for a flight powered by a Hobby King Turnigy 1300 mAh 3S 11.1v 25-35C LiPo battery. Both plots exhibit evidence of the initial rapid decline in available battery capacity associated with the dreaded RBDS problem.

I suspect that the initial rapid drop in battery voltage is due to a rapid increase in the battery's internal resistance as current surges from zero to its full operating level and the battery's temperature rises to attain a steady state value where radiated heat equals heat generated. After that, the voltage versus time curve flattens out and voltage declines much more slowly as the stored energy in the battery is consumed. Eventually, battery voltage reaches the knee of the curve and will then decline very rapidly to dangerously low levels that would damage the battery if not avoided. Obviously, the pilot needs to know when he must land the vehicle not only to avoid battery damage but also to avoid the greater calamity and expense of crashing to the ground after total loss of power. :o

Undoubtedly, the mischief in the RBDS problem is in exactly how Parrot programmers have decided to translate measured Battery Voltage into the estimated Battery Level parameter on which they have apparently chosen to base their decisions to sound alarms, terminate flights and refuse takeoff commands. Whatever the method is, that translation must get increasingly unreliable and problematic as a given battery ages, its internal resistance rises, and its available energy storage capacity declines. It would be so much more simple and straightforward to base such decisions directly on measured Battery Voltage. :idea:
You do not have the required permissions to view the files attached to this post.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest