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

resora said:
Mission data, parameters, and configuration are stored separately in non-volatile onboard storage and remain available after power cycling.
Click to expand...
If i am reading correct 'the cube' has just 1MB RAM and 2MB storage. That is all it needs?
The internal flash sounds like SPI flash?
Can you recommend a 'rover' controller for ArduPilot? It seems to me the features shown here are well beyond what I would need for a land rover.
Flight controller seems overkill for me but this software suite seems amazing.

I see some controllers with JST connectors for the soldering impaired.

I started looking at pynmeagps and what I thought would be an easy one to port might have been wrong.
There are many python scripts in the one port to test. We know it works with PIP so it should port fine.
I am going to make a simple port python skeleton and build from there.
Lot of commonality when I peruse the python ports in our tree.
Good doc here for porting. Spells it out.
 
My first python port stab:
/usr/ports/astro/py-pynmeagps/Makefile
Code: 
PORTNAME=       pynmeagps
DISTVERSION=    1.1.5
CATEGORIES=     astro python geography
MASTER_SITES=   PYPI
PKGNAMEPREFIX=  ${PYTHON_PKGNAMEPREFIX}

MAINTAINER=     python@dude.tld
COMMENT=        Python library for NMEA GPS messages
WWW=            https://github.com/semuconsulting/pynmeagps

LICENSE=        BSD3CLAUSE
LICENSE_FILE=   ${WRKSRC}/LICENSE

USES=           python
USE_PYTHON=     autoplist concurrent pep517 pytest

NO_ARCH=        yes

.include <bsd.port.mk>


It fails but I have no port requirements yet. This library has no SETUP.PY to extract stuff from... PEP 517 is the new way?
How-to-do -that?

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
*** Error code 1
Click to expand...
 
Code: 
PORTNAME=       pynmeagps
DISTVERSION=    1.1.5
CATEGORIES=     astro python geography
MASTER_SITES=   PYPI
PKGNAMEPREFIX=  ${PYTHON_PKGNAMEPREFIX}
MAINTAINER=     python@dude.tld
COMMENT=        Python library for NMEA GPS messages
WWW=            https://github.com/semuconsulting/pynmeagps
LICENSE=        BSD3CLAUSE
LICENSE_FILE=   ${WRKSRC}/LICENSE
USES=           python
USE_PYTHON=     autoplist concurrent pep517 pytest
BUILD_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}setuptools>=0:devel/py-setuptools \
${PYTHON_PKGNAMEPREFIX}wheel>=0:devel/py-wheel
NO_ARCH=        yes
.include <bsd.port.mk>
please test Makefile
 
Same message even after pkg clean. I decided to move on to another pip to port to get a grasp and was happy to find these.
comms/py-pyserial
misc/py311-pexpect
devel/py-geocoder
textproc/py-empy
devel/py-intelhex
devel/py-defusedxml


I am not sure about jinja2. We have some ports that might work:
textproc/py-jinja2-cli
textproc/py-jinjanator

So we need to do PIP to ports on:
:
MAVProxy
pymavlink
dronecan
fastcrc
pynmeagps

I wonder how dronecan works via PIP when we don't even have CAN support? I will look at that one next.
 
Digging through fastcrc source pyproject.toml is the file needed for dependencies.
py-fastcrc needs maturin which we have in ports:
devel/py-maturin

For pynmeagps we have these:
Code: 
[dependency-groups]
build = [
    "build",
    "packaging>=24.2",
    "pip",
    "setuptools>=75.0.0",
    "twine>=6.1.0",
    "wheel",
]
 
I'm collecting pimavlink dependencies - there are no python fastsrc in the ports, so I'm making a new package, I'll write about successes or failures
Porting programs is truly an eternal quest to complete. )))
 
I reached a brick wall. pynmeagps needs py-setuptools>75 and we only have 63.1. I tried to fudge it but it really needs >70.1

Code: 
/usr/local/lib/python3.11/site-packages/wheel/bdist_wheel.py:4: FutureWarning: The 'wheel' package is no longer the canonical location of the 'bdist_wheel' command, and will be removed in a future release. Please update to setuptools v70.1 or later which contains an integrated version of this command.

ERROR Missing dependencies:
setuptools>=75.0.0
*** Error code 1
Click to expand...

Revised Makefile
Code: 
PORTNAME=    pynmeagps
DISTVERSION=    1.1.5
CATEGORIES=    astro python geography
MASTER_SITES=    PYPI
PKGNAMEPREFIX=    ${PYTHON_PKGNAMEPREFIX}

MAINTAINER=    python@dude.tld
COMMENT=    Python library for NMEA GPS messages
WWW=        https://github.com/semuconsulting/pynmeagps

LICENSE=    BSD3CLAUSE
LICENSE_FILE=    ${WRKSRC}/LICENSE

USES=        python
USE_PYTHON=    autoplist concurrent pep517

BUILD_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}build>0:devel/py-build@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}packaging>=0:devel/py-packaging@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}pip>=19.3.1:devel/py-pip@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}setuptools>=0:devel/py-setuptools@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}twine>0:devel/py-twine@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}wheel>0:devel/py-wheel@${PY_FLAVOR} \

NO_ARCH=    yes

.include <bsd.port.mk>
 
I already had /devel/py-fastcrc in progress. Let me share my work with you.
/usr/ports/devel/py-fastcrc/Makefile
Code: 
PORTNAME=       fastcrc
DISTVERSION=    0.3.6
CATEGORIES=     devel python
MASTER_SITES=   PYPI
PKGNAMEPREFIX=  ${PYTHON_PKGNAMEPREFIX}

MAINTAINER=     python@dude.tld
COMMENT=        Python module for computing CRC checksums
WWW=            https://github.com/overcat/fastcrc

LICENSE=        MIT
LICENSE_FILE=   ${WRKSRC}/LICENSE

USES=           python
USE_PYTHON=     autoplist concurrent pep517

BUILD_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}maturin>=1.5<2.0:devel/py-maturin@${PY_FLAVOR}

NO_ARCH=        yes

.include <bsd.port.mk>
To use this run make. Then run make makesum then make again.

More work needed:
ERROR Missing dependencies:
puccinialin
*** Error code 1
Click to expand...
 
Make that another port needed.
py-puccinialin

And it has needs:

Code: 
dependencies = [
    "filelock>=3.19.1,<4.0.0",
    "httpx>=0.28.1,<0.29",
    "platformdirs>=4.3.6,<5",
    "tqdm>=4.67.1,<5",

Code: 
[build-system]
requires = ["flit_core>=3.2,<4"]
Code: 
[dependency-groups]
dev = [
    "ruff>=0.15.6,<0.16.0",
    "ty>=0.0.23,<1.0.0",
 
Please test Makefile, build >= rust 1.9.5
Code: 
PORTNAME=    fastcrc
DISTVERSION=    0.3.6
CATEGORIES=    devel python
PKGNAMEPREFIX=    ${PYTHON_PKGNAMEPREFIX}

MAINTAINER=    python@dude.tld
COMMENT=    Hyper-fast Python module for computing CRC checksums
WWW=        https://github.com/overcat/fastcrc

LICENSE=    MIT
LICENSE_FILE=    ${WRKSRC}/LICENSE

USE_GITHUB=    yes
GH_ACCOUNT=    overcat
GH_TAGNAME=    v${DISTVERSION}

USES=        cargo python
USE_PYTHON=    autoplist concurrent pep517

BUILD_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}maturin>=1.5<2.0:devel/py-maturin@${PY_FLAVOR}

CARGO_INSTALL=    no

CARGO_CRATES=    autocfg-1.1.0 \
        crc-3.3.0 \
        crc-catalog-2.4.0 \
        heck-0.5.0 \
        indoc-2.0.5 \
        libc-0.2.132 \
        memoffset-0.9.0 \
        once_cell-1.21.3 \
        paste-1.0.15 \
        portable-atomic-1.9.0 \
        proc-macro2-1.0.89 \
        pyo3-0.26.0 \
        pyo3-build-config-0.26.0 \
        pyo3-ffi-0.26.0 \
        pyo3-macros-0.26.0 \
        pyo3-macros-backend-0.26.0 \
        quote-1.0.37 \
        syn-2.0.82 \
        target-lexicon-0.13.3 \
        unicode-ident-1.0.4 \
        unindent-0.2.3

do-build:
    cd ${WRKSRC} && \
        ${SETENV} ${MAKE_ENV} ${CARGO_ENV} \
        ${PYTHON_CMD} -m maturin build \
        --release \
        --strip \
        -i ${PYTHON_CMD} \
        --compatibility off \
        --out ${WRKSRC}/dist

.include <bsd.port.mk>
 
I will test that next and report back. Since I hate rust and you are well advanced let me drop off fastcrc and pickup an attempt at dronecan
 
then they crossed a bulldog with a rhinoceros, I also lost so much with these errors, so collect DroneCAN dependency
 
Yea I don't know how to overcome py-setuptools =>75. Probably somewhere somebody is working on it. This is why I wondered earlier how strict versioning was here. I knew we dragged late on stuff.
 
Makefile DroneCAN ? [try to find the term, there might be something to do in the examples
Code: 
 grep -rn "py-setuptools =>75" /usr/ports
 
Funny grepping for stuff from /usr/ports has been my crutch. -nr though

Well since we are dealing with an OS that may have python version problems you need to consider this.
Are you using cutting edge version of ArduPilot or release version?

Another consideration is ports-managment. Dropping 20 new ports by non-committers probably will languish.
Maybe instead do a couple at a time. We need to have a ports committer to submit them or help usher then along.
If I read you instructions right there are no BASE FreeBSD modifications at all correct?

We have a process for base system modifications called Phab. It wold be used in large project like this.
So progress can be tracked and commits picked up. Comments added.

I don't know what to do with a large port like this...
 
What about upstreaming some of the patches you developed? Do they seem receptive upstream? Maybe we should open a PR there announcing your work for FreeBSD support. Include patches.
See if anybody answers.

We have a large Python Team when I was looking at info. Maybe announce in that group or RFC.
 
I took the scenic path by trying to build all different versions of py-setuptools back to 70.1.
The reason is we have 63.1 in ports and it uses no patches at all. I guess there is a reason the newer versions are not in ports. It is a broke build.

I noticed that 81.0 was mentioned and started with that version.
The "Current Effort" link leads to a closed PR from 2023 and I don't see how it directly relates to v81.0.
Where that body of code work is I would like to know.
 
When building ArduPilot firmware, the ARM GCC EABI toolchain is required. Should I provide a port for it, or is it expected that users will install it separately?
 
No it should be provided to make the port build. Build requires. But this brings up a good point. Other arch's.
Something else to consider. Breaking these into separate ports instead of a giant metaport.. Some people might only want one part of the suite.

I have some time today and plan on picking though the py-setuptools PR to see what I learn.
We would not want to make a port w/patch based on preliminary work but knowing what it will take once >v75.0 hits helps.

I bought a controller finally. Matek F405 Wing v2. I didn't know the F405 designator is the suffix of the processor.
 
You must log in or register to reply here.
Back
Top