ardupilot
ardupilot copied to clipboard
ArduPilot
SITL: Failed to load defaults from ... when trying to start multi-aircraft SITL
Bug report
Issue details
When trying to start a simulation with:
sim_vehicle.py -v ArduPlane --map --console -n 2 --auto-sysid
the output in the main window is:
SIM_VEHICLE: Using defaults from (../../git/ardupilot/Tools/autotest/default_params/copter.parm)
SIM_VEHICLE: Run ArduCopter
SIM_VEHICLE: "/home/felix/git/ardupilot/Tools/autotest/run_in_terminal_window.sh" "ArduCopter" "/home/felix/git/ardupilot/build/sitl/bin/arducopter" "-S" "--model" "+" "--speedup" "1" "--slave" "0" "--defaults" "../../git/ardupilot/Tools/autotest/default_params/copter.parm" "-I0" "--sysid" "1"
SIM_VEHICLE: Run ArduCopter
SIM_VEHICLE: "/home/felix/git/ardupilot/Tools/autotest/run_in_terminal_window.sh" "ArduCopter" "/home/felix/git/ardupilot/build/sitl/bin/arducopter" "-S" "--model" "+" "--speedup" "1" "--slave" "0" "--defaults" "../../git/ardupilot/Tools/autotest/default_params/copter.parm" "-I1" "--sysid" "2"
RiTW: Starting ArduCopter : /home/felix/git/ardupilot/build/sitl/bin/arducopter -S --model + --speedup 1 --slave 0 --defaults ../../git/ardupilot/Tools/autotest/default_params/copter.parm -I0 --sysid 1
SIM_VEHICLE: Run MavProxy
SIM_VEHICLE: "mavproxy.py" "--out" "127.0.0.1:14550" "--out" "127.0.0.1:14551" "--master" "tcp:127.0.0.1:5760" "--sitl" "127.0.0.1:5501" "--out" "127.0.0.1:14560" "--out" "127.0.0.1:14561" "--master" "tcp:127.0.0.1:5770" "--sitl" "127.0.0.1:5511" "--map" "--console"
RiTW: Starting ArduCopter : /home/felix/git/ardupilot/build/sitl/bin/arducopter -S --model + --speedup 1 --slave 0 --defaults ../../git/ardupilot/Tools/autotest/default_params/copter.parm -I1 --sysid 2
Connect tcp:127.0.0.1:5760 source_system=255
Connect tcp:127.0.0.1:5770 source_system=255
Loaded module console
Loaded module map
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from tcp:127.0.0.1:5760
MAV>
and all plane simulations fail with the following error:
Setting SIM_SPEEDUP=1.000000
Setting SYSID_THISMAV=1
Starting sketch 'ArduPlane'
Starting SITL input
Using Irlock at port : 9005
bind port 5760 for 0
Serial port 0 on TCP port 5760
Waiting for connection ....
Connection on serial port 5760
PANIC: Failed to load defaults from ../../git/ardupilot/Tools/autotest/default_params/plane.parm
Running: sh dumpstack.sh 30301 >dumpstack.sh_arduplane.30301.out 2>&1
Failed
Running: sh dumpcore.sh 30301 >dumpcore.sh_arduplane.30301.out 2>&1
Failed
(the second window has SYSID_THISMAV=2 and other ports, but the same error)
The path to the defaults file is correct, I can access it using the path listed above.
The command:
sim_vehicle.py -v ArduPlane --map --console --auto-sysid
out of the same or any other directory works as expected.
Does somebody have the same problem?
Version current master (020262b)
Platform [ x ] All (tested with plane and also copter) [ ] AntennaTracker [ x ] Copter [ x ] Plane [ ] Rover [ ] Submarine
I can confirm I get the same error on master 020262bfe7755951ec655e9257084c6920b0f642
Starting from the ardupilot directory
It may be related to these changes which were attempted to be fixed then partially reverted, https://github.com/ArduPilot/ardupilot/pull/19879 Reversion here: 13f7e12d2a57e5c20e7eead146a3da2f252af6e8
Unfortunately, I cant via wiki (search term swarm) or google (search term ardupilot swarm) find the calls or documentation to create swarms. And am thus left with simvehicle.py --help
After investigating a bit further, it seems the problem is the usage of relative paths to the parm file in combination with -n >=2.
Changing line 687 of sim_vehicle.py from
paths = [util.relcurdir(os.path.join(autotest_dir, x)) for x in paths]
to
paths = [os.path.join(autotest_dir, x) for x in paths]
so that absolute paths are used solves the problem for me.
The problem is, that before calling run_in_terminal_window(cmd_name, cmd + c) (line 750) the program changes into the instance directory and then the relative path is wrong.
I hope with this information someone can write a better fix than this little hack. I would appreciate it.
I think I'm seeing something like this building SITL from master. On each build the SIM* parameters seem to randomly load or not load. I'm simulating a single plane. Don't get an error, but I just get no parameters:
param show *BATT*
MANUAL> BATT_FS_CRT_ACT 0.0
BATT_FS_LOW_ACT 0.0
param show *BAT*
MANUAL> BATT_FS_CRT_ACT 0.0
BATT_FS_LOW_ACT 0.0
param show *B*
MANUAL> BARO1_GND_PRESS 94504.3515625
BARO2_GND_PRESS 94503.875
BARO_ALT_OFFSET 0.0
BATT_FS_CRT_ACT 0.0
BATT_FS_LOW_ACT 0.0
param show
MANUAL> ARSPD_OFFSET 2013.474853515625
BARO1_GND_PRESS 94504.3515625
BARO2_GND_PRESS 94503.875
BARO_ALT_OFFSET 0.0
BATT_FS_CRT_ACT 0.0
BATT_FS_LOW_ACT 0.0
INS_ACC2_ID 2753036.0
INS_ACC_ID 2753028.0
SR0_EXTRA1 4.0
SR0_EXTRA2 4.0
SR0_EXTRA3 4.0
SR0_EXT_STAT 4.0
SR0_POSITION 4.0
SR0_RAW_SENS 4.0
SR0_RC_CHAN 4.0
STAT_RUNTIME 35847.0
param show *VOLT*
MANUAL> param show *SIM*
MANUAL>
A build I did about 12 hours ago, did show the SIM parameters. I just went back in my history, so I don't have a search for SIM* but I did search for *BATT* which shows SIM_BATT parameters that don't show now. Note that above I searched for BATT and only got two results, whereas below (12 hours ago) I got a whole raft of BATT parameters.
MANUAL> param show *BATT*
MANUAL> BATT2_MONITOR 0.0
BATT3_MONITOR 0.0
BATT4_MONITOR 0.0
BATT5_MONITOR 0.0
BATT6_MONITOR 0.0
BATT7_MONITOR 0.0
BATT8_MONITOR 0.0
BATT9_MONITOR 0.0
BATT_AMP_OFFSET 0.0
BATT_AMP_PERVLT 17.0
BATT_ARM_MAH 0.0
BATT_ARM_VOLT 10.0
BATT_CAPACITY 3300.0
BATT_CRT_MAH 0.0
BATT_CRT_VOLT 5.0
BATT_CURR_PIN 12.0
BATT_FS_CRT_ACT 0.0
BATT_FS_LOW_ACT 0.0
BATT_FS_VOLTSRC 0.0
BATT_LOW_MAH 0.0
BATT_LOW_TIMER 10.0
BATT_LOW_VOLT 7.0
BATT_MONITOR 4.0
BATT_OPTIONS 0.0
BATT_SERIAL_NUM -1.0
BATT_VLT_OFFSET 0.0
BATT_VOLT_MULT 2.0
BATT_VOLT_PIN 13.0
BATT_WATT_MAX 0.0
SIM_BATT_CAP_AH 0.0
SIM_BATT_VOLTAGE 10.0
we should probably revert 9743ac9c3db5de9e4d478830821e67053b4c6a15 too. I wrote that pr under some incorrect assumptions.
we should probably revert 9743ac9 too. I wrote that pr under some incorrect assumptions.
I can confirm that just reverting the changes made there on top of the current master code solves the problem for me.
@Williangalvani is simply reverting that commit going to cause you problems with your workflow? It's biting more people, so we should probably do something here :-)
This problem still exists unfortunately, I am having these problems as we speak!
I tested on master hash 83559c41ec55dfd817fbffcb60bf7897d9da95f1 just now, and it seems to work. Two vehicles spawn and don't crash.
Regarding how to launch the swam, I also found some other options for sim_vehicle, but it's not clear how they all relate.
Here's some other parameters I was playing with. The swarm param seems to not change anything, and --instances seems to provide a manual way if you don't use --auto-sysid.
sim_vehicle.py --swarm Tools/autotest/swarminit.txt -v Plane --console --map --instances 0 1 2
Pierre made a nice video on swarming, but it doesn't use sim_vehicle.py. https://www.youtube.com/watch?v=SMISOREe1y4&ab_channel=MrKhancyr
Ok, here's the magic for using SITL, with the help of Peter and James. Both of these use auto-sysid because it's easy.
Option 1: Launch and supply an offset line
./Tools/autotest/sim_vehicle.py -v Copter --map --console --auto-offset-line 90,10 -n 5 -L CMAC --auto-sysid
Option 2: Launch and supply a swarm configuration file, which gives you more control over things like orientation
./Tools/autotest/sim_vehicle.py -v Copter --map --console -n 5 -L CMAC --auto-sysid --swarm Tools/autotest/swarminit.txt
Warning If you do not supply a line offset or a swarm configuration file, they will all launch in the same spot.
How many? Well, Peter proved you can do 50, which is pretty neat.