Adding pdef.xml to firmware.diydrones.com

[Pat Hickey]

Hi Tridge,

I'm currently adding support for parameters to Mavelous using Kevin's generated pdef.xml file. It would be helpful if this file was published on firmware.diydrones.com in a versioned fashion similar to the firmware builds, so Mavelous (and other GCSs) can fetch the appropriate parameter definitions automatically.

Along those same lines, it would be nice for APM to report some sort of  version information in a mavlink message which could be matched to a firmware.diydrones.com pdef.xml file. I haven't given much thought about how to do this - it may already be possible - but maybe Kevin or others can share their scheme for matching pdef with firmware in their GCS.

Thanks,

Pat

[Pat Hickey]

Sounds fair - I agree its a secondary concern. I could see it becoming a problem if we ever did a significant refactoring of the existing parameters but for now I think it would be OK to always grab the latest pdef file from the web.

On Sun, Apr 7, 2013 at 12:11 PM, Kevin Hester <kev...@geeksville.com> wrote:

re: Kevin's scheme for matching pdef with vehicle version

Alas - I don't really have one ;-).  The pdef file contains docs for all libs and vehicle types and I use vehicle type (from the heartbeat) to select ArduPlane, ArduCopter, etc...  I count on the fact that removal of parameters is rare and the assignment of enum to int values don't change (they better not or all current GCSes would have pain ;-) ).  Of course if parms show up on a vehicle that I don't have in the pdef, the app copes - just no autodocs for the user.

It would be awesome to have a mavlink field or read only 'parameter' that contains the software version - if there isn't one already (I couldn't find one).  It would allow future proofing some behaviors and if nothing else we could have Flurry tell us the current installed fleet of all software versions (to figure out level of backward compatibility required etc...).