Both loaders build "@ROMFS/models/<name>" into fname when the model is not
found on the filesystem, then stat() the original path again -- the one
already known to be missing -- so the fallback can never succeed and a model
that exists only in ROMFS panics. fname was also never passed to load_json()
and never freed.
Stat and load the resolved path, guard it against a failed asprintf, and free
it.
allows the scalar model values (mass, disc area, momentum drag etc) to
be customised as parameters for copters and quadplanes. A json model
file sets the defaults for the parameters
The SIM_FRM_BBDRAG and SIM_FRM_MDRAG drag coefficients default to
zero on planes so the plane model alone handles drag and the
auto-tests don't need retuning. Setting them on a quadplane gives
more realistic airbraking in VTOL modes
A collective pitch quadcopter matching AP_MotorsHeli_Quad's layout,
with rotor speed control on channel 8 to match AP_MotorsHeli_RSC's
default channel.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This PR clarifies the intended SIM_BATT_* param behavior
Step 1: Split Frame's battery management into smaller parts
Step 2: Move battery managagement out of Frame to Aircraft-children which have a Frame
Step 3: Move SITL::Plane's battery consumption up one level in the 'function stack'
Step 4: SIM::Battery manages its own initial voltage
Step 5: Make Aircraft responsible for managing battery resets
Step 6: Frame now does not use/have a SIM::Battery
(It uses the batt owned by Aircraft-children which have a Frame.)
Step 7: Put battery maybe-reset logic into SITL::Battery
Only one ever exists so there's little reason to construct all
possibilities ahead of time and store them in global RAM. Instead, keep
a list of the parameters and only construct the one requested. Saves
some 60K of RAM on hardware when using sim on hardware.
In particular, enough is saved to get esp32empty copter building again.
But esp32 sim on hardware still does not work due to other regressions.
this makes use of DRefs to greatly improve XPlane support. It only
supports XPlane 11 and later
The key change is the use of a JSON file to map ArduPilot output
channels to DataRefs, and map raw joystick inputs to RC inputs
this gets rid of the awful throttle hack handling, and allows for
control of a much wider range of aircraft
this allows for any output to be an ESC, which allows for proper
simulation of quadplanes with ESCs on outputs 5-8 or 9-12, for testing
notch filtering
==15803== Conditional jump or move depends on uninitialised value(s)
==15803== at 0x4C34975: index (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15803== by 0x444D8D: SITL::Frame::load_frame_params(char const*) (SIM_Frame.cpp:363)
==15803== by 0x445415: SITL::Frame::init(char const*, SITL::Battery*) (SIM_Frame.cpp:432)
==15803== by 0x3696ED: SITL::MultiCopter::MultiCopter(char const*) (SIM_Multicopter.cpp:35)
==15803== by 0x34B49C: SITL::MultiCopter::create(char const*) (SIM_Multicopter.h:44)
==15803== by 0x34C58E: HALSITL::SITL_State::_parse_command_line(int, char* const*) (SITL_cmdline.cpp:480)
==15803== by 0x344005: HALSITL::SITL_State::init(int, char* const*) (SITL_State.cpp:923)
==15803== by 0x33D854: HAL_SITL::run(int, char* const*, AP_HAL::HAL::Callbacks*) const (HAL_SITL_Class.cpp:182)
==15803== by 0x15ACDD: main (Copter.cpp:678)
==15803==
this takes account of motor expo, velocity of air over propellers,
mass, size and other factors
It also allows for frame parameters to be supplied as an external json file