The ground hit velocity is calculated by taking the last recorded
total velocity for the flight data and using that as the ground
hit velocity if the last altitude measurement is less than 10 m.
This method worked until commit f11a3e4 introduced the ability to
track and report all events that happened after a GROUND_HIT event.
That commit introduced a GroundStepper that will step between the
GROUND_HIT event and the SIMULATION_END event and will always
add a measurement to the flight data to record the rocket being on
the ground.
A better way of measuring the ground hit velocity is to interpolate
the velocity at the time the GROUND_HIT event, as that would actually
be the appropriate ground hit velocity.
Closes#576
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Adds back the instance options in the previous commit for specifying
instance details about rail buttons. This change adds it back but
slightly tweaks the layout and location in order to keep the config
panel in a 2 column arrangement.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Add two new material types for rail buttons, delrin and nylon.
The material densities are pulled from wikipedia and cross-referenced
with Dupont's material database.
Additionally, set Delrin as the default material for RailButtons.
Closes#554
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Allow rail buttons to define presets. This change doesn't actually add
any default presets to the library, but enables the ability to add some
preset options for rail buttons.
Partially Closes#554
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
The default values assigned to RailButton sizes were configured with
a 1.0 meter outer diameter and 0.8 meter internal diameter (for 1010
rail buttons) which resulted in overly large rail buttons when added
using the default values.
Presuming that 1010 rail buttons are the common and an acceptable
default, change the default button sizes to align with the 1010 size.
Additionally, this change fixes some of the layout issues present in
add railbutton dialog.
Closes#554
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
PR than I like as well. All I can do is apologize...
Fixes length calculation in RocketPanel.
(1) Finished switching over from deprecated getBounds() function to getBoundingBox().
getBounds() function is removed.
(2) 3D rendering code had its own getBounds(). Switched this over to
RocketComponent:getBoundingBox() as well
(3) Made getBoundingBox() consistently get the bounding box relative to the component.
Implementations for some components were calculating box relative to start of rocket
(4) Used InstanceMap to iterate through all instances of components in creating bounding box.
parameter, determining whether to validate fin tab, and made them
private.
Created two public wrappers for each, one calling for validation
(which has the same signature as the original three methods), and the
other not.
Called NoValidate versions of the three in file loading functions so
validation doesn't interfere with tab length when tab is read before
fin.
Tried to make the coding of the three more consistent with each
other.
of structure from calculation of motors, so mass and CG overrides
don't affect motors
Modified structure calculation so that when an override is in effect
and children are also being overridden, don't include root of tree as
an element in its own right when computing MOI.
Modified MassCalculatorTest to look for correct MOI value.
BarrowmanCalculator
Modify BarrowmanCalculator to actually sum fin nonaxial forces
Modify FinSetCalcTest to sum fins in test3Fin() and test4Fin()
Extra bonus: if at some point we allow fins to be other than radially
symmetrical, this code should still work (not tested)
some common (but generally not important) errors in thrustcurves, and
not enter thrustcurves that will cause simulation failures into the
database.
(1) Permits thrustcurves to start at time 0 with a nonzero thrust.
Previous code inserted a datapoint with time 0 and thrust 0; this
caused thrust interpolation code to fail while running a simulation.
If the first datapoint is at a time greater than 0 it does enter a
(0, 0) datapoint, as this is the correct documented behavior for RASP
files.
(2) Permits thrustcurves to end with a nonzero thrust. Similarly to
the previous case, the old code entered a new datapoint at the same
time as the previous end of thrust with thrust 0, which would break
thrust interpolation.
(3) Thrustcurves that have a zero-thrust datapoint and a non-zero
thrust datapoint at time 0 have the first datapoint removed.
(4) Thrustcurves with more serious errors -- mainly multiple thrusts
at a single time -- aren't entered into the database, as they will
break thrust interpolation and there is no obvious way to guess which
of the datapoints is correct, or to see how to average them.
