Hello,
I have talked myself into using ArduCopter again for flying w/ a Linux based BBBlue as my AutoPilot.
Anyway…is waf smart? Is it smart enough. I want to cross-compile and then upload the arducopter executable to the BBBlue (Linux based controller) to use it for control of my craft.
Um…would I need to call the gcc compiler or is there a waf command to use?
Seth
From the Ardupilot directory:
./waf configure --board=blue
./waf copter
Then copy the binary to the bb. Instructions in the wiki.
Hello @james_pattison ,
Seth here. Yep…I got that far. I was actually using:
Then, I followed the instructions on the github.com repo. for building using upload and rsync .
Seth
P.S. I was thinking that I needed to use a cross-compiler like arm-linux-gnueabihf-gcc and -g++ and so on. I guess the waf command finds the CC=pwd/ and then makes a move. Anyway…I really thought I needed to change out some of the internals in where waf finds the files needed to CC.
If you’ve run the environment install script the tool chain will be where waf can find it.
Hello @james_pattison,
Seth here again. Yes sir…no issue. I will need to change some items on the install script, i.e. as I am running a Debian Distro on my BBBlue and Ubuntu has a different version of a CC.
Seth
P.S. Does that sound right? Anyway…I will keep trying. I am using QGroundControl to do basic setup and teardown of the configurations, calibrations, and parameters. It seems everything is working when I listen to their source online for calibration of ESCs and so on but then I start an ArduPilot-ArduCopter executable for the BBBlue and run the bot. This is when exactly nothing happens. Is there a log I should look into that may show more than journalctl -xe or systemctl status arducopter.service ?
The install script is to put the tool chain on the pc you’re compiling on, so the distro on your bb is a separate matter. Just follow the guides linked in the documentation.
Hello,
I tried. Time to install a new system. I have sid and I need buster since the BBBlue system is Debian Buster that I am working on.
Right now, I am natively compiling the arducopter source from ardupilot on the BBBlue itself. Since I ruined my system, I will need to install a new system. I decided to install python3.9 from sid by accident. Things since then, have been mucked.
Seth
P.S. I will go and listen to the guides. Anyway, thank you for your participation so far. I rarely get repliers.
Hello Sir,
Seth here again. Um…are the PRU software(s) for the BBBlue compiled when compiling Copter-4.1 or has people moved on from producing compiled PRU source for this particular board.
I ask b/c I am not too familiar w/ the PRU clpru or pasm compilers nor do I regularly code in CPP, C, and/or ASM.
Seth
P.S. And then there are linker scripts too. Anyway, if you are familiar w/ these ideas, please do reply. I kind of caught the tail end of the ArduPilot-BBBlue production phases.
You’re overthinking this somewhat. Just follow the guide, it’s all there to follow.
The only variation you might want to make is to build a more recent version of Ardupilot.
Why is it so important that the BBBlue create its own binary? You could build on a faster platform (with probably fewer struggles) and then copy the binary over.
Hello @Yuri_Rage,
Seth here. Um…I thought since I needed an arm binary/executable, building on the machine would ensure that this took place.
Seth
ArduPilot rarely runs natively on the system upon which it was built. Many of our flight controllers are STM32-based with Arm processors, but we build on Windows, Linux, or even Mac.
I recently refreshed the OS on my primary (Windows 10) laptop and needed to reconfigure the build environment anyway, so I just went through the exercise of installing WSL2, cloning and updating the repository, running the configuration scripts, and then building the “blue” target. It only took about 20 minutes, including all the downloads and configuration steps.
I now have a Copter 4.2.0-dev binary that should run on a BeagleBone Blue, though I have no way of testing to confirm that.
Hello…okay. I will attempt it this way. I have WSL2 as a Debian Distro on my Win 10 machine.
Seth
P.S. I will then put it, the binary, on the BBBlue and test it.
I don’t see why Debian won’t work, but it’d be trivial to install Ubuntu alongside it (as an additional WSL2 distro) if you run into further trouble.
Hello @Yuri_Rage,
Okay…so. The STM32-based arm chip has eabi, non hard float, and I thought this would matter when cross-compiling to get the toolchain and everything else.
But…I have a BBBlue and I will install the Ubuntu version of WSL2 and then install the config. script and port the executable to the BBBlue for testing.
Seth
P.S. If it is that easy, I will reply once I get up and running to allow others to know what I have done that works and what does not work.
The configuration script should take care of the cross compilation options, dependencies, and any other requirements.
Hello @Yuri_Rage,
Okay…I am installing the prereqs now for Ubuntu. I will keep everyone informed.
Seth
P.S. Thank you. Okay…so. It seems I am Ready to Fly on the QGroundControl but the motors are not spinning like when I calibrated them. So, the machine is not flyable right now. Maybe it is a config. on the BBBlue I am overlooking. The compilation finished w/ ease and the prereqs installed too. I uploaded the binary to the BBBlue w/ waf like described.
Hello @Yuri_Rage and @james_pattison ,
Would I say ‘n’ for no when this happens in the build script?
# ArduPilot official Toolchain for STM32 boards
function install_arm_none_eabi_toolchain() {
# GNU Tools for ARM Embedded Processors
# (see https://launchpad.net/gcc-arm-embedded/)
ARM_ROOT="gcc-arm-none-eabi-6-2017-q2-update"
ARM_TARBALL="$ARM_ROOT-linux.tar.bz2"
ARM_TARBALL_URL="https://firmware.ardupilot.org/Tools/STM32-tools/$ARM_TARBALL"
I am asking b/c the firmware is for STM32 boards, right? And…I need a eabihf toolchain. Is there a toolchain from ArduPilot w/ this reference or do I need to find my own, e.g. like on the ARM website or w/ the Linaro toolchain website?
Seth
P.S. I only ask b/c when building images and other resources for the armv7l boards, I have always had to get a toolchain w/ the gnueabihf versioning.
Please stop overthinking this. Follow the documentation.
If you’ve got WSL2 and an Ubuntu distro already, follow these steps.
Pay particular attention to this install script, available once you’ve cloned the repository:
Tools/environment_install/install-prereqs-ubuntu.sh -y
I suppose you could get away with not installing the STM32 toolchain, but there is no harm (other than a few MB of virtual machine bloat) in just saying yes to everything and letting the script do its job.
Your specific question is answered via a glance at the configuration script - it sets the build environment correctly by setting toolchain = 'arm-linux-gnueabihf'.
You are overcomplicating this in a big way.
Also, if you’ve already built a binary, uploaded it, and connected to QGC, then your toolchain is set up correctly. You more likely have an onboard configuration problem that should be solved via setting parameters in QGC rather than reloading or rebuilding the firmware.