3DR Solo Drone WiFi Comunicação

Question

Eu tenho dois UAVs 3DR Solo. Eles possuem computadores ARM tanto no drone quanto no controlador rodando o busybox Linux.

Pelo que entendi: Por padrão, o controlador atua como um ponto de acesso sem fio. Tem o SSID: SoloLink. Esta imagem mostra a configuração padrão:

Ocontroladoréacoisacomduasantenasediz"SOLO" na tela e o UAV / drone real é a coisa em forma de X.

Isso funciona bem e eu posso diretamente ssh no controlador ( ssh [email protected] ) e no solo real com ( ssh [email protected] )

Eu posso executar um comando de um utilitário python na página do github do 3DR: github.com/3drobotics/solo-cli/blob/master/soloutils/wifi.py (desculpe, eu só posso ter 2 links por causa da minha reputação) para dizer ao controlador para se conectar a outra rede WiFi. Eu configurei um Ubiquity PicoStation para atuar como um roteador e ter o SSID: ubnt. Para conectar o controlador à rede ubnt , conecto-me à rede SoloLink e executo solo wifi --name=ubnt . O que isso basicamente faz é criar um script bash e executá-lo:

if [ "$#" -lt "2" ]; then
    echo "Usage:   'basename $0' timeout_in_seconds command" >&2
    echo "Example: 'basename $0' 2 sleep 3 || echo timeout" >&2
    exit 1
fi
cleanup()
{{
    trap - ALRM               #reset handler to default
    kill -ALRM $a 2>/dev/null #stop timer subshell if running
    kill $! 2>/dev/null &&    #kill last job
      exit 124                #exit with 124 if it was running
}}
watchit()
{{
    trap "cleanup" ALRM
    sleep $1& wait
    kill -ALRM $$
}}
watchit $1& a=$!         #start the timeout
shift                    #first param was timeout for sleep
trap "cleanup" ALRM INT  #cleanup after timeout
"$@"& wait $!; RET=$?    #start the job wait for it and save its return value
kill -ALRM $a            #send ALRM signal to watchit
wait $a                  #wait for watchit to finish cleanup
exit $RET                #return the value
SCRIPT
cat > /tmp/setupwifi.sh << 'SCRIPT'
# Delete old files
rm /mnt/rootfs.rw/lib/modules/3.10.17-rt12-*/kernel/net/ipv4/netfilter/iptable_filter.ko || true
/etc/init.d/hostapd stop
killall wpa_supplicant || true
killall udhcpc || true
cat <<EOF > /etc/wpa_client.conf
network={{
{credentials}
}}
EOF
echo 1 > /proc/sys/net/ipv4/ip_forward
sed -i.bak 's/dhcp-option=3.*/dhcp-option=3,10.1.1.1/g' /etc/dnsmasq.conf
sed -i.bak 's/dhcp-option=6.*/dhcp-option=6,8.8.8.8/g' /etc/dnsmasq.conf
/etc/init.d/dnsmasq restart
sleep 2
echo 'connecting to the internet...'
wpa_supplicant -i wlan0 -c /etc/wpa_client.conf -B
/tmp/timeout.sh 15 udhcpc -i wlan0 || {{
    echo -e "\nerror: wrong credentials or couldn't connect to wifi network!\n"
    ifconfig wlan0 down
}}
/etc/init.d/hostapd start
sleep 3
wget -O- http://example.com/ --timeout=5 >/dev/null 2>&1
if [[ $? -ne '0' ]]; then
    echo ''
    echo 'error: could not connect to the Internet!'
    echo 'please check your wifi credentials and try again.'
else
    echo 'setting up IP forwarding...'
    insmod /lib/modules/3.10.17-rt12-*/kernel/net/ipv4/netfilter/iptable_filter.ko 2>/dev/null
    iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
    iptables -A FORWARD -i wlan0 -o wlan0-ap -j ACCEPT
    iptables -A FORWARD -i wlan0-ap -o wlan0 -j ACCEPT
    echo ''
    echo 'success: Solo is now connected to the Internet.'
    echo 'if your computer does not yet have Internet access, try'
    echo "disconnecting and reconnecting to Solo's wifi network."
fi
SCRIPT
chmod +x /tmp/timeout.sh
chmod +x /tmp/setupwifi.sh
bash /tmp/setupwifi.sh > /log/setupwifi.log 2>&1

(a parte {credentials} é porque este script está em uma string grande em um script python e substitui essa parte pelas credenciais que eu passei)

Parece ativar o encaminhamento, reconfigurar o dnsmasq, configurar o wpa_supplicant para conectar-se à minha nova rede WiFi, iniciar o wpa_supplicant e reconfigurar o iptables para encaminhar o tráfego de wlan0 para wlan0-ap interfaces e vice-versa. A última instrução if/else que eu modifiquei para que ela não faça o wget e apenas execute o bloco else .

Isso funciona bem e eu posso acessar o controlador a partir da rede ubnt . Minha configuração agora parece: Eu posso ssh para o controlador com ssh [email protected] , mas não vejo o Solo na rede. Tentei nmap -sP 192.168.1.1/24 do laptop e só vejo o roteador ( 192.168.1.1 ), o controlador ( 192.168.1.6 ) e eu ( 192.168.1.76 ).

Isso é onde estou preso

Eu quero poder acessar o drone Solo do computador. Eu entendo que existem duas interfaces no controlador, mas eu não entendo como colmatar.

O propósito disso é que eu possa conectar outro par à mesma rede ubnt e então eu possa monitorar / controlar dois UAV de uma fonte central e um piloto pode estar no circuito para assumir o controle, se necessário.

Qualquer ajuda ou termos do google serão apreciados. Eu não tenho muita experiência com redes e tenho caído em muitos buracos de coelho pesquisando os comandos e termos associados à rede.

    

Answer 1

Na verdade, eu estava vinculado a este artigo por um amigo que queria minha contribuição - também vou compartilhá-lo aqui.

O problema aqui está faltando rotas. Para que seu 192.168.1.76 IP (ou qualquer 192.168.1.x IP) chegue a 10.1.1.x , ele precisa conhecer o caminho. IPs na mesma sub-rede (por exemplo, [ 10.1.1.1 e 10.1.1.10 ] ou [ 192.168.1.76 e 192.168.1.1 ]) não precisam de uma rota para se comunicar; eles usam uma transmissão para encontrar o dispositivo com um determinado IP e enviar o tráfego diretamente.

Para ir de uma sub-rede para outra sub-rede, você precisa definir uma rota. Além disso, você precisa definir uma rota BACK. Então, você pode tentar isso (se o seu roteador e o controlador solo suportarem):

Você precisa de uma rota no seu 192.168.1.1 AP. A origem seria qualquer, o destino seria 10.1.1.0/24 e o próximo salto seria 192.168.1.6 - o controlador Solo. O controlador está ciente de ambas as redes, por isso, se você enviar tráfego destinado a 10.1.1.10 , o Solo deverá já saber como chegar lá, e deverá enviá-lo. Além disso, como o próprio controlador é, efetivamente, o gateway de rede para o drone ( 10.1.1.1 ), e está também ciente da sub-rede 192.168.1.0/24 , que nenhuma rota seria necessária lá - o rota de volta está implícita.

Adicione essa rota ao seu roteador ( any>10.1.1.0/24>192.168.1.6 ) e veja se isso resolve o problema.