addition of NavIO and PXF builds to firmware.diydrones.com

[Andrew Tridgell]

Hi Victor and Mikhail,

On the dev call today we discussed the state of the Linux ports, and
decided to add the NavIO and PXF builds to the standard autobuild which
creates binaries on firmware.diydrones.com.

So you should be able to point your users there for the latest builds,
and new stable releases as they come out.

The build just kicked off, so the first builds should be available in an
hour or so.

We're hoping this will encourage more users to try the Linux ports.

Mirkix, I haven't added BBBMini builds as I expect that BBBMini users
are more likely to be happy to build their own binaries as they are more
likely to be real DIY users. I hope that is OK!

Eventually we'd like to have a single ArduPilot ARM package with a
config file for sensors, bus layout etc, but in the meantime this should
work.

Cheers, Tridge

[Daniel Frenzel]

Is it possible to make an update repository which contains *.deb or *.rpm files?

In case of linux with all the binaries in them?

Best

[Mikhail Avkhimenia]

Hi Andrew,

> On the dev call today we discussed the state of the Linux ports, and
> decided to add the NavIO and PXF builds to the standard autobuild which
> creates binaries on firmware.diydrones.com.

Thank you, that is very convenient. I'll update the download section in our docs.

23.06.2015, 07:44, "Andrew Tridgell" <and...@tridgell.net>:

[mir...@googlemail.com]

Hi Andrew,

for me it is ok. I already provide a full Debian 8 image with 4.0.4 RT PREEMPT Kernel and BBBMINI Device Tree. In the next release of the image there is a script included, that build the latest BBBMINI binaries for ArduPlane, ArduCopter and APMrover2 (for each: master, beta, stable). Maybe we can think about putting BBBMINI binaries to firmware.diydrones.com when the BBBMINI is getting more popular.  

Best regards
Mirko

[Víctor MV]

That's great Tridge, thanks!

[Víctor MV]

A minor concern,

We've been providing both Debian and Snappy Ubuntu Core images for a while. For the snappy ones we need the logs and terrain data to be placed in a different location. The reason is basically because of the way partitions are configured in the Snappy filesystem.

Tridge, would you be willing to accept a commit such as this one for the PXF?

[Andrew Tridgell]

Hi Víctor,

> Tridge, would you be willing to accept a commit such as this one

> <https://github.com/vmayoral/ardupilot/commit/42d510beea750e13138147189297ec93c44f0b77>
> for the PXF?

I think I'd prefer to add a command line option to set the log directory
and terrain directory.

so first switch this code:

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_HAL_Linux/HAL_Linux_Class.cpp#L131

to use this library:

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_HAL/utility/getopt_cpp.h

then add --log-directory and --terrain-directory command line
options. Add const methods on hal.util to get the directories.

That would get us a little step closer to proper runtime configuration.

Cheers, Tridge

[Víctor MV]

Hi Tridge,

I've made a branch with a few commits. HAL_Linux_Class.cpp makes now use of GetOptLong and the argument passed to GetOptLong is now stored in a member of the Util class. 

How would you like the Dataflash_File modified from here? I can't come up with a clean way of coding it.

Regards,

[Andrew Tridgell]

Hi Víctor,

> <https://github.com/erlerobot/ardupilot/commits/log-directory-change> with

> a few commits. HAL_Linux_Class.cpp makes now use of GetOptLong and the
> argument passed to GetOptLong is now stored in a member of the Util class

> <https://github.com/erlerobot/ardupilot/commit/397261615a0543c8d7a732ada589317ef9423152#diff-f927fb5712b09354f3b814b3629e2f0dR88>

Thanks! A few comments:

- I don't think we need a set_custom_log_directory() function, and we
don't need the private variables in the top level HAL class

- the get_custom_log_directory() should return a const char *, and
should default to { return NULL; }

- in the GetOptLong table calling it "uartA" would be better than
"uartADriver" as it is setting the device, not the driver

- we should remove the (char *) cast for set_device_path() and instead
fix UARTDriver.cpp to take a const char *. In general casting a const
char* to a char* is a bad idea.

- in _usage() it is better to have the options one per line, or it
becomes unreadable as it grows

- when processing the --log-directory and --terrain-directory options
just set the variable in private variables in the HAL_Linux class,
then implement the hal.util->get_custom_log_directory() function to
return that value (we want it this way as we don't want ports that
have no concept of command line options to pay any price for the
functions)

- in DataFlash_File.cpp we then use
hal.util->get_custom_log_directory() to get the directory. If it
returns NULL then we use the current default. Having a private const
char* variable in that class to hold the chosen directory may be
easiest.

Thanks!

Cheers, Tridge