Ich habe zwei 3DR Solo UAVs. Sowohl in der Drohne als auch im Controller sind ARM-Computer installiert, auf denen Busybox Linux läuft.
So wie ich das verstehe: Standardmäßig fungiert der Controller als drahtloser Zugangspunkt. Er hat die SSID: SoloLink. Dieses Bild zeigt die Standardkonfiguration:
Der Controller ist das Ding mit den zwei Antennen und auf dem Bildschirm steht „SOLO“ und das eigentliche UAV/die Drohne ist das X-förmige Ding.
Das funktioniert einwandfrei und ich kann per SSH direkt in den Controller ( ) und in das eigentliche Solo mit ( ) einsteigen.ssh [email protected]ssh [email protected]
Ich kann einen Befehl von einem Python-Dienstprogramm auf der GitHub-Seite von 3DR ausführen: github.com/3drobotics/solo-cli/blob/master/soloutils/wifi.py(leider kann ich aufgrund meines Rufs nur 2 Links angeben), um dem Controller mitzuteilen, dass er sich mit einem anderen WLAN-Netzwerk verbinden soll. Ich habe eine Ubiquity PicoStation als Router eingerichtet und sie mit der SSID:ubnt ausgestattet. Um den Controller mit dem ubntNetzwerk zu verbinden, verbinde ich mich mit dem SoloLinkNetzwerk und führe aus solo wifi --name=ubnt. Im Grunde wird dabei ein Bash-Skript erstellt und ausgeführt:
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
(der Teil {credentials} liegt daran, dass sich dieses Skript in einem großen String in einem Python-Skript befindet und diesen Teil durch die Anmeldeinformationen ersetzt, die ich ihm übergebe)
Es scheint, die Weiterleitung zu aktivieren, dnsmasq neu zu konfigurieren, wpa_supplicant so zu konfigurieren, dass eine Verbindung zu meinem neuen WLAN-Netzwerk hergestellt wird, wpa_supplicant zu starten und dann iptables so neu zu konfigurieren, dass der Datenverkehr von wlan0den wlan0-apSchnittstellen und umgekehrt weitergeleitet wird. Die letzte if/elseAnweisung dort habe ich so geändert, dass wget nicht ausgeführt wird, sondern nur der elseBlock ausgeführt wird.
Das läuft einwandfrei und ich kann vom Netzwerk aus auf den Controller zugreifen ubnt. Mein Setup sieht nun so aus:
Ich kann problemlos per SSH auf den Controller zugreifen, sehe das Solo aber nicht im Netzwerk. Ich habe es vom Laptop aus versucht und sehe nur den Router ( ), den Controller ( ) und mich selbst ( ).ssh [email protected]nmap -sP 192.168.1.1/24192.168.1.1192.168.1.6192.168.1.76
Hier stecke ich fest
Ich möchte vom Computer aus auf die Solo-Drohne zugreifen können. Mir ist klar, dass der Controller zwei Schnittstellen hat, aber ich verstehe nicht, wie ich sie überbrücken kann.
Der Zweck besteht darin, dass ich ein weiteres Paar an dasselbe Netzwerk anschließen ubntund dann zwei UAVs von einer zentralen Quelle aus überwachen/steuern kann und ein Pilot in die Schleife eingebunden sein kann, um bei Bedarf die Kontrolle zu übernehmen.
Für jede Hilfe oder Google-Begriffe wäre ich dankbar. Ich habe nicht viel Erfahrung mit Netzwerken und bin bei der Suche nach Befehlen und Begriffen im Zusammenhang mit Netzwerken schon in viele Irrwege geraten.
Antwort1
Ein Freund hat mir tatsächlich den Link zu diesem Artikel geschickt und wollte meinen Input hören – ich werde ihn auch hier teilen.
Das Problem hier sind fehlende Routen. Damit Ihre 192.168.1.76IP (oder eine beliebige 192.168.1.xIP) zu gelangen kann 10.1.1.x, muss sie den Weg kennen. IPs im selben Subnetz (z. B. [ 10.1.1.1und 10.1.1.10] oder [ 192.168.1.76und 192.168.1.1]) benötigen keine Route zur Kommunikation; sie verwenden eine Übertragung, um das Gerät mit einer bestimmten IP zu finden und ihren Datenverkehr direkt zu senden.
Um von einem Subnetz zu einem anderen zu gelangen, müssen Sie eine Route definieren. Zusätzlich müssen Sie eine Route ZURÜCK definieren. Sie können also Folgendes versuchen (sofern Ihr Router und der Solo-Controller dies unterstützen):
Sie benötigen eine Route in Ihrem 192.168.1.1AP. Die Quelle wäre beliebig, das Ziel wäre 10.1.1.0/24und der nächste Hop wäre 192.168.1.6- der Solo-Controller. Der Controller kennt beide Netzwerke, wenn Sie also Datenverkehr an senden, der an bestimmt ist 10.1.1.10, wird der Solosollenwissen bereits, wie man dorthin kommt, undsollensenden Sie es weiter. Da der Controller selbst praktisch das Netzwerk-Gateway für die Drohne ist ( 10.1.1.1), und es istAuchsich des 192.168.1.0/24Subnetzes bewusst ist, dass dort keine Route erforderlich wäre - die Route zurück ist impliziert.
Fügen Sie diese Route zu Ihrem Router hinzu ( any>10.1.1.0/24>192.168.1.6) und prüfen Sie, ob das Problem dadurch gelöst wird.