Pi Zero compatability confirmed!

highmatergogo

We noticed today that notochord was only using about 12% CPU and a few % of RAM so I wondered if a pi zero would cope with it. I was bored this evening so gave it a go and so far it seems to work perfectly!

Building the source code took a while, obviously, as the pi zero only has one core vs the four cores of the pi 3 B+.

The only change from the wiki docs for pi setup I did was running

scons -j3 debug=1

Without the -j3 flag.

I've only tried one kceptor but I'll try a full suit tomorrow and report back.

EDIT: Oh! And, of course, you need the Rasbian Stretch Lite OS!

shloopmoop

Hey @highmatergogo, How did your testing go for the pi zero? Im very curious.

highmatergogo

Hey @shloopmoop apologies for the delay. I only tested one K-Ceptor and it seemed to work perfectly. I suspect that it would struggle with more K-Ceptors but I didn't get around to testing.

I'm super busy at the moment but if I get time I will test more.

daylanKifky

highmatergogo
It might also be able to deal with more KCeptors. In a RPi3 with 15 KCs the notochord uses about 10% of one Core

valor

daylanKifky and highmatergogo That's great.
Once my Mini K-ceptors and Mini HUBs are tested by others, and confirmed to work fine I'm thinking about jumping on designing Finger ceptors with PI Zero W integrated HUB and FFC cables...since we can now power the PI Zero W from a Mini K-ceptor.

highmatergogo

Yes, we noticed that, that's exactly why we gave the zero a go 😀

highmatergogo

valor Awesome. That's a great idea!

joseph

Hey, all. I hope it's okay that I'm bumping a two-year-old thread. I just got my Chordata in the mail and realized I allocated my RPi4 to a work project already. Here's what I ended up doing to try and get it working in the time since:

First, the image on the site won't boot -- it's 64 bit and the Zero W is 32 bit. I grabbed the 32 bit (Lite?) OS, as noted by highmatergogo in the first post.

I set up wifi and 'touched /boot/ssh' before you ejecting the CF disk.

The RPi was up and running, so I installed aptitude, scons, git, and build-essentials.

I cloned the repo: git clone https://gitlab.com/chordata/notochord-module.git.

Running make setup gave this error:

E: Unable to locate package python3.7-distutils
E: Couldn't find any package by glob 'python3.7-distutils'
E: Package 'python3.7' has no installation candidate
E: Unable to locate package python3.7-dev
E: Couldn't find any package by glob 'python3.7-dev'
make: *** [Makefile:80: install-deps] Error 100

So I swapped python-3.9 because it's already available for the RPi. I just edited the Makefile to change this.

The setup-submodules command will attempt to install lxml for Python, which will fail due to a hash mismatch. Might be because of my 32-bit version or, more likely, because of the Python 3.9 version. The problem is one of the submodules has a hash mismatch. I tried purging the Pipfile.lock, but I think it's in a submodule that the hashes are located. This is where I'm stuck now. Going to try purging the submodule folder.

Update: After purging the .local and Pipfile.lock, I'm still hitting the 'Can't install package' issue.

ERROR: Couldn't install package: [Requirement(_name='lxml', vcs=None, req=NamedRequirement(name='lxml', version='==4.9.1', req=Requirement.parse('lxml==4.9.1'), extras=[], editable=False, _parsed_line=<Line (editable=False, name=lxml, path=None, uri=None, extras=(), markers=None, vcs=None, specifier===4.9.1, pyproject=None, pyproject_requires=None, pyproject_backend=None, ireq=lxml==4.9.1)>), markers=None, _specifiers='==4.9.1', index='pypi', editable=False, hashes=frozenset({'sha256:9f36de4cd0c262dd9927886cc2305aa3f2210db437aa4fed3fb4940b8bf4592c', 'sha256:8d1a92d8e90b286d491e5626af53afef2ba04da33e82e30744795c71880eaa21', 'sha256:ef72013e20dd5ba86a8ae1aed7f56f31d3374189aa8b433e7b12ad182c0d2dfb', 'sha256:c4b2e0559b68455c085fb0f6178e9752c4be3bba104d6e881eb5573b399d1eb2', 'sha256:e8f0c9d65da595cfe91713bc1222af9ecabd37971762cb830dea2fc3b3bb2acf', 'sha256:603a464c2e67d8a546ddaa206d98e3246e5db05594b97db844c2f0a1af37cf5b', 'sha256:eea5d6443b093e1545ad0210e6cf27f920482bfcf5c77cdc8596aec73523bb7e', 'sha256:93e414e3206779ef41e5ff2448067213febf260ba747fc65389a3ddaa3fb8715', 'sha256:be9eb06489bc975c38706902cbc6888f39e946b81383abc2838d186f0e8b6a9d', 'sha256:e5f66bdf0976ec667fc4594d2812a00b07ed14d1b44259d19a41ae3fff99f2b8', 'sha256:04da965dfebb5dac2619cb90fcf93efdb35b3c6994fea58a157a834f2f94b318', 'sha256:fe17d10b97fdf58155f858606bddb4e037b805a60ae023c009f760d8361a4eb8', 'sha256:f05251bbc2145349b8d0b77c0d4e5f3b228418807b1ee27cefb11f69ed3d233b', 'sha256:079b68f197c796e42aa80b1f739f058dcee796dc725cc9a1be0cdb08fc45b000', 'sha256:4cfbe42c686f33944e12f45a27d25a492cc0e43e1dc1da5d6a87cbcaf2e95627', 'sha256:5974895115737a74a00b321e339b9c3f45c20275d226398ae79ac008d908bff7', 'sha256:a60f90bba4c37962cbf210f0188ecca87daafdf60271f4c6948606e4dabf8785', 'sha256:27e590352c76156f50f538dbcebd1925317a0f70540f7dc8c97d2931c595783a', 'sha256:ae06c1e4bc60ee076292e582a7512f304abdf6c70db59b56745cca1684f875a4', 'sha256:0538747a9d7827ce3e16a8fdd201a99e661c7dee3c96c885d8ecba3c35d1032c', 'sha256:0645e934e940107e2fdbe7c5b6fb8ec6232444260752598bc4d09511bd056c0b', 'sha256:4780677767dd52b99f0af1f123bc2c22873d30b474aa0e2fc3fe5e02217687c7', 'sha256:a614e4afed58c14254e67862456d212c4dcceebab2eaa44d627c2ca04bf86837', 'sha256:f9ced82717c7ec65a67667bb05865ffe38af0e835cdd78728f1209c8fffe0cad', 'sha256:1e1cf47774373777936c5aabad489fef7b1c087dcd1f426b621fda9dcc12994e', 'sha256:2aaf6a0a6465d39b5ca69688fce82d20088c1838534982996ec46633dc7ad6cc', 'sha256:6d949f53ad4fc7cf02c44d6678e7ff05ec5f5552b235b9e136bd52e9bf730b91', 'sha256:927a9dd016d6033bc12e0bf5dee1dde140235fc8d0d51099353c76081c03dc29', 'sha256:32a73c53783becdb7eaf75a2a1525ea8e49379fb7248c3eeefb9412123536387', 'sha256:6eafc048ea3f1b3c136c71a86db393be36b5b3d9c87b1c25204e7d397cee9536', 'sha256:4d5bae0a37af799207140652a700f21a85946f107a199bcb06720b13a4f1f0b7', 'sha256:edffbe3c510d8f4bf8640e02ca019e48a9b72357318383ca60e3330c23aaffc7', 'sha256:b122a188cd292c4d2fcd78d04f863b789ef43aa129b233d7c9004de08693728b', 'sha256:c62e8dd9754b7debda0c5ba59d34509c4688f853588d75b53c3791983faa96fc', 'sha256:bd34f6d1810d9354dc7e35158aa6cc33456be7706df4420819af6ed966e85448', 'sha256:bcaa1c495ce623966d9fc8a187da80082334236a2a1c7e141763ffaf7a405067', 'sha256:fe749b052bb7233fe5d072fcb549221a8cb1a16725c47c37e42b0b9cb3ff2c3f', 'sha256:c852b1530083a620cb0de5f3cd6826f19862bafeaf77586f1aef326e49d95f0c', 'sha256:206a51077773c6c5d2ce1991327cda719063a47adc02bd703c56a662cdb6c58b', 'sha256:487c8e61d7acc50b8be82bda8c8d21d20e133c3cbf41bd8ad7eb1aaeb3f07c97', 'sha256:4beea0f31491bc086991b97517b9683e5cfb369205dac0148ef685ac12a20a67', 'sha256:f1be258c4d3dc609e654a1dc59d37b17d7fef05df912c01fc2e15eb43a9735f3', 'sha256:10d2017f9150248563bb579cd0d07c61c58da85c922b780060dcc9a3aa9f432d', 'sha256:41fb58868b816c202e8881fd0f179a4644ce6e7cbbb248ef0283a34b73ec73bb', 'sha256:57e4d637258703d14171b54203fd6822fda218c6c2658a7d30816b10995f29f3', 'sha256:b570da8cd0012f4af9fa76a5635cd31f707473e65a5a335b186069d5c7121ff2', 'sha256:9232b09f5efee6a495a99ae6824881940d6447debe272ea400c02e3b68aad85d', 'sha256:dad7b164905d3e534883281c050180afcf1e230c3d4a54e8038aa5cfcf312b84', 'sha256:4e285b5f2bf321fc0857b491b5028c5f276ec0c873b985d58d7748ece1d770dd', 'sha256:287605bede6bd36e930577c5925fcea17cb30453d96a7b4c63c14a257118dbb9', 'sha256:9c3a88d20e4fe4a2a4a84bf439a5ac9c9aba400b85244c63a1ab7088f85d9d25', 'sha256:8f0a4d179c9a941eb80c3a63cdb495e539e064f8054230844dcf2fcb812b71d3', 'sha256:13c90064b224e10c14dcdf8086688d3f0e612db53766e7478d7754703295c7c8', 'sha256:1355755b62c28950f9ce123c7a41460ed9743c699905cbe664a5bcc5c9c7c7fb', 'sha256:1a7c59c6ffd6ef5db362b798f350e24ab2cfa5700d53ac6681918f314a4d3b94', 'sha256:1436cf0063bba7888e43f1ba8d58824f085410ea2025befe81150aceb123e345', 'sha256:1423631e3d51008871299525b541413c9b6c6423593e89f9c4cfbe8460afc0a2', 'sha256:86e92728ef3fc842c50a5cb1d5ba2bc66db7da08a7af53fb3da79e202d1b2cd3', 'sha256:d9fc0bf3ff86c17348dfc5d322f627d78273eba545db865c3cd14b3f19e57fa5', 'sha256:5ef87fca280fb15342726bd5f980f6faf8b84a5287fcc2d4962ea8af88b35130', 'sha256:98cafc618614d72b02185ac583c6f7796202062c41d2eeecdf07820bad3295ed', 'sha256:6d279033bf614953c3fc4a0aa9ac33a21e8044ca72d4fa8b9273fe75359d5cca', 'sha256:6daa662aba22ef3258934105be2dd9afa5bb45748f4f702a3b39a5bf53a1f4dc', 'sha256:6653071f4f9bac46fbc30f3c7838b0e9063ee335908c5d61fb7a4a86c8fd2036', 'sha256:6ca2264f341dd81e41f3fffecec6e446aa2121e0b8d026fb5130e02de1402785', 'sha256:830c88747dce8a3e7525defa68afd742b4580df6aa2fdd6f0855481e3994d391', 'sha256:21fb3d24ab430fc538a96e9fbb9b150029914805d551deeac7d7822f64631dfc', 'sha256:0f3f0059891d3254c7b5fb935330d6db38d6519ecd238ca4fce93c234b4a0f73', 'sha256:8caf4d16b31961e964c62194ea3e26a0e9561cdf72eecb1781458b67ec83423d', 'sha256:4878e667ebabe9b65e785ac8da4d48886fe81193a84bbe49f12acff8f7a383a4'}), extras=(), abstract_dep=None, _line_instance=<Line (editable=False, name=lxml, path=None, uri=None, extras=(), markers=None, vcs=None, specifier===4.9.1, pyproject=None, pyproject_requires=None, pyproject_backend=None, ireq=lxml==4.9.1)>, _ireq=None)]

I'm looking for where this hash appears, but it looks like it's auto-generated from somehwhere and then added to the lock file? I'll try and hack around it. Just have to get the submodules installed and built.

/home/joseph/.local/share/virtualenvs/notochord-module-4zc6H2Qp/bin/python /home/joseph/.local/lib/python3.9/site-packages/pipenv/patched/pip/__pip-runner__.py install -i https://pypi.org/simple --no-input --upgrade --no-deps --exists-action=i -r /tmp/pipenv-wm21z3o2-requirements/pipenv-vli02zgd-hashed-reqs.txt
Using source directory: '/home/joseph/.local/share/virtualenvs/notochord-module-4zc6H2Qp/src'
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple

Collecting lxml==4.9.1

  Using cached https://www.piwheels.org/simple/lxml/lxml-4.9.1-cp39-cp39-linux_armv6l.whl (6.7 MB)

ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
    lxml==4.9.1 from https://www.piwheels.org/simple/lxml/lxml-4.9.1-cp39-cp39-linux_armv6l.whl#sha256=8c6c812e0284a452ed567ce1ec33c0b4c51a1e3111b350f5b061618e99fb29e4 (from -r /tmp/pipenv-wm21z3o2-requirements/pipenv-vli02zgd-hashed-reqs.txt (line 1)):

UPDATE 2:
I found this: https://github.com/pypa/pipenv/issues/2540 Looks like piwheels is not in the Pipfile, so the 64-bit hashes are getting used. I just made the swap and am trying to do a build again.

UPDATE 3:
All is not well in waffleville.

Locking [packages] dependencies...
⠇ INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending(State(mapping=OrderedDict([('lxml', LinkCandidate('https://files.pythonhosted.org/packages/70/bb/7a2c7b4f8f434aa1ee801704bf08f1e53d7b5feba3d5313ab17003477808/lxml-4.9.1.tar.gz (from https://pypi.org/simple/lxml/) (requires-python:>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=
Locking [dev-packages] dependencies...
⠹ pipenv.exceptions.ResolutionFailure: ERROR: No matching distribution found for cython
joseph@raspberrypi:~/notochord-module $ vi ./Pipfile

So for some reason LXML and cython aren't getting along? Or, at least, cython isn't found. There should be a {version="*", index="piwheels"} in the Pipfile, so I'm not sure why it's saying none can be found. Trying to install it manually:

joseph@raspberrypi:~/notochord-module $ python3.9 -m pipenv install cython
Installing cython...
Pipfile.lock (e4122c) out of date, updating to (3f4329)...
Locking [packages] dependencies...
Locking [dev-packages] dependencies...
⠙ ✘ Locking Failed!
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot install cython because these package versions have conflicting dependencies.
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/resolver.py", line 811, in _main
[ResolutionFailure]:       resolve_packages(
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/resolver.py", line 759, in resolve_packages
[ResolutionFailure]:       results, resolver = resolve(
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/resolver.py", line 738, in resolve
[ResolutionFailure]:       return resolve_deps(
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 1100, in resolve_deps
[ResolutionFailure]:       results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 899, in actually_resolve_deps
[ResolutionFailure]:       resolver.resolve()
[ResolutionFailure]:   File "/home/joseph/.local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 687, in resolve
[ResolutionFailure]:       raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

Hmm.

UPDATE 4:
I caved, added --skip-lock to just get everything installed. Moving to the next step of setup.

My final Pipfile:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[[source]]
url = "https://www.piwheels.org/simole"
name = "piwheels"
verify_ssl = true

[dev-packages]
scons = { version = "==4.2.0", index = "piwheels" }
pytest = { version = "*", index = "piwheels" }
pytest-cov = { version = "*", index = "piwheels" }
cython = { version = "*", index = "piwheels" }
scons-compiledb = { version = "==0.4.7", index = "piwheels" }
smbus2 = { version = "*", index = "piwheels"}
pygltflib = { version = "*", index = "piwheels"}
numpy = { version = "*", index = "piwheels"}

[packages]
lxml = ">=4.5"
cython = "*"

[requires]
python_version = "3"

UPDATE 5:

make fails almost immediately with "DuplicateSectionError: While reading from 'Pipfile' [line 6]: section '[source' already exists:". That's allowed, I thought, but the internet says it's a strict mode thing: https://github.com/pypa/pip/issues/8373

I edited the SConstruct file and set strict to false. It's pretty late now, so I think I'll come back to this tomorrow.

daylanKifky

Hello joseph and many thanks for this valuable feedback!

The notochordOS image that we currently offer is in fact targeted to the RPi 3/4 with a 64 bits system. Our team is currently focusing in deliver a basic software set, so everyone get's to use their kit as soon as possible. But we will for sure be updating it to expand it's compatibility for other systems.

A couple of things to point out:

We created the notochord OS repository which contains a set of scripts to automatically install and configure everything necessary to use a RPi within the Chordata framework. You will find instructions in the README. It's currently targeted at a 64 bits systems, but perhaps you can make a couple of tweaks to it to adapt it to the 32bits one.

probably the main change you would have to make is in the file extract_noto_artifact.sh

By the way, there's an automatic compilation of the notochord-module set in gitlab CI/CD for arm64 and armhf. So you can directly grab that instead of compiling the module (which already takes some time in a RPi 3, doing it in the Zero must have been a long process, right?). As you will see the extract_noto_artifact.sh is grabbing the compiled module and extracting it in the RPI. changing the ?job=arm64 to ?job=armhf part of the URL there should install the correct version for the Zero.

There's also chordata_conf.ini which contains many configuration variables. You can, for example, globally change the python version used from there.

(perhaps adding a new configuration var for the architecture and using it in extract_noto_artifact.sh would be a clean way to do it.. As you know we accept PR for any of our repositories 😉)

If you try this way please let us know if you encounter any more troubles with the Pipfile.lock. We are currently using it to unify the library versions used among all the implementations of the notochord, but given yours and other internal small compatibility issues we encounter recently probably the best way to go is removing it from the notochord repository completely. This will force pipfile to behave as with the --skip-lock flag by default

Let me know if this solution works for you or if you need any more feedback on our side.

PS: the README tells you to use a one-line command to directly fetch and run the notochordOS setup scripts as their are in the remote repository. If you want to make some mods to the scripts take a look at the fetch_and_run.sh file and manually execute those lines

daylanKifky

daylanKifky By the way, I assume you are one of our backers. Is that correct? I would give you the Kickstarter badge then

joseph

daylanKifky Correct. I'm one of the backers!

Also, I was just about to post an update. I realized only this morning that I should have been using the notochordOS repo and NOT the module. 🤦

I might edit my post above to pull out the info because it could be distracting to new users and this forum post is the only search result so far for "Zero". I'll report back when I get it running.

joseph

Just an update on this. Had it running in the background all of yesterday. There were a few failures.

The most time consuming one was user error. I read "== it might take from several minutes up to a couple of hours
Press any key to continue or Ctrl+C to abort." and skipped over 'press any key to continue' and just read 'Press Ctrl+C to abort', so I waited a day, came back, and reread it. D'oh.

There was some trouble with resolving raspberrypi. Should be looking for raspberrypi.local, I think, but that didn't really block anything that I could tell.

Created symlink /etc/systemd/system/hostapd.service → /dev/null.
Processing triggers for man-db (2.9.4-2) ...
sudo: unable to resolve host raspberrypi: Name or service not known
Removed /etc/systemd/system/hostapd.service.
sudo: unable to resolve host raspberrypi: Name or service not known
Synchronizing state of hostapd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable hostapd
== Backing up existing DHCPCP configuration
== Writing DHCPCP configuration
sudo: unable to resolve host raspberrypi: Name or service not known
interface wlan0
sudo: unable to resolve host raspberrypi: Name or service not known
    static ip_address=192.168.85.1/24
sudo: unable to resolve host raspberrypi: Name or service not known
    nohook wpa_supplicant
== Backing up existing DNSMASQ configuration
sudo: unable to resolve host raspberrypi: Name or service not known
== Writing DNSMASQ configuration
sudo: unable to resolve host raspberrypi: Name or service not known
interface=wlan0
sudo: unable to resolve host raspberrypi: Name or service not known
dhcp-range=192.168.85.2,192.168.85.20,255.255.255.0,24h
sudo: unable to resolve host raspberrypi: Name or service not known
domain=wlan     # Local wireless DNS domain
sudo: unable to resolve host raspberrypi: Name or service not known
address=/notochord.wlan/192.168.85.1
== Writing HOSTAPD configuration
cp: cannot stat '/etc/hostapd/hostapd.conf': No such file or directory
Original hostapd.conf not found, could not backup
sudo: unable to resolve host raspberrypi: Name or service not known
== Setting WIFI country rc.local script
>> AUTO WIFI COUNTRY SET init @ 2022-11-27T15:06:54+00:00
>> Auto script added to /etc/rc.local
sudo: unable to resolve host raspberrypi: Name or service not known
>> AUTO WIFI COUNTRY SET: No country code file found, nothing done
== unblocking WLAN
sudo: unable to resolve host raspberrypi: Name or service not known
== Backing up current configuration
== Install notochord-module..

No. The real hiccup was, unsurprisingly, lxml, which again failed to build. I'll go back and re-review the instructions above. It's no secret I have a bit of animus for lxml. I think this just got killed for OOM issues, but I'll give it another go when I have the chance. Here's the LXML error:

      building 'lxml.etree' extension
      creating build/temp.linux-armv6l-3.9
      creating build/temp.linux-armv6l-3.9/src
      creating build/temp.linux-armv6l-3.9/src/lxml
      arm-linux-gnueabihf-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -ffile-prefix-map=/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -ffile-prefix-map=/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -I/usr/include/libxml2 -Isrc -Isrc/lxml/includes -I/usr/include/python3.9 -c src/lxml/etree.c -o build/temp.linux-armv6l-3.9/src/lxml/etree.o -w
      arm-linux-gnueabihf-gcc: fatal error: Killed signal terminated program as
      compilation terminated.
      Compile failed: command '/usr/bin/arm-linux-gnueabihf-gcc' failed with exit code 1
      creating tmp
      cc -I/usr/include/libxml2 -I/usr/include/libxml2 -c /tmp/xmlXPathInitr0wuut8o.c -o tmp/xmlXPathInitr0wuut8o.o
      cc tmp/xmlXPathInitr0wuut8o.o -lxml2 -o a.out
      error: command '/usr/bin/arm-linux-gnueabihf-gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for lxml

UPDATE:

Already up to date.
== Getting pre-compiled notochord module
== Fetching notochord-module artifacts on branch master from gitlab CI/CD
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   147  100   147    0     0    201      0 --:--:-- --:--:-- --:--:--   201
100   484  100   484    0     0    512      0 --:--:-- --:--:-- --:--:--   512
100 1425k  100 1425k    0     0   655k      0  0:00:02  0:00:02 --:--:-- 2017k
Archive:  /tmp/artifacts.zip
  inflating: /tmp/module_tar/multiarch/arm-linux-gnueabihf-notochord-module-6381c7b4.tar.bz2
tar: /tmp/module_tar/multiarch/arm-linux-gnueabihf-notochord-module-6381c7b4.tar.bz2: Not found in archive
tar: Exiting with failure status due to previous errors

Looks like there's some kind of unzip issue? Maybe just a weird name change, but I think it's easy enough to work around. I'll do that and comment out the steps in extract_noto_artifact.

daylanKifky

joseph 'press any key to continue' and just read 'Press Ctrl+C to abort', so I waited a day, came back, and reread it. D'oh.

oh sorry to hear that!

joseph There was some trouble with resolving raspberrypi. Should be looking for raspberrypi.local, I think, but that didn't really block anything that I could tell.

Yes that shouldn't be blocking the rest of the script. But it's strange to be happening. Did you run the script in a fresh raspi-os SD card? or did it have some previous configuration.

The lxml compilation requires hardware resources, particulary RAM memory, which in the Zero is not big. That's probably the issue. You can try running:

pip install lxml

while you use another terminal window to keep an eye on the resources usage with the program: htop

The notochord OS setup script should have set 512M of SWAP memory. So when the lxml compilation starts you should see the RAM usage raise, probably hit the limit, and then the SWAP would start filling up. It might probably also run out of SWAP space.

If this is the case you can raise the SWAP memory, but it would result in a really slow compilation. Otherwise try the following:

Flash a new SD with the 32bit raspi-os
Use the RPI4 you have to run the notochordOS setup script
When the setup is done use the SD card in your Zero

Note: this procedure should work in theory, but it hasn't been tested.
As I said before, we will officially adapt the notochord OS to work out of the box with 32bit systems. Given your experience it would probably involve pre-compiling the lxml module and fetching it from the raspberry so you can skip local compilation. All these steps would require some time and our team is currently focused on publishing the required software and documentation to allow all our backers to use the suite as soon as possible.
So if you are able to try the proposed steps it would be great!

Let us know how it goes

joseph

daylanKifky

Appreciate the reply. It's definitely an OOM error. dmesg | tail shows:

[247602.190761] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),global_oom,task_memcg=/,task=as,pid=12172,uid=0
[247602.191036] Out of memory: Killed process 12172 (as) total-vm:385380kB, anon-rss:331244kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:380kB oom_score_adj:0

Swapping the SD card is really clever. 😆 If I can't make this work I might try, but the Raspberry Pi 4 is currently being used to host the printer at the office and I think people might notice if I took it down. I'll see about bumping the swap or running the pip install separately.

Jump

How much ram does the pi need to have to run properly? I was also considering trying a pi alternative

joseph

Jump Probably more than 512MB, which is what the zero has. I haven't messed with it since the last update -- busy week. I might have to put this on hold until I can get my hands on another full-size RPi.

daylanKifky

Under normal usage thee current version of the software (notochord module + notochord control server) uses no more than 100M of RAM, and a small amount of 2 processing CPU cores: <40% on one and <15% of another. This has been benchmarked in a RPi 3B with a 15 sensor gear running at 100Hz.

We will be adding new processing tasks to the notochord in the future so this might change, but for the moment it should work properly under the RPi Zero processing capacities.

Compilation would probably require about 1.5Gb, so doing it on the zero might be a real pain. We added armhf cross compilation to the notochord module CI/CD, so you can download the pre-compiled module from here: https://gitlab.com/chordata/notochord-module/-/jobs/artifacts/master/browse/multiarch?job=armhf

The problem remains lxml which is being compiled by pip in this case.

joseph

Swap files to the rescue!

I gave everything another shot on the Zero W. I think there have been some updates to the automatic script, but the real victory came from adding some swap space. If future folks are running OOM while doing the lxml build, try this:

# Allocate a file in root called 'swapfile' and give it ~512 megs of space.
sudo dd if=/dev/zero of=/swapfile bs=1024 count=500000
# Use the built in 'mkswap' to make it a swap file and turn on memory swapping.
sudo mkswap /swapfile
sudo swapon /swapfile

Full credit to Edwin Steele for the solution. I thought Linux always set up a default swap but it makes sense it wouldn't for an SD card. Minimizing wear and all that. I don't know if the swap will persist after boots, but I'm checking now.