initial "experimental" boards

[dagar]

Here's the first easy step we can take for these experimental boards and setting expectations.

dagar@dagar-desktop:~/git/Firmware$ make emlid_navio2_experimental 
-- PX4 version: v1.11.0-beta1-346-gcf0964c040
-- PX4 config file: /home/dagar/git/Firmware/boards/emlid/navio2/experimental.cmake
CMake Warning at cmake/px4_add_board.cmake:176 (message):
  EMLID_NAVIO2 is experimental and not officially supported
Call Stack (most recent call first):
  boards/emlid/navio2/experimental.cmake:2 (px4_add_board)
  CMakeLists.txt:144 (include)


-- PX4 config: emlid_navio2_experimental
-- PX4 platform: posix
-- PX4 lockstep: disabled
-- cmake build type: RelWithDebInfo
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/lib/ccache/arm-linux-gnueabihf-gcc
-- Check for working CXX compiler: /usr/lib/ccache/arm-linux-gnueabihf-g++
-- Check for working CXX compiler: /usr/lib/ccache/arm-linux-gnueabihf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/lib/ccache/arm-linux-gnueabihf-gcc
-- Check for working C compiler: /usr/lib/ccache/arm-linux-gnueabihf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- ccache enabled via symlink (/usr/lib/ccache/arm-linux-gnueabihf-g++ -> /usr/bin/ccache)
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.9", minimum required is "3") 
-- build type is RelWithDebInfo
-- PX4 ECL: Very lightweight Estimation & Control Library v1.9.0-rc1-182-g29cf788
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dagar/git/Firmware/build/emlid_navio2_experimental
[7/790] git submodule src/drivers/gps/devices
[12/790] git submodule src/lib/ecl
[13/790] git submodule mavlink/include/mavlink/v2.0
[790/790] Linking CXX shared library src/examples/dyn_hello/examples__dyn_hello.px4mod

[LorenzMeier]

Nice!

[LorenzMeier]

Needs to be rebased. I would then immediately follow up with a manufacturer supported category and capture the support email and website in the build system.

[bkueng]

This works for a first round, however I'd like to avoid for users to have to switch build commands several times, and as this conflicts with other labels (like rtps or fixedwing), I prefer to directly to a more permanent solution, like make experimental/emlid_navio2

[dagar]

This works for a first round, however I'd like to avoid for users to have to switch build commands several times, and as this conflicts with other labels (like rtps or fixedwing), I prefer to directly to a more permanent solution, like make experimental/emlid_navio2

Yes the label breaks down if you want multiple variants of the same experimental board, but it seemed like an okay way to bring the issue front and center with something effectively unused/ignored for the vast majority of users (_default).

I wouldn't be opposed to jumping straight to a more permanent solution, I just don't know what that is exactly. What are the top level categories, how does that work with manufacturers and official px4 standard boards? How would we handle some boards being manufacturer supported and some manufacturer's boards still being experimental? I'm not sure if actual tree placement even adds any real visibility.

[bkueng]

We can do:

boards/
   experimental/
      emlid/
   official/
      px4/

And official is the default, so no change for make px4_fmu-v4. And if needed we still can add more categories in future.

[LorenzMeier]

@dagar I prefer the folder structure as well. The question is if the experimental boards should have that added to their names IN ADDITION to make it really clear.

[dagar]

We can do:

boards/
   experimental/
      emlid/
   official/
      px4/

And official is the default, so no change for make px4_fmu-v4. And if needed we still can add more categories in future.

@bkueng that part was reasonably clear, but there was talk of a level in between for manufacturer supported.

If we really want the support status to be understood by the majority of developers and even users then experimental needs to be pervasive throughout the build invocations, generated artifacts, and ideally board naming internally (ver, logs, etc). I think we can make that happen easily enough with just 2 categories (and no burden on the official targets), but the line in between for manufacturer supported boards (if any) needs to be considered from the beginning.

@dagar I prefer the folder structure as well. The question is if the experimental boards should have that added to their names IN ADDITION to make it really clear.

@LorenzMeier likewise, this PR was originally the 90 second solution until we were ready to hash out all the details that now we're now getting into. Simply splitting the folders is harmless, but I don't think that alone is going to make it clear for even most developers.