Port PX4 to BeagleBone Blue #9635

UAV-Pilot · 2018-06-10T23:29:09Z

There will be a separate pull request in DriverFramework repository for drivers to support BeagleBone Blue. Firmware including these changes can be compiled without the DriverFramework changes.

This reverts commit 954c42c.

dagar · 2018-06-11T01:07:57Z

src/modules/commander/PreflightCheck.cpp

@@ -727,6 +727,9 @@ bool preflightCheck(orb_advert_t *mavlink_log_pub, vehicle_status_s &status,
 #elif defined(__PX4_POSIX_RPI)
 	PX4_WARN("Preflight checks for mag, acc, gyro always pass on RPI");
 	checkSensors = false;
+#elif defined(__PX4_POSIX_BBBLUE)
+	PX4_WARN("Preflight checks for mag, acc, gyro always pass on BBBLUE");
+	checkSensors = false;    


Is this actually necessary?

It's convenient for near-term development, but I'd love it if we had at least one non-PX4 platform that did preflight stuff the right way...

To expand on that slightly, most of the value comes from the estimator checks which are already running everywhere. Skipping sensor preflight checks isn't actually as horrible as it initially appears.

Hold my be....on second thought, I'll just take your word for it. :-P

dagar · 2018-06-11T01:10:40Z

How much is actually needed from the Robotics_Cape_Installer repository?

dagar · 2018-06-11T01:12:04Z

Overall this looks like a great start. The main issue I see on first pass is the number of bbblue defines in common modules. We'd really like to eliminate those entirely.

dagar · 2018-06-11T01:13:24Z

src/modules/mavlink/mavlink_main.cpp

@@ -1782,6 +1790,12 @@ Mavlink::task_main(int argc, char *argv[])
 			set_protocol(SERIAL);
 			break;

+		case 'n':
+#ifdef __PX4_POSIX_BBBLUE
+			_mavlink_wifi_name = myoptarg;


Why do we need a special case for wifi? Why is it any different than a regular network interface?

In posix-configs/bbblue/px4.config, I have the following comments about the usage of -n option.

mavlink start -x -u 14556 -r 1000000
-n name of wifi interface: SoftAp, wlan or your custom interface,
e.g., -n wlan . The default on BBBlue is SoftAp

Besides the regular network interface, a SoftAP is also activated after boot by default on BBBlue.
So there are 2 not 1 active wifi interfaces. The existing code only picks the regular one.

dagar · 2018-06-11T01:14:42Z

src/modules/sensors/sensors.cpp

@@ -447,6 +447,10 @@ Sensors::adc_poll()
 		int   bat_voltage_v_chan[BOARD_NUMBER_BRICKS] = BOARD_BATT_V_LIST;
 		int   bat_voltage_i_chan[BOARD_NUMBER_BRICKS] = BOARD_BATT_I_LIST;

+		if (_parameters.battery_adc_channel >= 0) {  // overwrite default


We need a better battery/power architecture, but at the moment the "right" way to do this would be setting the ADC channel in the board config.

In posix-configs/bbblue/px4.config, I have the following comments that could explain why this option was added. Fixing the setting in board config seems could not satisfy the need to specify the main power source for the case of BeagleBone Blue.

Three possible main power battery sources for BBBlue:

1. onboard 2S LiPo battery connector, which is connect to ADC channel 6

2. onboard 9-18V DC Jack, which is connect to ADC channel 5. This is the board default.

3. other power source (e.g., LiPo battery more than 4S/18V).

Scale the voltage to below 1.8V and connect it to ADC channel # 0, 1, 2 or 3.

param set BAT_ADC_CHANNEL 5

dagar · 2018-06-11T01:16:27Z

@bgat FYI

dagar · 2018-06-11T01:19:53Z

cmake/common/px4_base.cmake

-
-		-Wno-unused-parameter
-		)
+if(CONFIG MATCHES "^posix_bbblue_")


I'd like to discuss in the robotics cape library is actually needed as a submodule, but for now you could pass -Wno-error to it alone rather than changing these flags system wide.

I haven't played with the Robotics Cape, but it seems to me that it's incompatible with/redundant to the Beaglebone Blue. Are you including the Robotics Cape so that you can support the Black?

Nevermind, I was talking about the hardware while you were talking about the library...

The interface to librobotics needs to be part of a module, but it seems like the calls could be hidden inside of the PWM, etc. APIs and then the library itself could be shared from the host platform.

Although with enough available time and experience with TI’s ARM processor, which I don’t have, one could implement the porting without the Robotics Cape library, I’d think using this library made my porting an order of magnitude easier than implementing the corresponding features from scratch. Device initialization and other device specific APIs from this library are used for BMP280/MPU9250 I2C driver, ADC, linux_pwm, etc. Let’s take a look of linux_pwm adaption for example. The porting code simply uses 2 APIs from the library: one for initialization and another for setting pulse width, however the underline hardware and corresponding software in the library are much more complicated than these 2 seemingly simple APIs. In TI AM33XX processor, there is a PRUSS (Programmable Real-time Unit Sub System), which consists of two 32-bit 200MHz real-time core (PRU). In Robotics Cape library, the servo initialization API loads assembly code into PRU to generate PWM signals, and the pulse width setting API communicate with the external processor (PRU) through shared memory. Thus the PWM implementation involves multiple processors of different kinds: ARM and PRU, and inter-processor communication. These are not trivial tasks. Another benefit of using this library is in maintenance area. After the release of BeagleBone Blue board, its users had quite some issues when device tree in software was out of sync with kernel updates, and this issue was only resolved recently. For details, refer to this email thread: https://groups.google.com/forum/#!msg/beagleboard/GHeMjrAM5AE/zcfCc8YVCQAJ . By using this library, PX4 users with BeagleBone Blue boards and traditional Robotics Cape Library users can help each other in library maintenance with regarding to kernel updates. Another aspect is that TI made the Blue variant of the BeagleBone board by combining previously 2 boards: a BeagleBone board and a Robotics Cape (the hardware corresponding to the Robotics Cape Library software) into one board: BeagleBone Blue, so it’s natural to me to use a library which was specifically developed for BeagleBone Blue board.

I don't think it's likely that PX4 users would choose BeagleBone Black plus a sensor board over the integrated BeagleBone Blue board, so I did not think about supporting BeagleBone Black before.

dagar · 2018-06-11T01:20:39Z

Are the mavlink and sitl_gazebo submodule changes intentional?

dagar · 2018-06-11T01:22:14Z

src/drivers/boards/bbblue/CMakeLists.txt

+# POSSIBILITY OF SUCH DAMAGE.
+#
+############################################################################
+include_directories(../../../lib/Robotics_Cape_Installer/library/include)


${PX4_SOURCE_DIR}

dagar · 2018-06-11T01:23:20Z

src/drivers/linux_pwm_out/bbblue_pwm_rc.cpp

+
+#ifdef __DF_BBBLUE
+#include <roboticscape.h>
+#include "../boards/bbblue/board_config.h"


I wouldn't use a relative path, these locations are likely going to change in the near future.

LorenzMeier · 2018-06-11T06:29:11Z

On a very high-level note: We will move from DriverFramework to CDev in the next weeks. That should not preclude this PR from merging it though.

UAV-Pilot · 2018-06-12T01:26:10Z

I'm new to PX4, so with limited time available, it's impossible for me in the initial porting to get everything to match with PX4 conventions or catch up with the latest development. If I remember correctly, when I started the porting, new implementation of mpu9250 I2C driver was not ready for posix/linux platform. My original intention was to get the initial porting into PX4 code base so that others can have a working BeagleBone Blue version to improve upon piece by piece, such as replacing bmp280 and mpu9250 I2C drivers. BTW, bmp280 and mpu9250 share the same I2C bus on BeagleBone Blue, and hopefully the new CDev already handles this case.

UAV-Pilot · 2018-06-12T01:29:06Z

I did not intend to change the mavlink or sitl_gazebo or matrix or ecl submodule. Those changes came in with git sync.

UAV-Pilot · 2018-06-12T19:40:19Z

Regarding "the number of bbblue defines in common modules", I assume it refers to directives like the following:

#if !defined(__PX4_QURT) && !defined(__PX4_POSIX_RPI) && !defined(__PX4_POSIX_BBBLUE) && !defined(__PX4_POSIX_BEBOP)

#if !defined(CONFIG_ARCH_BOARD_RPI) && !defined(CONFIG_ARCH_BOARD_BBBLUE)

#if defined(__PX4_POSIX_OCPOC) || defined(__PX4_POSIX_BBBLUE)

Except the ones in cmake/common/px4_base.cmake and other cases unique to BeagleBone Blue board such as multiple choices of main power sources and multiple choices of wifi interfaces, I'd think they are intrinsic with the porting process. What I did was scanning “RPI” and “OCPOC” in all source code to see where board specific customizations are, then mirroring what has been done for other boards. From the above directives, I saw others did it for other boards (e.g., “RPI” , “OCPOC”) in the past. And with those directives remaining in code base, I can see others are most likely to do the same again in the future when porting PX4 to a new board. If they need be eliminated, a person who is more knowledgeable in PX4 is more suitable to do it for all cases.

This reverts commit 954c42c.

…make; removed relative path in include

UAV-Pilot · 2018-06-13T07:37:12Z

Modified per pull request comments:
rolled back changes to px4_base.cmake;
removed relative path in include

UAV-Pilot · 2018-06-13T08:07:51Z

(Re-post a comment hidden in an outdated section)

Although with enough available time and experience with TI’s ARM processor, which I don’t have, one could implement the porting without the Robotics Cape library, I’d think using this library made my porting an order of magnitude easier than implementing the corresponding features from scratch. Device initialization and other device specific APIs from this library are used for BMP280/MPU9250 I2C driver, ADC, linux_pwm, etc. Let’s take a look of linux_pwm adaption for example. The porting code simply uses 2 APIs from the library: one for initialization and another for setting pulse width, however the underline hardware and corresponding software in the library are much more complicated than these 2 seemingly simple APIs. In TI AM33XX processor, there is a PRUSS (Programmable Real-time Unit Sub System), which consists of two 32-bit 200MHz real-time core (PRU). In Robotics Cape library, the servo initialization API loads assembly code into PRU to generate PWM signals, and the pulse width setting API communicate with the external processor (PRU) through shared memory. Thus the PWM implementation involves multiple processors of different kinds: ARM and PRU, and inter-processor communication. These are not trivial tasks. Another benefit of using this library is in maintenance area. After the release of BeagleBone Blue board, its users had quite some issues when device tree in software was out of sync with kernel updates, and this issue was only resolved recently. For details, refer to this email thread: https://groups.google.com/forum/#!msg/beagleboard/GHeMjrAM5AE/zcfCc8YVCQAJ . By using this library, PX4 users with BeagleBone Blue boards and traditional Robotics Cape Library users can help each other in library maintenance with regarding to kernel updates. Another aspect is that TI made the Blue variant of the BeagleBone board by combining previously 2 boards: a BeagleBone board and a Robotics Cape (the hardware corresponding to the Robotics Cape Library software) into one board: BeagleBone Blue, so it’s natural to me to use a library which was specifically developed for BeagleBone Blue board.

This reverts commit 954c42c.

…make; removed relative path in include

hamishwillee · 2018-06-18T05:01:18Z

@UAV-Pilot When this is done, do you think you could create a setup page in the documentation? Probably something about the same level as this one?

bgat · 2018-06-18T15:35:42Z

You really DO want to use libroboticscape for this port, because the PWM channels are all routed to the PRU. That makes them dependent on PRU firmware, which travels in sync with libroboticscape.

The alternative is to adopt Linux's PWM sysfs interface, which would substantially increase CPU loading on high-update-rate platforms like quad/hex/octocopters. It might let you run PX4 on other boards in the Beagle universe, but I don't think that's an interesting goal right now.

(When I started looking at Blue, I looked at getting rid of libroboticscape and decide it just wasn't worth the effort. Then, life happened and my attention got pulled elsewhere...)

dagar · 2018-06-18T15:37:47Z

You really DO want to use libroboticscape for this port, because the PWM channels are all routed to the PRU. That makes them dependent on PRU firmware, which travels in sync with libroboticscape.

That's fine, but can we do it cleanly without having to carry yet another submodule?

bgat · 2018-06-18T16:12:27Z

There's a runtime package for the Beaglebone Blue itself, but there isn't a -dev package for cross-compiling with it. So bringing it in as a submodule is about as good as it gets right now.

Tragically, libroboticscape has build dependencies on ti-pru-cgt-installer and pru-software-support-package, so even with the submodule there's no guarantee that you've got everything you need to cross-compile PX4 to BBB. Ugh.

It's as if the BBB guys solved the easy half of the problem, then moved on...

UAV-Pilot · 2018-07-02T21:52:53Z

So far I had no problem when cross-compiling PX4 to BeagleBone Blue on Ubuntu host.

It has been quite some time since this pull request was opened. May we move ahead to next step? If so, I'll make it builtable again.

This initial port can make PX4 available on BeagleBone Blue now, and it does not prevent others from enhancing PX4 on BeagleBone Blue in the future such as phasing out the roboticscape submodule if desired. Getting PX4 onto BeagleBone Blue now rather than an unknown future time might actually accelerate the enhancement process as it'd give more people a usable version of PX4 on BeagleBone Blue to play with, explore and enhance.

BTW, roboticscape package was renamed librobotcontrol recently, and according to its github page: https://github.com/StrawsonDesign/librobotcontrol , it was also used in porting ArduPilot to BeagleBone Blue. Also this package ships with official BeagleBone OS images (refer to https://beagleboard.org/latest-images).

UAV-Pilot · 2018-07-24T05:25:41Z

New pull request #10012 with rebased code was created to change the usage of the robot control package from a submodule to a library.

UAV-Pilot · 2018-08-03T17:36:07Z

@hamishwillee Had a local draft here: UAV-Pilot/px4_user_guide@abaf61f . I'll create a pull request once pull request #10012 is merged. I'm new to gitbook, so later please help polish it.

hamishwillee · 2018-08-05T23:25:00Z

Thanks @UAV-Pilot. I added a few comments, but overall this looks like a good structure and content. I can tidy the markdown for gitbook as a post-process :-)

UAV-Pilot · 2018-08-07T07:34:17Z

@hamishwillee Thanks for the feedback! Now that pull request #10012 was merged, I updated the document according to your feedback and upcoming posix shell feature (#10173), and created pull request PX4/PX4-user_guide#306 . Please take a look. Thanks!

UAV-Pilot · 2018-08-07T07:35:03Z

Now that pull request #10012 was merged, close this original pull request.

Bob-F and others added 9 commits May 27, 2018 16:53

Updated src/lib/DriverFramework

954c42c

changes from git pull upstream master

1fdedcd

Firmware changes for porting PX4 to BeagleBone Blue board

4a90254

Merge branch 'master' of https://github.com/PX4/Firmware

72236b7

Firmware changes for porting PX4 to BeagleBone Blue board

a002bf1

Revert "Updated src/lib/DriverFramework"

126a9e4

This reverts commit 954c42c.

skip output redirect when parsing arguments in main function

02697b5

resolve a conflict during git operations

e47c9a4

Added Robotics_Cape_Installer submodule

eb2d15d

dagar reviewed Jun 11, 2018

View reviewed changes

dagar added the Admin: Enhancement (improvement) 💡 label Jun 11, 2018

UAV-Pilot added 6 commits June 12, 2018 23:05

Merge branch 'master' of https://github.com/PX4/Firmware

c98cc66

Merge branch 'master' of https://github.com/PX4/Firmware

0162b09

Firmware changes for porting PX4 to BeagleBone Blue board

a45ce46

Revert "Updated src/lib/DriverFramework"

8dd5fbb

This reverts commit 954c42c.

skip output redirect when parsing arguments in main function

a95964a

Added Robotics_Cape_Installer submodule

4134f72

UAV-Pilot added 4 commits June 12, 2018 23:53

Firmware changes for porting PX4 to BeagleBone Blue board

6a03294

Modified per pull request comments: rolled back changes to px4_base.c…

a4b65a1

…make; removed relative path in include

Resolve push conflict

1412c71

Modified per pull request comments

19db523

UAV-Pilot added 12 commits June 13, 2018 02:21

sync change to src/lib/DriverFramework

2ad7fd9

Merge branch 'master' of https://github.com/PX4/Firmware

5566ce5

Firmware changes for porting PX4 to BeagleBone Blue board

deb6d2d

Revert "Updated src/lib/DriverFramework"

60ad621

This reverts commit 954c42c.

skip output redirect when parsing arguments in main function

54e1381

Added Robotics_Cape_Installer submodule

09e750e

Firmware changes for porting PX4 to BeagleBone Blue board

0817fd2

skip output redirect when parsing arguments in main function

acdc25e

Firmware changes for porting PX4 to BeagleBone Blue board

8bf145e

Modified per pull request comments: rolled back changes to px4_base.c…

d8e8914

…make; removed relative path in include

Modified per pull request comments

25a0b02

git sync

c10855e

UAV-Pilot mentioned this pull request Jul 31, 2018

Driver changes for porting PX4 to BeagleBone Blue PX4/DriverFramework#228

Merged

UAV-Pilot closed this Aug 7, 2018

Port PX4 to BeagleBone Blue #9635

Port PX4 to BeagleBone Blue #9635

Conversation

UAV-Pilot commented Jun 10, 2018 • edited by AuterionWrikeBot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dagar commented Jun 11, 2018

dagar commented Jun 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Three possible main power battery sources for BBBlue:

1. onboard 2S LiPo battery connector, which is connect to ADC channel 6

2. onboard 9-18V DC Jack, which is connect to ADC channel 5. This is the board default.

3. other power source (e.g., LiPo battery more than 4S/18V).

Scale the voltage to below 1.8V and connect it to ADC channel # 0, 1, 2 or 3.

dagar commented Jun 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dagar commented Jun 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LorenzMeier commented Jun 11, 2018

UAV-Pilot commented Jun 12, 2018

UAV-Pilot commented Jun 12, 2018

UAV-Pilot commented Jun 12, 2018

UAV-Pilot commented Jun 13, 2018

UAV-Pilot commented Jun 13, 2018

hamishwillee commented Jun 18, 2018

bgat commented Jun 18, 2018

dagar commented Jun 18, 2018

bgat commented Jun 18, 2018

UAV-Pilot commented Jul 2, 2018

UAV-Pilot commented Jul 24, 2018

UAV-Pilot commented Aug 3, 2018

hamishwillee commented Aug 5, 2018

UAV-Pilot commented Aug 7, 2018

UAV-Pilot commented Aug 7, 2018

UAV-Pilot commented Jun 10, 2018 •

edited by AuterionWrikeBot

Loading