Using my APM as a data logger for a dragster....

3689582141?profile=original

3689582268?profile=original

 

 

 

 

 

 I am using my APM 2.6 as a "smart" data logger for a vintage rail dragster which i am on the team for as their  "engineer".  I have some experience using the APM with RC planes and quadcopters and decided this would be a good way to get some velocity and acceleration data with the benefit of gps location thrown in.  it's nice to get IMU and GPS accel and velocity data both.  we used the device on 15Mar14 for the first time and i overwhelmed the log storage capacity of the APM so i am looking at ways to either increase that or reduce the number of parameters that are saved. 3689582295?profile=original

I would like to limit the parameters being save to what i need or be able to turn the logging on or off using the MAVLINK telemetry.  any suggestions would be greatly appreciated.

thanks

dennis

 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • I tried reducing the frecuquency but for some reason when I remove :

    if (g.log_bitmask != 0) {
    Log_Write_Data(DATA_AP_STATE, ap.value);
    }

    from arducopter.pde the whole thing crashes.

  • We did something similar recently building a data logger for aircraft.Have a look at http://diydrones.com/profiles/blogs/apm-as-a-flight-data-recorder

    In short, if you want to log data onboard for extended periods, get a Pixhawk. We also learned a few things thanks to input on the blog.

  • Dennis, I have zero experience with Arduplane so anything I suggest relates only to Arducopter ;) I am glad you got it sorted. How did you get around the auto disarm? The on board memory is 16Mb which in my books is not so tiny, but then when I first started programming, I had to fit everything into 3.5Kb.... For example, the IMU message in the log looks like it is 31bytes long including the header. If this was all you were storing then you should get around 3 hours worth at 50Hz (not withstanding the overhead of the FMT, PARM and other entries that written at the beginning of every log) I realise that there are other log entries that you are interested in too but as each run is less than 20sec (I hope!) I'm sure there should be no problem. You can always look at removing the unneeded items in each entry (eg you are probably only interested in acceleration in one axis and not the gyro data at all from the IMU entry) 

  • Developer

    @Dennis Okeefe I forgot to mention that DroidPlanner saves all  data that is received into the android device storage. You can review that data later with Mission Planner.

  • Developer

    @Dennis Okeefe 

    If you have an Android device at hand you don't have to buy nothing to try this out. Just plug the device into the APM, or via a telemetry link, and you should be good to run. Here is our latest release: http://diydrones.com/profiles/blogs/droidplanner-2-official-stable-...

  • james....

    well, i tried the "logs on when armed" approach and had some issues.  i had arduplane loaded and i could not arm - it seems like that isn't even available in that firmaware.  i had picked arduplane because i had used it more than arucopter and wanted to eventually add an air data system (pitot static) to the beast - adding that to a ardcopter doesn't make any sense so it doesn't seem to be an option for me to do that.  i switched the firmware load to a quad (arducopter) and the "logs on when armed" advice works perfectly.  i removed all the un-needed logs and only kept a few for my dragster logging effort.  i turned on attitude_high instead of attitude_med and the data rates when out of sight (not really a surprise).  10sps for a dragster is a little slow but 50sps is way more than i need so i am back at attitude_med.  i think i will drive this thing around for a few days getting a feel for how much "time" i can get on the tiny onboard memory available for logs and then decide what to do next.  on your comment about heading that actually is handy because after the dragster burnout it backs up to the start line and heading flips around and it's a nice way to tell that event is occuring.  i don't need a compass for that an will probably turn it off.

    aruthur....

    i have been looking at droidplanner and can't find any real documentation regarding what it saves in the way of telemetry and log data?  i probably am just looking in the wrong places so if you know where i could get smarter before buying that stuff i would appreciate the guidance.  i would REALLY rather use a small android device instead of the huge groundstation i use to support flights of the airplanes and quads.   all i really want to see during the racing event is that i am capturing data to analyze the next day.  i am thinking of setting up waypoints along the track at the timing lights an making a "mission" out of the run - i am not exactly sure what that will provide me but at least the autopilot will think it's doing something usefull and we want to keep them happy....  

    thank you both for supporting this bizarre application of the technology - i am trying to use a screwdriver to dig a hole instead of a shovel but in the end i WILL have a hole.

    dennis 

  • Developer

    You should consider have an on board GCS likeDroidPlanner, running on a android device. That will give you practically unlimited logging (restricted by the device storage), and a real-time display of the data.

  • i really appreciate your time in helping me get going.  i played with the code for a microwii for a while so i have some idea of what to expect when i dive into the programming side of this.  i did some programming during my career as a flight test engineer and enjoyed doing it - it's all very "logical" which most engineers adapt to very well given our wierd personnalities.

    thanks for telling me the first steps to get going....

    dennis

  • Hi Dennis,

    Interesting application of an APM!

    Following on from here: http://diydrones.com/xn/detail/705844:Comment:1593784

    External GPS should be fine however I can't imagine that the magnetometer will ever give any predictable results in this environment.... I'm not sure if the mag was something you wanted to use or if it just happened to be included. Surely on a drag strip you pretty much know what direction you are heading (well, hopefully!) I have used a pitot tube out of a car window to get some calibration information. I had to use a 2.5m carbon spar at arms length to get the tube out of the interference of the car.... Readings inside this distance tended to read too high as the air speeds up to passs around the vehicle. I imagine that the GPS would be the most reliable speed measurement. It will be interesting to see what the APM inertial nav makes of this situation...


    As far as the APM goes, Logging only occurs when the APM is in the 'ARMED' state. My copter gives me a separate file every time I arm. You say that you are "in a ground station" - do you have telemetry? You could arm the APM using your Tx just prior to launch (or use MP action if you have telemetry). Setting the throttle up a bit on your Tx should stop the APM from timing out and disarming. You would have to be careful of what happens if the car goes out of radio range and set appropriate failsafes. I imagine that interference is quite possible in this environment.

    As for modifying the code, you can start here: http://copter.ardupilot.com/wiki/developer-page/ If you are on a Windows machine, follow the instructions under the heading 'Building using the Arduino IDE'. Anyone can check out a copy of the code but as you "hoped and prayed" integrating changes with the main code is highly controlled. There is nothing stopping you from altering the code, compiling it, uploading it to your APM and using it yourself.

    I have had a quick look at the current code (3.2dev) and if you wanted to disable the auto disarm so that you could enable/disable logging from the Mission planner and not worry about the throttle on your Tx, I believe that commenting out line 108 in the motors.pde file: init_disarm_motors(); does the trick. I have attached a compiled version of this modified code if you want to test it before you manage to sort out compiling your own. Please note that a number of modules are disabled in order to fit the code into the APM (OPTFLOW, CLI, FENCE, SONAR). I have tested this code using a spare APM on my desk and it appears to do what you want. Please do not fly this code, I do not want to be responsible for any unforeseen consequences! You can upload the code using the 'Load custom firmware' option on the 'Install Firmware' page of Mission Planner. Please back up your settings first and don't forget to restore an official firmware version (and settings) before flying!

    PS, I see in another thread you were wanting to disable the crash detection for your upside testing rig. I have disabled it in this code by adding the following at the top of crash_check.pde:

    if (true) {
    inverted_count = 0;
    return;
    }

    Custom Firmware Downlaod: http://gdurl.com/OeEL/download

This reply was deleted.