The Moving_Platform_Simulation example defines radar mountings.
Is the mounting offset is x,y,z offset from the physical center of the aircraft in meters? (assume yes)
Is the radar_rotation_offsets order Heading(Yaw), Pitch, Roll? Are the units angles degrees or radians? (assume degrees)
If I want to orient a sensor perpendicular look of 30 degrees for example is this the correct state vector: 0,0,30 ?
radar_mounting_offsets = StateVector([10, 0, 0]) # e.g. nose cone
radar_rotation_offsets = StateVector([0, 0, 0])
for k in range(1, 21): truth.append(GroundTruthState( transition_model.function(truth[k-1], noise=True, time_interval=timedelta(seconds=1)), timestamp=start_time+timedelta(seconds=k))) truths.add(truth) truth = GroundTruthPath([GroundTruthState([0, 1, 20, -1], timestamp=start_time)]) for k in range(1, 21): truth.append(GroundTruthState( transition_model.function(truth[k-1], noise=True, time_interval=timedelta(seconds=1)), timestamp=start_time+timedelta(seconds=k))) truths.add(truth)
Returning to my earlier question, I still can't figure out how to utilize ConstantAcceleration as a maneuver in my simulations. If I use CombinedLinearGaussianTransitionModel([ConstantAcceleration(0.), ConstantAcceleration(0.), ConstantAcceleration(0.)]), I get an error stating:
ValueError: matmul: Input operand 1 has a mismatch in its core dimension 0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 6 is different from 9)
If I change the Z component model with CombinedLinearGaussianTransitionModel([ConstantAcceleration(0.), ConstantAcceleration(0.), ConstantVelocity(0.)]), then I get the following error message:
ValueError: matmul: Input operand 1 has a mismatch in its core dimension 0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 6 is different from 8)
Notice that the reported mismatch has dropped from 9 to 8. This suggests that ConstantAcceleration is incompatible with my model. You could reproduce this behavior by modifying the target platform in the Moving Platform Simulation. Hopefully this clarifies my issue.
Sorry for the flurry of questions, but here's another issue I've run into. I'm trying to write my simulation to a YAML file using the following code:
YAMLWriter("config.yaml", groundtruth_source=sim.groundtruth, detections_source=sim.detections)
But this gives the error message, "AttributeError: 'PlatformDetectionSimulator' object has no attribute 'current'." When I use the same line of code in the Moving Platform Simulator example, it works fine. So somehow the tracker object is modifying the simulator object, adding the Current attribute, but I can't find the source code which does this. How can I save a simulator without using a tracker? Or do I need to use a dummy tracker?
currentattribute is set as each component is run; this is part of the
BufferedGeneratorwhich warps the iterable part of readers and another sensibly named attribute is pointed at this
detection_gen()being the iterable method and
detectionsbeing the attribute in this example). With the
*_sourcevariables should be set to the readers them selves, rather than the attribute where detections will be available. So in this case
detections_sourceshould be set to
YAMLWriter("config.yaml", groundtruth_source=sim.groundtruth, detections_source=sim)
YAMLWriterclass is immature and not well document unfortunately. I'll raise an issue for that.
tracker = MultiTargetTracker(...) from stonesoup.serialise import YAML with open('config.yaml', 'w') as config_file: YAML().dump(config_file, tracker)
YAMLWriteris good for writing out the data (truth, tracks, etc.), rather than a configuration.
Or in fact just:
from stonesoup.serialise import YAML with open('config.yaml', 'w') as config_file: YAML().dump(config_file, sim)
would work fine, as it'll serialise the groundtruth attribute.
for track in ctracks: X = [state.state_vector for state in track] Y = [state.state_vector for state in track] print(time, X[-1], Y[-1]) artists.extend(ax.plot(X, Y, color='k'))
@apiszcz Thanks for the suggestions. My current dilemma is that the tracker is behaving too poorly to turn over to an optimizer. I need to get it to produce at least one track for each target before optimization can help.
@sdhiscocks Thanks for your advice. My simulation has targets doing combinations of constant velocity and constant turn and my predictor model is constant velocity, so it should be capable. My measurement covariances are in spherical coordinates, so I've done some post hoc analysis of my simulation to find the cartesian variances. I've tried more than 100 simulations with various tracker parameters I'm able to get decent performance if I only simulate 1 target, but once go to 2 targets, I can't get a decent result. The fact that there are never simultaneous tracks make me wonder if my tracker is fundamentally flawed rather than poorly tuned.
If it helps, here's my tracker code:
bodies_all = target_ls + [sensor_platform] sim_all = PlatformDetectionSimulator(groundtruth=truths, platforms=bodies_all) target_transition_model = CombinedLinearGaussianTransitionModel( [ConstantVelocity(.005), ConstantVelocity(.005), ConstantVelocity(0)]) predictor = ExtendedKalmanPredictor(target_transition_model) updater = ExtendedKalmanUpdater() hypothesiser = DistanceHypothesiser(predictor, updater, measure=Mahalanobis(), missed_distance=3) covariance_limit_for_delete = .1 min_detections = 50 X_tar, Y_tar = sum(x_pos_rng)/2, sum(y_pos_rng)/2 s_prior_state=GaussianState([[X_tar], , [Y_tar], , [8000*feet_to_deg], ], np.diag([0, 0.002, 0, 0.002, 0, 0])) #data_associator = GNNWith2DAssignment(hypothesiser) data_associator = GlobalNearestNeighbour(hypothesiser) deleter = CovarianceBasedDeleter(covariance_limit_for_delete) initiator = MultiMeasurementInitiator( prior_state=s_prior_state, measurement_model=None, deleter=deleter, data_associator=data_associator, updater=updater, min_points=min_detections ) # Create an EKF Multi-target tracker tracker = MultiTargetTracker( initiator=initiator, deleter=deleter, detector=sim_all, data_associator=data_associator, updater=updater )