VRBRAIN: Some updates to allow building of VRBRAIN boards with waf

[LukeMike]

I Added new environments and configuration files to allow building VRBRAIN boards with waf.
I don't know if this is the best solution... probably not but I don't know very well waf.
Let me know if it's ok.
ArduPilot/PX4Firmware#63 is needed To build with waf our boards

[OXINARF]

@guludo Can you look at this? I am sure we can merge all the tools in one, can you help do that? Some changes are needed in the PX4 tool (maybe first we should talk to @tridge first about changing the tool name to nuttx, there was some conversations to change HAL_PX4 to HAL_NUTTX).

[guludo]

Hi @LukeMike :-)

Some issues:

• I agree with @OXINARF here. The px4 tool should be tweaked instead of creating a very very similar tool. But I think the name could continue being px4. If you issue sed "s,\r,," Tools/ardupilotwaf/vrbrain.py | sed -e "s,vrbrain,px4,g" -e "s,VRBRAIN,PX4,g" | diff -u Tools/ardupilotwaf/px4.py -, you'll see that the main differences are:
  • vrbrain apparently isn't using px4io. Not using px4io is already supported in the tool.
  • the target for vrbrain is 'px4' without the 'fmu' suffix.
  • differences on ROMFS files.
• I even think there shouldn't be a board class called vrbrain. The vrbrain subclasses should actually be subclasses of px4.

[OXINARF]

I even think there shouldn't be a board class called vrbrain. The vrbrain subclasses should actually be subclasses of px4.

This is a "political" thing. I think they won't have a problem with that if there's a rename. I understand that no one would like to have their boards named after another set of boards (and I think VRBRAIN actually existed before PX4).
There exists a different HAL so I think it is reasonable to have a different board type. But there's no need to have so many similar Waf tools.

[guludo]

@OXINARF

There exists a different HAL so I think it is reasonable to have a different board type.

When I said I though there shouldn't be a board called vrbrain, I actually meant as an abstract class. The vr* variants would still exist.

[OXINARF]

When I said I though there shouldn't be a board called vrbrain, I actually meant as an abstract class. The vr* variants would still exist.

I know but the abstract class is what provides the correct HAL library. And I know we could change that to accommodate VRBRAIN, but I think a separate board is preferable until a consensus about naming is reached.

[tridge]

the top level class could be called nuttx I think. Then vr* and px4* could derive from that.

[guludo]

But, doesn't it rely on things from PX4Firmware submodule?

On Thu, Aug 11, 2016 at 10:45 PM Andrew Tridgell [email protected]
wrote:

the top level class could be called nuttx I think. Then vr* and px4* could
derive from that.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#4647 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFvzi4RmsIOKw23lUup8fqwFpchqS3i9ks5qe9BPgaJpZM4JiRNl
.

[OXINARF]

@guludo Yes. Like I've written before it isn't good that the PX4 name is used for everything.

[LukeMike]

Hi all... Today I worked to merged AP_HAL_PX4 and AP_HAL_VRBRAIN into AP_HAL_NUTTX. I put my work into an our branch for_merge_nuttx.
All the boards in NuttX have a define (CONFIG_ARCH_BOARD_) then I thought to use that instead to define a CONFIG_HAL_BOARD_SUBTYPE for all board. I used CONFIG_HAL_BOARD_SUBTYPE for PX4 and VRBRAIN: I defined
#define HAL_BOARD_SUBTYPE_NUTTX_PX4 3001
#define HAL_BOARD_SUBTYPE_NUTTX_VRBRAIN 3002
CONFIG_HAL_BOARD_SUBTYPE is passed from waf into class px4, vrbrain, vrubrain and vrcore.
I built px4-v4 (arducopter-quad, arduplane and ardurover) and vrbrain-v52 and all is ok for me.

I have not finished, I have to rename all the libraries with suffix _PX4 to _NUTTX but this can be done at a later time.

Have you some time to take a look at this branch and tell me what you think?. I do not want to create a PR, without your opinion. I know it's a fairly major change but it could help solve the issue of having two cards that use the same operating system with two distinct AP_HAL.
I hope you understand me when I say that for us define our boards as a subtype of a board of another brand is not correct. In this way instead it is definitely acceptable and also properly organized

[LukeMike]

@tridge Why PX4NuttX is not a submodule of PX4Firmware? it would be great to be able to continue to build on the PX4 Firmware... especially since you have to implement and test drivers

[OXINARF]

@LukeMike That is great work! I have to ask for two things though:

• check your line endings configuration, you are changing LF to CRLF everywhere (which is wrong and makes it a pain to review, fortunately that can be bypassed by adding ?w=1 to the end of the URL)
• check your indentation settings, I saw, at least, 3 or 4 places where you changed four spaces to a tab

I have to say that I don't agree we rely on CONFIG_ARCH and use HAL_BOARD_SUBTYPE only to distinguish different vendors. I think we should be consistent and HAL_BOARD_SUBTYPE should define a specific board, like on Linux. This is just my personal opinion, I don't know what others think of it.

I will certainly bring this up in the next dev call, but I hope you understand this is quite a change so it can take some time to review everything.

Why PX4NuttX is not a submodule of PX4Firmware?

This has been debated before (stopping using our own submodule) but we have, at least, one commit on top that isn't upstream.

it would be great to be able to continue to build on the PX4 Firmware...

What do you mean with this?

[LukeMike]

@OXINARF thanksvery much... My work just wants to be a proposal, a starting point on which to reason: I do not claim for sure that it is taken as it is, and you're doing a great job. I wanted to help a little more.

I will try to check my settings ... I apologize for the inconvenience.

I use PX4Firmware to develop drivers and make tests and to launch the shell modules individually is very convenient: but this can also be done with the current system (file nostart on SD).
It just seemed more consistent to have PX4NuttX inside PX4Firmware being used only there. But I will not let you discuss things that surely you have already discussed.
I was also thinking of integrating our boards directly in PX4/Firmware to facilitate the work of Tridge when realigns the systems, but I do not think that they will never accept PR from me

For CONFIG_ARCH and HAL_BOARD_SUBTYPE: The problem is that there are some customizations that affect the individual board but others regarding the types of boards ... if you see the code that I produced you will notice that the main differences are at the level of PX4 and VRBRAIN and not a single board. I think it would be more convenient to have even this distinction.

[OXINARF]

It just seemed more consistent to have PX4NuttX inside PX4Firmware being used only there. But I will not let you discuss things that surely you have already discussed.

We want to use the upstream PX4NuttX but we need to make sure we aren't losing any change we made. If you are using PX4Firmware independently of ArduPilot to do development I think you can simply change the NuttX submodule inside your PX4Firmware local repository.

I was also thinking of integrating our boards directly in PX4/Firmware to facilitate the work of Tridge when realigns the systems, but I do not think that they will never accept PR from me

I wouldn't them?

Regarding HAL_BOARD_SUBTYPE: I understand what you are saying, some places would have a long list of ORs, but it would maintain consistency with Linux HAL. Anyway, this is something that can be discussed and decided in the dev call.

[lucasdemarchi]

@LukeMike This topic was brought up again after I needed to do some changes and basically copy and paste between PX4 and VRBRAIN hal directories. I think it would be really great if you could bring that branch as a PR. I gave it a quick look and here's my feedback:

• Use Nuttx instead of NUTTX. Just like we have AP_HAL_Linux, we would have AP_HAL_Nuttx
• You don't need to prefix the classes like NuttxStorage. It's already inside the Nuttx namespace. Take a look in the Linux hal, we removed the prefix some months ago since it was becoming so inconvenient to have to type things like Linux::LinuxStorage

Let me know if you can work on this soon.

@guludo @OXINARF wrt this specific PR, does it need to wait for the rename?

[OXINARF]

@lucasdemarchi Yes, wait for the rename as that will require a good amount of less changes than this PR.

[LukeMike]

@lucasdemarchi I am working on a new version in Vitualrobotix/pr_ap_hal_nuttx. Next week I can commit my changes and create a PR. At the moment I can build all PX4 boards. Now I have to merge our boards. The new AP_HAL is AP_HAL_Nuttx and there is no prefix PX4. I'm not using waf because for VRBrain there are not the changes I've done in another PR. Another difference is that I've created a sub type for every boards and non only one for PX4 and one for VRBrain.

[lucasdemarchi]

Check #5109. PX4 layer is greatly reduced in favor of using Nuttx directly
and intree drivers. Would be good to coordinate your changes with @tridge

Em 5 de nov de 2016 8:24 AM, "Luca Angelo Micheletti" <
[email protected]> escreveu:

@lucasdemarchi https://github.com/lucasdemarchi I am working on a new
version in Vitualrobotix/pr_ap_hal_nuttx. Next week I can commit my changes
and create a PR. At the moment I can build all PX4 boards. Now I have to
merge our boards. The new AP_HAL is AP_HAL_Nuttx and there is no prefix
PX4. I'm not using waf because for VRBrain there are not the changes I've
done in another PR. Another difference is that I've created a sub type for
every boards and non only one for PX4 and one for VRBrain.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#4647 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB8eBClEQRopGs64ksKU_1jgDQ_3m1Vks5q7GdXgaJpZM4JiRNl
.

[tridge]

@LukeMike thanks for your work on this, and sorry for all the churn with the driver layers. It is going to take some time to get it all sorted out.
I think I'm close to having the new driver framework from #5109 in master. So far it produces much better timing results than the PX4Firmware drivers, plus saves a bunch of memory and also will save a lot of flash once we remove the PX4Firmware drivers.
I'm also hoping it will encourage more people to work on the drivers. Most devs just left PX4Firmware work to me, as they found doing development in that tree too scary and unfamiliar. It also was bad that we had to do duplicate development of drivers for the Linux boards and stm32 boards.