#!/bin/sh
### BEGIN INIT INFO
# Provides: ArduPlane
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: ArduPlane Autopilot Daemon
# Description: starts ArduPlane Autopilot
### END INIT INFO
PIDFILE=/var/run/arduplane.pid
STARTCMD="ArduPlane -C /dev/ttyAMA0"
start(){
if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then
echo 'Service already running' >&2
return 1
fi
echo 'Starting service…' >&2
local CMD="$STARTCMD &> /home/pi/arduplane.log & echo \$!"
su -c "$CMD" root > "$PIDFILE"
echo 'Service started' >&2
}
stop(){
if [ ! -f $PIDFILE ] || ! kill -0 $(cat $PIDFILE); then
echo 'Service not running' >&2
return 1
fi
echo 'Stopping service…' >&2
kill -15 $(cat "$PIDFILE") && rm -f "$PIDFILE"
echo 'Service stopped' >&2
}
# Actions
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
esac
exit 0
It now creates a pid file for checking, if ardupilot is already running. if yes you can not start a second instance. Rest with update rc and so on is like mentioned in the post before. You just need to replace the text in the quotes of STARTCMD. Change to ArduCopter or edit telemetry parameters -C or add -A and so on…
If everything works well and if using TCP you can just enter “navio” as Host Adress in APM Planner. Then you do not even need to know the IP of the raspberry.
Thank you very much for scripts, works perfect.
I could tell if there is any way to update the apm vercion with scripts.
APM is nesesario desistalar and return to copilar.
Note: I put the arducopter executable in /usr/local/sbin
You should put the path to where arducopter is located in your setup.
I would also change the Restart=on-failure to Restart=always… that way if ardupilot stops for any reason (restore defaults from Mission Planner for example), it restarts ardupilot.
The problem with this method is that it will not autorestart on issues or when you do a reset to defaults in MP… you will have to re-boot. Also you cannot start and stop without knowing the PID.
With the above method you can:
Start sudo systemctl start ardupilot
Stop sudo systemctl stop ardupilot
Restart sudo systemctl restart ardupilot
Start on boot sudo systemctl enable ardupilot
Not run on boot (for troubleshooting or other tasks) sudo systemctl disable ardupilot
This makes it very easy to control what ardupilot does without having to go through crontab or ps aux for the PID to kill it.
Hi Guys…I already update to the latest Linux image “Linux navio 4.4.6-4d0ae01-emlid-v7+ #3 SMP PREEMPT Wed Apr 6 13:25:26 MSK 2016 armv7l GNU/Linux” and I need your help due I want to integrate Reach with navio but to do it I need to move my OSD connected currently on Navio+ UARTport. To do it, I proceed to move it till to USB available ports connecting the OSD through FTDI USB-uart converter but unfortunately when I wrote the command -->
sudo Arducopter-quad -A /dev/ttyUSB0 -C /dev/ttyUSB1 >/home/pi/startup_log &
on rc.local file and then I reboot the PI the APM doesn’t Autostart.
After check on /dev/ , I realize that just only one ttyUSB and tyAMAon that path
My questions are:
How I can get telemetry data to connect my osd using USB port?
Is there is a way to increase the ttyUSB_ devices on that path?
By the way main telemetry (3DR Radio are using ttyUSB0) working when the conmand on rc.local is
sudo ArduCopter-quad -A /dev/ttyUSB0 -C /dev/ttyAMA0 >/home/pi/startup_log &
First off I must say that I prefer a systemd service file over all other alternatives. But when using your example with arducopter-heli 3.3 the compass craps out. When trying to calibrate it in mission planner it says 3+ samples and nothing more. If I run arducopter from command line or rc.local it works as it supposed to. I have no idea how a systemd service could even make this happen
That is very strange indeed, system services should have no bearing on the compass or calibration. There was a bug in the original version of ardupilot (copter/rover/plane/heli) that was provided from Emlid with the compass having issues with calibration. Did you recompile or use the “experimental” version they released a few weeks ago? The only other thing I can think off is that maybe there are two different version installed on the Rpi and somehow the one that systemd is calling has the calibration bug??
I’m using the version from the docs on a clean freshly installed image. I have the navio in a traditional helicopter and there seems to be a bug in the latest git version so when I build from source I cant reverse the servos from either mission planners gui or the params. Have not heard of the experimental version though.
Thanks. I’ll try it and see if it is better. But it seemed like most of the compass issues were with the navio2, I have the navio+, but I’ll try anyway.
