Zima Blade

Mi sono preso una Zima Blade attirato piu' che altro dal basso consumo e di avere la possibilita' di avere uscita SATA per dischi esterni

Sul dispositivo e' preinstallato CasaOS ma di fatto e' una Debian 11 con il solo utente root e password casaos

 

Inserire la ram non e' banale perche' bisogna un po' forzare sulla cornice esterna in plastica.

Una grossa limitazione e' l'unica porta USB (almeno e' USB3) e l'uscita miniDP (che di fatto si usa solo per la prima configurazione ma oggi come oggi era piu' comoda una HDMI)

 Per rimuovere all'avvio CasaOs e' sufficiente disabilitare i seguenti servizi

casaos-app-management.service
casaos-gateway.service
casaos-local-storage.service
casaos-message-bus.service
casaos.service
casaos-user-service.service
 

Il dispositivo non e' velocissimo (ho preso la versione base per non spendere troppo) ma fa il suo lavoro

ODM ed FFMPEG

E' possibile utilizzare ffmpeg per estrarre fotogrammi (a cadenza a scelta dell'utente) da un filmato MP4 per fornirli in pasto ad ODM. Dalle prove che ho fatto e' un sostituto idoneo a scattare una serie di foto 

il seguente comando estrae un fotogramma al secondo (parametro dopo t-prev_selected_t) e li salva nel folder /frames

ffmpeg -i 20240229_094358.mp4 -vf "select=bitor(gte(t-prev_selected_t\,1)\,isnan(prev_selected_t))" -vsync 0 ./frames/f%09d.jpg

Rete neurale ed Aruco

Per alcune prove con gli Aruco tags sto usando una camera che ha come formato di output JPG ma sarebbe piu' idoneo il formato PNG 

Ho provato la rete neurale a questo link che permette di ricostruire dettagli che si sono persi al momento della compressione JPG.

Ho usato un set di immagini processandole come segue

alias enhance='function ne() { docker run --rm -v "$(pwd)/`dirname ${@:$#}`":/ne/input -it alexjc/neural-enhance ${@:1:$#-1} "input/`basename ${@:$#}`"; }; ne'
for x in ./originali/*.jpg; do
    #echo $x
    enhance --zoom=1 --model=repair $x
done

e mettendo a confronto le coordinate degli stessi aruco tags nel set jpg ed in quello elaborato dalla rete neurale e salvato in png

Per dare un'idea la prima immagine e' un originale in JPG

 

la seconda e' la stessa immagine processata dalla rete neurale e salvata in PNG

 

Nei grafici sottostanti i risultati (nei grafici rosso=set PNG, blu=set JPG)

In sintesi le coordinate dei tag sono molto simili ma

1) il dato PNG non ha mostrato outliers ed errori come invece quello JPG

2) nel set PNG il riconoscimento di tag lontani era circa il doppio rispetto al set JPG

3) a parte i punti 1 e 2 il processing tramite rete neurale ma non ha migliorato in modo sensibile la qualita' dell'algoritmo di posizionamento dei tags

 

 

Realsense Docker

Aggiornamento:

Il container e' disponibile gia' compilato su Docker.com al mio account

https://hub.docker.com/repository/docker/c1p81/realsense_2004/general

 ============================================

Ho deciso di tirare fuori dal cassetto la D415 Realsense e come al solito montare l'SDK diventa sempre piu' difficile a causa delle politiche di Intel di dismissione dei propri dispositivi

 

Stavolta volevo provare la strada dell'ambiente docker ma ne' il container ufficiale ne' alcuni trovati su docker hub risultavano completamente funzionanti e me lo sono scritto da solo

(da modificare l'image_id)

Bash

docker run -it --rm  --privileged  -v /dev:/dev  -v "$HOME:/home/luca/"   --device-cgroup-rule "c 81:* rmw"     --device-cgroup-rule "c 189:* rmw"   b105279d1264 /bin/bash

Realsense Viewer

xhost +

docker run -d  --net=host --env="DISPLAY" --volume="$HOME/.Xauthority:/root/.Xauthority:rw"   -v /dev:/dev    --device-cgroup-rule "c 81:* rmw"     --device-cgroup-rule "c 189:* rmw"   2bd94ff6bc38 realsense-viewer

 

Save to disk

docker run -it --rm --privileged    -v /dev:/dev  -v "$HOME:/home/luca/"   --device-cgroup-rule "c 81:* rmw"     --device-cgroup-rule "c 189:* rmw"   34ea465a203e sh -c "cd /home/luca && rs-save-to-disk"

per creare il docker si usa il comando

docker build -t 20_04_real .

con il seguente Dockerfile

FROM public.ecr.aws/lts/ubuntu:20.04_stable

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update \

&& apt-get install -qq -y --no-install-recommends \

build-essential \

cmake \

lsb-release \

git \

curl \

libssl-dev \

libusb-1.0-0-dev \

pkg-config \

libudev-dev \

libgtk-3-dev \

libglfw3-dev \

libgl1-mesa-dev \

libglu1-mesa-dev \

curl \

python3 \

python3-dev \

python3-pip \

libopencv-dev \

python3-opencv \

python3-numpy \

ca-certificates \

&& rm -rf /var/lib/apt/lists/*

RUN mkdir -p /etc/apt/keyrings

RUN curl -sSf https://librealsense.intel.com/Debian/librealsense.pgp | tee /etc/apt/keyrings/librealsense.pgp > /dev/null

RUN echo "deb [signed-by=/etc/apt/keyrings/librealsense.pgp] https://librealsense.intel.com/Debian/apt-repo `lsb_release -cs` main" | tee /etc/apt/sources.list.d/librealsense.list

RUN apt-get update

RUN apt-get -y install librealsense2-dkms librealsense2-utils librealsense2-dev librealsense2-dbg librealsense2-udev-rules mc nano locales

RUN apt-get clean

RUN pip install pyrealsense2

RUN git clone https://github.com/IntelRealSense/librealsense

RUN cd librealsense

RUN mkdir /librealsense/build

WORKDIR /librealsense/build

RUN cmake ../ -DBUILD_EXAMPLES=true

RUN make

ODM

 Ho provato a vedere se ODM poteva essere idoneo per misurare l'altezza di un cumulo (o di una collinetta) usando fotogrammetria da terra con la camera del telefono cellulare

In un sito di prova e' stato verificato un errore inferiore a 30 cm su 5 m di altezza

Metashape vs ODM

Aggiornamento

Modificando il parametro da Volume Analysis a Model 3D, ODM ha un risultato comparabile con Metashape

Sto provando a fare fotogrammetria da terra tramite ODM e WEBODM  confrontando con Metashaoe

Per riferimento ho preso una piccola collina ad anfiteatro con 208 immagini riprese muovendosi attorno alla collina. ODM non riesce a capire che si tratta dello stesso oggetto e crea dei piani ognuno relativo al lato del perimetro su cui sono state fatte le foto, Metashape invece riesce a collegare i transetti ortogonali del lati dell'area e ricrea un unico oggetto geometricamente corretto

Un altro aspetto non trascurabile e' il tempo di calcolo: con parametri di default e con lo stesso numero di immagini Metashape su M1 ha impiegato meno di 15 minuti per terminare il calcolo, ODM su docker x86 ha impiegato oltre un'ora

Oggetto di riferimento

Se invece si fa un solo transetto come qui ODM risulta corretto anche dal punto di vista delle dimensioni stimate

Mesh creata con Metashape

Mesh creata con ODM

PointCloud da Metashape

PointCloud da ODM

Ferrari Fiorano 14 febbraio