Implimentation Problems on a Raspberry Pi

[rolly]

I’m trying to get Monty setup on a 64 bit Arm Raspberry Pi running Bookworm. In " ```
conda env create -f environment_arm64.yml" I get "Solving environment: failed
PackagesNotFoundError: The following packages are not available from current channels:

• pytorch::torchvision
• pytorch::pytorch==1.11.0
• pyg::pyg
• aihabitat::habitat-sim==0.2.2
• mkl[version=‘<2022’]"
  Forgive my low level intrusion into the conversation. Is there a preferred platform for Monty (& am I going to experience much misery trying to do the Monty on a Raspberry Pi)?

[brainwaves]

hi @rolly, first, it’s really cool you’re trying to build monty on a raspberry pi. If you’re going to strap that Raspberry Pi to a robot one day, we’d love to see.

Currently, we’re doing all our development on MacOS, so we haven’t tried what you’re attempting. So, it is an unknown path and probably there will be dragons.

[tslominski]

Hey @rolly .

I wrote environment_arm64.yml with Apple Silicon in mind, but I’m curious about what happens on Raspberry Pi.

The thing with Apple is that they have a built-in x86 emulator. The arm64 installation on Apple Silicon (miniconda version) is lying to conda by claiming it is Intel via the --subdir=osx-64.

What does a Raspberry Pi conda installation output for conda info?

[rolly]

conda info

 active environment : base
active env location : /home/rolly/anaconda3
        shell level : 1
   user config file : /home/rolly/.condarc

populated config files : /home/rolly/anaconda3/.condarc
conda version : 24.9.2
conda-build version : 24.9.0
python version : 3.12.7.final.0
solver : libmamba (default)
virtual packages : __archspec=1=cortex_a72
__conda=24.9.2=0
__glibc=2.36=0
__linux=6.6.51=0
__unix=0=0
base environment : /home/rolly/anaconda3 (writable)
conda av data dir : /home/rolly/anaconda3/etc/conda
conda av metadata url : None
channel URLs : main/linux-aarch64
main/noarch
r/linux-aarch64
r/noarch
package cache : /home/rolly/anaconda3/pkgs
/home/rolly/.conda/pkgs
envs directories : /home/rolly/anaconda3/envs
/home/rolly/.conda/envs
platform : linux-aarch64
user-agent : conda/24.9.2 requests/2.32.3 CPython/3.12.7 Linux/6.6.51+rpt-rpi-2712 debian/12.8 glibc/2.36 solver/libmamba conda-libmamba-solver/24.9.0 libmambapy/1.5.8 aau/0.4.4 c/. s/. e/.
UID:GID : 1000:1000
netrc file : None
offline mode : False

[tslominski]

Thank you.

So, it looks like Habitat will not work for linux-aarch64 without compiling from source, as there are no available distributions:

– https://anaconda.org/search?q=habitat-sim

Similarly, the pytorch channel does not offer pytorch, but there is something on conda-forge, although I don’t know if it is compatible:

– https://anaconda.org/search?q=platform:linux-aarch64+pytorch

Lastly, instead of pyg::pyg from Conda, you’d need torch_geometric from PyPi.

After taking the above constraints into account and working through additional dependency constraints, this is the environment_linux_aarch64.yml file I ended up with (removed Habitat dependencies, switched to conda-forge channel, upgraded Python to 3.9, updated pytorch to 1.13.1, upgraded torchvision to 0.14.0, install torch_geometric via pip):

# This file may be used to create an environment using:
#
# ## Miniconda or Anaconda
#     $ conda env create --file environment_linux_aarch64.yml
# If you are using the zsh shell, run:
#     $ conda init zsh
# Or, if you are using a different shell, run:
#     $ conda init
# After init, if you do not want conda to change your global shell when
# you open a new terminal, run:
#     $ conda config --set auto_activate_base false
# Finally, activate the environment with:
#     $ conda activate tbp.monty
#
# platform: linux-aarch64
name: tbp.monty
channels:
  - defaults
  - conda-forge

dependencies:
  - python=3.9
  - cmake>=3.14.0
  - wget

  - conda-forge::pytorch=1.13.1
  - conda-forge::quaternion=2023.0.3 # later versions missing np.long
  - conda-forge::torchvision=0.14.0

  - pip
  - pip:
      - torch_geometric
      - -e .[dev]

Unfortunately, I don’t have access to a Raspberry Pi, so I have no idea if this dependency configuration will work. All I can tell is that Conda didn’t complain about the dependencies and architecture before running into a trying-to-install-aarch64-on-osx-environment-related problem.

Then, if, the above works, you will run into the problem described in this GitHub issue about Windows OS support, where we discovered that Monty is unintentionally coupled to Habitat. However, a path to decoupling is outlined there as well.

[brainwaves]

@tslominski I have a raspberry pi, lemme know if you want SSH access.

[rolly]

“Condo env create” worked fine using the above yml file on my Raspberry Pi (thanks). pytest failed trying to import habitat.sim & magnum (as you indicated in your GitHub Windows OS support issue).
Not sure where I go from here.

[tslominski]

Thank you for letting us know that the installation was completed without error .

Also, thank you for pointing out the problem with pytest. That’s another place we’ll need to decouple and update the onboarding docs for folks who don’t have the option to run Habitat.

I think further progress on Raspberry Pi will be possible once Monty is decoupled from Habitat.

[rolly]

Don’t mean to put you on the spot, but could you give me some indication of when this decoupling from Habitat might occur. If it’s no time soon, I might persue something like a minimal M4 Mac Mini

[tslominski]

Decoupling from Habitat utilities within a motor policy seems to have little uncertainty (use scipy instead). However, Monty uses the Habitat simulator for testing. Determining the best approach to testing Monty without the Habitat simulator remains an open question.

[tslominski]

I opened pull request #153 to address HabitatSim coupling during benchmark or experiment runs.

[DanML]

For reference pytorch is available on Rasp PI but not in the default pip distro.
You need to pull it direct from torch: ie.
pip3 install https://github.com/pytorch/pytorch/releases/download/v1.9.0/torch-1.9.0-cp37-cp37m-linux_armv7l.whl