Have got my Navio+ running on a RasPi2.
- It runs in screens perfectly well
- It runs MavProxy so you can do DroneAPI for cool stuff.
Screens is a way of running processes in the background and be able to interact with them. If you just background them with the & modifier then you can’t really get to them easily to see what is happening. This way I can switch to MavProxy that is running in the screen and enter commands. It basically means I have a GCS on the RasPi. It also means you can run DroneAPI on the RasPi and it talks directly to the Navio+
This is my rc.local
sudo -u pi screen -d -m -S 3G
sudo -u pi screen -S 3G -p 0 -X exec /home/pi/start3G.sh
sudo -u pi screen -d -m -S Navio
sudo -u pi screen -S Navio -p 0 -X exec /home/pi/startNavio.sh
sudo -u pi screen -d -m -S MavProxy
sudo -u pi screen -S MavProxy -p 0 -X exec /home/pi/startmavproxy.sh
The command sudo -u means that it runs as user pi so when you login as pi and switch to the screens they are there for you to look at instead of for the root user which would happen if you left out the sudo command
start3G.sh
sudo ./home/pi/sakis3g USBINTERFACE=‘0’ OTHER=‘USBMODEM’ USBMODEM=‘12d1:1c05’ APN=‘CONNECT’ CUSTOM_APN=‘CONNECT’ APN_USER=‘0’ APN_PASS=‘0’ connect
startNavio.sh
sudo ArduPlane -A udp:192.168.1.28:14550 -C /dev/ttyAMA0 > /home/pi/startup_log
192.168.1.28 is the IP address of the RasPi
startmavproxy.sh
python /usr/local/bin/mavproxy.py --master=192.168.1.28:14550 --logfile=/home/pi/mav.tlog --out=192.168.1.10:14550 --out=113.212.169.23:14550
The --master statement takes the UDP packets from the Navio and starts up MavProxy. The --out is for the ground station that is connected via wifi and if 3G is working the other IP address is the fixed IP address of my 3G connection on the ground.
The only problem is when I use 3G and the RasPi does not have an IP address from the ethernet port and I don’t think it will work. I will have to find some way of changing it depending on what is connected.
Now to fly the Penguin with it when my digital airspeed sensor and power module arrive.
3 Likes
Been smacked over the head with the obvious stick and of course the IP address for communication should be 127.0.0.1
This line should be:
sudo ArduPlane -A udp:127.0.0.1:14550 -C /dev/ttyAMA0 > /home/pi/startup_log
and
python /usr/local/bin/mavproxy.py --master=127.0.0.1:14550 --logfile=/home/pi/mav.tlog --out=192.168.1.10:14550 --out=113.212.169.23:14550
In my case MavProxy is doing all the distributing of telemetry
Quite clever! That should be helpful for other Navio users.
What are your plans for DroneAPI?
We have to script up the takeoff when the sample is put in the lander.
Hi,
why do you use the -C option when starting Arduplane and not an additional --out for mavproxy?
I didn’t know you could. In SITL there is a --out switch however in this I am not sure there is as SITL uses MavProxy to work whereas this binary does not.
I mean an additional --out switch in the mavproxy script, like:
python /usr/local/bin/mavproxy.py --master=192.168.1.28:14550 --logfile=/home/pi/mav.tlog --out=192.168.1.10:14550 --out=113.212.169.23:14550 --out=/dev/ttyAMA0,“baud”
and not using the -C option with Arduplane.
This way mavproxy would really handle all the telemetry. Or do you do use the -C option to still have telemetry, if mavproxy hangs?
I tried to use screen, simply copying your rc.local lines :-).
For some reason it did not work. The scripts alone start just fine, but the screen calls just created the detached sessions, without starting either Arducopter or mavproxy.
I then had a look around the internet and modified the rc.local to this:
su - pi -c “screen -dmS APMCopter ~/StartAPMCopter.sh”
su - pi -c “screen -dmS Mavproxy ~/StartMavproxy.sh”
Now APMCopter starts in its screen session, but mavproxy does not.
If I enter those lines in the console I get asked for a password for both, I enter the password of user pi and APMcopter starts, mavproxy does not.
Mavproxy starts just fine if I call the script directly.
I will keep trying, perhaps it is something obvious that escapes me at the moment. If you have an idea what goes wrong, please let me know.
I see your point about the -C option. I didn’t really think about it actually. The only thought I had was that MaxProxy outputs the networking telemetry and the Navio is for the radio type telemetry. I will be using exclusively 3G as I do not have any more 3DR radios to use.
I actually use a screen manager called byobu to manage my screen sessions. I left it out of what I posted as screens is more common that using a manager.
sudo -u pi byobu -d -m -S 3G
sudo -u pi byobu -S 3G -p 0 -X exec /home/pi/start3G.sh
sudo -u pi byobu -d -m -S Navio
sudo -u pi byobu -S Navio -p 0 -X exec /home/pi/startNavio.sh
sudo -u pi byobu -d -m -S MavProxy
sudo -u pi byobu -S MavProxy -p 0 -X exec /home/pi/startmavproxy.sh
Follow the bottom of this file as to how to setup and run byobu
This is my byobu sessions after startup. If I select 1 then this is what I see:
As you can see MavProxy is controlling the Navio.
Maybe it would help to install byobu and configure it - it makes screen management really easy.
BTW I am not sure about the error I am getting here. MavProxy seems to work OK. I have emailed Tridge about it but he has not replied yet.
