ArduPilot SITL on FreeBSD 15.0 – successful build and a question about porting

Before testing firmware builds, please install the ARM embedded toolchain and:
Code: 
pkg install gcc-arm-embedded gcc opencv proj rsync git gmake python py311-pip py311-sqlite3
The port uses arm-none-eabi-gcc to build firmware for STM32-based flight controllers (e.g. F405, F7, H7).

SITL can be tested without the ARM toolchain, but hardware firmware builds require gcc-arm-embedded.
Tested on FreeBSD 15.0-RELEASE:
- SITL (ArduCopter)
- SPEDIXF405 firmware build
Code: 
ardupilot-waf configure --board SPEDIXF405
ardupilot-waf copter
codeberg.org

ports-FreeBSD

my test ports FreeBSD Makefile
codeberg.org codeberg.org
 
I was checking out your codeberg repository and I must congratulate you. That is quite a bit of work you have there.
Looking at your science/adrupilot port and the GH Tuples I was back to my same nagging question.
Should some of this be separate ports or a metaport. I am not thoroughly versed. Seeing the ARM EABI needed for the whole port knda makes my point.

It does not look like you will need to drag in 20 new ports for this like I thought. What is your estimation of new ports needed?
Reason I ask is you might want to push the new dependencies first 'In anticipation' of landing the ArduPilot port. Giving people a heads up.

I am pretty sure the setuptools work is there at the PR for v81.0 but it seems some patches are there that are not needed for py-setuptools but are fixes for the upcoming breakage.
Its hard to discern from all those patches what is needed. The unrelated-ports fixes really should be in another PR.

I started with the v78.1 patch and it alone failed. It would satisfy your dependency.

Everything you have done is excellent. Once the ports are finished you might want to add another way to test the port work.
Make an archive file of all the custom ports so testers can extract them straight into a ports tree to test.
jmos did that with his custom SeaMonkey port and I found it a good way to use the software.

pynmeagps Makefile has some extraneous text. Good job fixing the license error.

What can I do to help you? Have you devised a plan ? FreeBSD @python Mailing List RFC or talk to python @ IRC members?
Laying groundwork might help this move along.
 
Previously I would get a successful wheel build. Shown in GREEN text. Now I can't get that far.

Code: 
===>  License MIT accepted by the user
===>   py311-setuptools-78.1.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py311-setuptools-78.1.1 for building
===>  Extracting for py311-setuptools-78.1.1
=> SHA256 Checksum OK for python/setuptools-78.1.1.tar.gz.
===>  Patching for py311-setuptools-78.1.1
===>   py311-setuptools-78.1.1 depends on package: py311-packaging>=24.2 - found
===>   py311-setuptools-78.1.1 depends on package: py311-more-itertools>=8.8 - found
===>   py311-setuptools-78.1.1 depends on package: py311-wheel>=0.43.0 - found
===>   py311-setuptools-78.1.1 depends on file: /usr/local/bin/python3.11 - found
===>   py311-setuptools-78.1.1 depends on package: py311-build>=0 - found
===>   py311-setuptools-78.1.1 depends on package: py311-installer>=0 - found
===>  Configuring for py311-setuptools-78.1.1
===>  Building for py311-setuptools-78.1.1
* Getting build dependencies for wheel...

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook
    raise BackendUnavailable(
pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'

ERROR Backend 'setuptools.build_meta' is not available.
*** Error code 1

Stop.
make: stopped making "all" in /usr/ports/devel/py-setuptools78

Using Makefile for 78.1.1 from v81.0 PR
/usr/ports/devel/py-setuptools78/Makefile
Code: 
PORTNAME=    setuptools
DISTVERSION=    78.1.1
CATEGORIES=    devel python
MASTER_SITES=    PYPI
PKGNAMEPREFIX=    ${PYTHON_PKGNAMEPREFIX}
DIST_SUBDIR=    python
 
# note: before committing a new major version, contact portmgr to
# arrange for an experimental ports run. Untested commits may be
# backed out.
MAINTAINER=    python@FreeBSD.org
COMMENT=    Python packages installer
WWW=        https://setuptools.pypa.io/
 
LICENSE=    MIT
LICENSE_FILE=    ${WRKSRC}/LICENSE
 
BUILD_DEPENDS=    ${_CORE_DEPENDS}
RUN_DEPENDS=    ${_CORE_DEPENDS}
 
USES=        cpe python

CPE_VENDOR=    python
USE_PYTHON=    allflavors autoplist concurrent pep517 pytest

_CORE_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}packaging>=24.2:devel/py-packaging@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}more-itertools>=8.8:devel/py-more-itertools@${PY_FLAVOR} \
        ${PY_TOMLI} \
        ${PYTHON_PKGNAMEPREFIX}wheel>=0.43.0:devel/py-wheel@${PY_FLAVOR}

# circular dependencies
#_CORE_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}jaraco.text>=3.7:devel/py-jaraco.text@${PY_FLAVOR} \
#        ${PYTHON_PKGNAMEPREFIX}platformdirs>=4.2.2:devel/py-platformdirs@${PY_FLAVOR} \
#        ${PYTHON_PKGNAMEPREFIX}jaraco.functools>=4:devel/py-jaraco.functools@${PY_FLAVOR}

# remove vendored packages of those already installed via pkg(8)
_DIST_EXCLUDES=    packaging* \
        more_itertools* \
        wheel* \
        tomli* \
        typing_extensions* \
        importlib_metadata* \
        zipp*
EXTRACT_AFTER_ARGS=    ${_DIST_EXCLUDES:S,^,--exclude setuptools/_vendor/,}
 
NO_ARCH=    yes

.include <bsd.port.mk>
 
Python dependencies are being submitted separately:
devel:py-fastcrc, py-pymavlink, py-pynmeagps, py-dronecan
net/py-mavproxy
These ports were not previously available in the FreeBSD Ports Collection. Other dependencies, such as py311-intelhex, already exist in the ports tree.
I currently see ArduPilot as two parts:
  • ArduPilot SITL
  • ArduPilot firmware build support
  • The required ports for firmware builds are listed as dependencies, and gcc-arm-embedded is already available in the Ports Collection.
  • I think QGroundControl should be handled as a separate port: https://github.com/mavlink/qgroundcontrol
The setuptools > 81 issue is not that setuptools itself is unavailable. The problem is that many Python packages need to be checked and tested for compatibility. While testing one version, newer versions are released, and it is difficult to keep up with the repository of tested packages. There are also relatively few people working on porting and testing.


>>> Regarding your question, "What can I do to help?":
Test the ports with:
Code: 
make install clean
and report any build or runtime errors, build firmware for a Matek F405 Wing V2 board, flash the generated firmware onto a Matek F405 Wing V2 and verify that it works correctly.
 
Regarding py-setuptools, it would be worth discussing this with the Python team to understand which direction they are taking and which version they are currently testing.
Building py-setuptools 81 is not the main problem. The real challenge is testing a large number of Python modules and ensuring that nothing breaks across the ports tree or in existing user environments.Any setuptools update has a wide impact, so compatibility testing is likely more important than getting a newer version to build successfully.
 
It does seem like a massive amount of work with the packaging changes. First elimination of setup.py for PEP517 then elimination of PKG-INFO.

I am beginning to understand the term "Technical Debt". FreeBSD Python team has quite a task onhand.
 
Started testing your ports.
/science/ardupilot -- Checks out good Did not check
/devel/py-dronecan -- Checks out good
/devel/py-mavlink -- Makefile has bogus text Head and Master. Needs pyfastcrc built first... Depends on it?
/devel/pyfastcrc -- SAME. Bogus Makefile text Head and Master.

make[1]: stopped making "install" in /usr/ports/devel/py-fastcrc
*** Error code 1

Stop.
make: stopped making "all" in /usr/ports/devel/py-pymavlink
Click to expand...

I use this to grab dependencies from packages for each port build:
make build-depends-list | cut -c 12- | xargs pkg install -A -y
 
I can't seem to get /devel/py-fastcrc to build using my installed packaged rust-1.94.

py-fastcrc wants to build from ports RUST v1.96

Just to show you how much I want to see this ported I am letting it build..
 
when I tested, I was going to use rust 1.95.0, now I'm testing
>> /devel/py-mavlink -- Makefile contains fake Head and Master text. First you need to create pyfastcrc... Does it depend on this?
yes, it is written in Makefile RUN_DEPENDS=
Code: 
cd /usr/ports
git branch -vv
 
Yes I think that because I use "QUARTERLY" packages on this machine but a fresh ports tree I ran into that rust problem.
I let it run overnight and did a make config-recursive beforehand.(Rust sucks in so many ports its terrible)
Good Build was done in the morning.
/devel/fastcrc

Nice job.
 
/devel/py-pymavlink
Now builds well. Lots of moved links at end. I guess that is staging. Looks like it is suffixing a version.
Code: 
Successfully built pymavlink-2.4.49-cp311-cp311-freebsd_14_4_release_p6_amd64.whl
===>  Staging for py311-pymavlink-2.4.49
===>   py311-pymavlink-2.4.49 depends on package: py311-lxml>=0 - found
===>   py311-pymavlink-2.4.49 depends on package: py311-fastcrc>=0 - found
===>   py311-pymavlink-2.4.49 depends on file: /usr/local/bin/python3.11 - found
===>   Generating temporary packing list
===> Creating unique files: Move MAN files needing SUFFIX
===> Creating unique files: Move files needing SUFFIX
Move: bin/magfit.py --> bin/magfit.py-3.11
Link: @bin/magfit.py --> bin/magfit.py-3.11
Move: bin/magfit_WMM.py --> bin/magfit_WMM.py-3.11
Link: @bin/magfit_WMM.py --> bin/magfit_WMM.py-3.11
Move: bin/magfit_delta.py --> bin/magfit_delta.py-3.11
Link: @bin/magfit_delta.py --> bin/magfit_delta.py-3.11
Move: bin/magfit_gps.py --> bin/magfit_gps.py-3.11
Link: @bin/magfit_gps.py --> bin/magfit_gps.py-3.11
Move: bin/magfit_motors.py --> bin/magfit_motors.py-3.11
 
/cad/openrocket
Built OK but I stopped it when the build tried to build openjdk25 from ports. I installed openjdk25 via FreeBSD packages and continued..
So it requires openjdk
 
I see two copies of py-mavproxy. One in /devel and one in /net
The one in /devel should be deleted.

Please consider this structure for your ports tree MAIN categories:
/science/ardupilot <<<< I think this was a good choice
/devel/py-fastcrc <<<<<< This one is the probably the only one that belongs in /devel aka developer tools. maybe /MATH secondary
/astro/py-pynmeagps <<<<< All GPS stuff goes in /ASTRO
/comms/pymavlink <<<<< Secondary /NET
/science/mavproxy
/science/openrocket <<<< Secondary /MATH
/misc/py-dronecan <<<<< Maybe /SCIENCE
 
For MAINTAINER=
Do not use python@FreeBSD.org or ports@FreeBSD.org

ports@ as MAINTAINER spits out message about unmaintained port.
python@ as MAINTAINER is incorrect. They only handle Python tooling.

No offense at all. You do not want to make more work for the team. They want to see maintained port submitted.
I know these are just dummy entries but I wanted to make sure. You have already exposed a public email for this task.
 
The PR for py-setuptools references a REVIEW.

⚙ D46236 devel/py-setuptools: update to 81.0.0

reviews.freebsd.org reviews.freebsd.org
The build/patch here 78.1.0 does not work for me either. Is it just me? It also has differences with the 78.1.1 patch on PR.
Code: 
* Getting build dependencies for wheel...

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook
    raise BackendUnavailable(
pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'

ERROR Backend 'setuptools.build_meta' is not available.
*** Error code 1

Stop.
make: stopped making "all" in /usr/ports/devel/py-setuptools78

Off topic:
Why are all these new Python ports building with the lowest version? py-3.11 ? Installed is 3.11,3.12,3.13,3.14

What does it mean when there is "t" suffixed? py-3.11t ???
 
The little snippit at the bottom of the Reviews Makefile is interesting:
Code: 
.include <bsd.port.pre.mk>
.if ${PYTHON_REL} < 31000
_CORE_DEPENDS+=    ${PYTHON_PKGNAMEPREFIX}importlib-metadata>=6:devel/py-importlib-metadata@${PY_FLAVOR}
.endif
.if ${PYTHON_REL} < 31100
_CORE_DEPENDS+=    ${PYTHON_PKGNAMEPREFIX}tomli>=2.0.1:textproc/py-tomli@${PY_FLAVOR}
.endif

.include <bsd.port.post.mk>

${PYTHON_REL} < 31000
I guess this means < version 3.10.0.0
 
create link
Code: 
sudo ln -s /usr/local/bin/python3.11 /usr/local/bin/python
sudo ln -s /usr/local/bin/python3.11 /usr/local/bin/python3


if we are compiling a new setuptools, then we need all the modules to be from the work folder, not the system ones that are installed. we need to edit a lot of env. sorry for writing briefly. no time

Quickstart - setuptools 82.0.1 documentation

setuptools.pypa.io setuptools.pypa.io
https://pypi.org/project/build/

Mitigated API authentication bypass for python.org download metadata
 
I have looked at the firmware in a disassembler, and I noticed that it contains a lot of code which is not used on a particular flight controller. For example, support for many different barometers, sensors, and other hardware is compiled into the same firmware. That is why I have been thinking for a long time about generating firmware tailored to the specific hardware configuration. I think a 1 MB flight controller is still a good choice for learning ArduPilot and getting started. Even if some advanced features are not available, it provides enough functionality for the first steps. For new projects, however, I think it makes sense to choose a flight controller with at least 2 MB of flash (or even more if possible), because the ArduPilot project continues to grow and new features are constantly being added. At the same time, I believe it is important to continue supporting 1 MB boards. There are many F405-based flight controllers already in use, and generating firmware specifically for the hardware installed on a board could help extend their useful life. It is also worth remembering that working with flight controllers often requires some soldering skills, whether for repairs, modifications, or connecting additional hardware.
 

Attachments

  • cutter.png
    cutter.png
    60.3 KB · Views: 28
Luckily Amazon had not shipped my controller so I cancelled the Matek F705 WING.
I might buy a H743-WING with 2MB flash.
I really don't mind spending more for my first buy. I wish I had read more.
Thanks so much for the help.
 
My soldering skills are not the best but I can make things stick. But that is a selling point for the Pixhawk. The modular connectors.
Not going to lie to you. Soldering on a $120 new board scares me. I can do 2.54mm pitch OK these days.
So I have to balance the extra costs of Pixhawk over DIY connectors on others.
PixHawk6 is beyond my budget. Pixhawk4 with H743 don't impress for the price.

Since I am buying a controller for a rover all these controllers are massive overkill.
I could do it with an F4 but I do want to have plenty of flash memory as you point out.

I have looked at a couple of Pi based controllers and considered it. RC Hat looks nice.
It is quite a contrast from a flight controller.
Everything on them is miniaturized. I don't need that. Hence why I like the -WING boards. Larger sized.

I was also checking out the STM32 robot controllers. Nucleo boards with H723.

I see cheap developer boards with H743 and 2M flash for $25 dollars. That would be neat.

One thing I have learned is looping is a big part of what the controller does. How fast the MCU is affects looping frequency.
 
You must log in or register to reply here.
Back
Top