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

212 views
Skip to first unread message

Andrew Tridgell

unread,
Jun 23, 2015, 12:44:30 AM6/23/15
to Víctor Mayoral Vilches, Mikhail Avkhimenia, drones-...@googlegroups.com, mirkix
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

unread,
Jun 23, 2015, 4:55:34 AM6/23/15
to drones-...@googlegroups.com, mir...@gmail.com, vic...@erlerobot.com, and...@tridgell.net, mikhail.a...@emlid.com
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

unread,
Jun 23, 2015, 12:02:57 PM6/23/15
to and...@tridgell.net, drones-...@googlegroups.com
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

unread,
Jun 23, 2015, 4:36:08 PM6/23/15
to drones-...@googlegroups.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

unread,
Jun 24, 2015, 8:45:40 AM6/24/15
to drones-...@googlegroups.com
That's great Tridge, thanks!

Víctor MV

unread,
Jun 24, 2015, 8:54:29 AM6/24/15
to drones-...@googlegroups.com
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

unread,
Jun 24, 2015, 9:01:19 AM6/24/15
to Víctor MV, drones-...@googlegroups.com
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

unread,
Jun 24, 2015, 2:03:30 PM6/24/15
to drones-...@googlegroups.com, v.may...@gmail.com, and...@tridgell.net
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

unread,
Jun 24, 2015, 7:44:21 PM6/24/15
to Víctor MV, drones-...@googlegroups.com, v.may...@gmail.com
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
Reply all
Reply to author
Forward
0 new messages