Blogs

copterLoader - firmware uploader

Posted by geir on December 30, 2010 at 12:30am
3689383778?profile=original

This program downloads precompiled firmware for the arducopter and automatically uploads it to APM. No need to install arduino, libraries etc.

Hopefully this program will make it easier for those of you who fly the arducopter, but don’t have an interest in programming. Using this program you don’t have to install arduino and build the code yourself.

Right now I only uploaded one version (version RC02) of the code. This is the one I'm flying. Nothing extra (gps, mag +++). If people like it I will upload more. And the user can chose witch one to download right in the software.

Remember this is the alpha version, so there might be some bugs. Please give me feedback (bugs or suggestions)

 

You can downloade it at http://geir111.blogspot.com

Tags: apm, arducopter, firmware, program, upload
E-mail me when people leave their comments –
Follow

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

Join diydrones

Comments

  • Developer
    Michael Smith January 6, 2011 at 11:35am
    @HK I think the momentum right now is all towards MAVLink.
  • Developer
    Michael Smith January 6, 2011 at 11:35am
    Don't worry about implementing a compiler in your uploader; that's what the Arduino IDE is...
  • geir January 6, 2011 at 4:35am

    Ok for the next version I'll go for hex uploading. If the auto detect stuff doesn’t work out, and we need a lot off hex files. I’ll look in to implementing a compiler. It should not be a problem to do this.

  • Paul Mather January 5, 2011 at 12:38pm

    But what are the arudcopter people planning on using? The Labview GCS ONLY works with AP legacy. Qgroundcontrol ONLY works with MAVlink. My GCS works with both, but MAVlink is far more complete than AP legacy and APM binary. So my vote would be MAVlink....but that's going to essentially obsolete the Labview GCS.

  • Developer
    Michael Smith January 5, 2011 at 11:49am

    The GPS protocol decoders are all very small, so it's less of a hit than it might seem.

    Also, I just realised that GPS_PROTOCOL_AUTO probably isn't going to work with the code as it stands right now - if you want to tinker, use the example program.

    We would probably only want one GCS protocol built in; those are, as you rightly note, somewhat on the bulky side.

  • Paul Mather January 5, 2011 at 11:46am
    I'm not sure how the libraries effect things...but with the "old" AP source, there were a bunch of compiler #If statements that would include or not include source based on variables in the defines file. So if MediaTek, uBlox, SiRF and NMEA are all going to be included isn't that 4 times the GPS code in the compiled source? Same with APM binary, MAVlink and AP legacy for GCS? I didn't think we had enough room in the code to include everything and have EEPROM variables to select what gets used. I'd love it if we could but I didn't think that was an option.
  • Developer
    Michael Smith January 5, 2011 at 11:36am

    @Paul I actually have both protocol and baudrate auto-sensing done.  You can configure GPS_PROTOCOL_AUTO and give it a try.  I've had it goof up once talking to the 1.6 MTK firmware and wind up talking NMEA, but I've never been able to reproduce.  Any thoughts you have on the strategy or risks would be greatly appreciated.

     

  • Paul Mather January 5, 2011 at 11:34am
    Jani, are you sure? I believe auto sensing is for baud rate, not for which protocol it's using...or at least that's what I though Mike was working on....
  • Developer
    Jani Hirvinen January 5, 2011 at 6:11am

    Happy, we are also working to get auto sensing working on APM code. GPS auto sensing works already. We can also sense presence of magnetometers and even xbees. So properly configured HEX file will work 70-80% of the users. And users who have something special connected, can also compile their own codes.

     

    But let's see how it goes after all auto sensing features are working ...

  • Paul Mather January 5, 2011 at 5:35am
    But again, this solution will only work if everyone has the same hardware. If one user has uBlox then they have one HEX file. If another user has SiRF that's a different hex file. If a user has MediaTek and a magnetometer, then that's another one. So for every option, it's exponential. GPS ^ Mag ^ GCS = LOTS of HEX files.
This reply was deleted.