Patch: Running example_vasarhelyi with quadcopter
drone type
#12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These proposed changes are based on attempts to run
example_vasarhelyi
withDRONE_TYPE = "quadcopter"
First issue addressed:
Swarm.m
after the main simulation is finished but during plotting and swarm state analysis. The error seems to be becausevel_xyz_history
is empty. Whenexample_vasarhelyi
is run withDRONE_TYPE = "point_mass"
, each drone'spos_ned_history
andvel_xyz_history
are saved by the methodDrone.update_state
(lines 376 to 387). When runningDRONE_TYPE = "quadcopter"
,Drone.compute_kinematics
is called instead and it savespos_ned_history
but does not savevel_xyz_history
.Drone.compute_kinematics
to savevel_xyz_history
. Theif
statement needs to check for an empty array becausevel_xyz_history
does not have values assigned to it prior to this point (pos_ned_history
appears to have values assigned to it by the methodDrone.set_pos
by swarm initialization)isequal
to ensure theif
statement does its check against a logical scalar.Second issue addressed:
param_swarm
includes a line that is commented out with the comment "leave empty if you use a real drone model."if
statement that assigns a value top_swarm.max_a
based onDRONE_TYPE
appears to fix the issue, and is consistent with other usages ofDRONE_TYPE
in other parameter files to assign parameter values.