Recent changes to feature-requestshttps://sourceforge.net/p/moast/feature-requests/2005-10-25T21:30:13ZSensorData1D needs improvement2005-10-25T21:30:13Z2005-10-25T21:30:13ZThomas R. Kramerhttps://sourceforge.net/u/tomrkramer/https://sourceforge.netdaca5ebdf843c5ac8eb02d65a4d4eac29eda9095<div class="markdown_content"><p>The SensorData1D class in sensorData.hh needs<br />
improvement. There are at least three problems with it.</p>
<p>1. The isGlobal data member is a boolean. However, the<br />
sensor data being passed from Servo SP to Prim SP is<br />
neither local nor global; it is relative to the<br />
position of the sensor.</p>
<p>2. SensorData1D is designed to be used for several<br />
different purposes, but there is no place where the<br />
documentation of what it means for a specific purpose<br />
belongs. We could use subclasses with no additional<br />
members to provide a place for documentation. If we do<br />
not do that, we should decide where documentation<br />
belongs in cases of this sort.</p>
<p>3. The most severe problem is that since the data being<br />
passed from Servo SP to Prim SP is relative to the<br />
location of the sensor, it is necessary to know the<br />
location of the sensor in order to use the data. The<br />
sensor location is currently being found in Prim SP by<br />
getting the vehicle location from nav data, knowing the<br />
location of the sensor relative to the vehicle, and<br />
computing the position of the sensor. It is assumed<br />
that the vehicle did not move much while the data was<br />
being collected. It is also assumed that the nav data<br />
read in Prim SP is not appreciably different from what<br />
the nav data was in Servo SP at the time the data was<br />
collected.</p>
<p>I think we can agree that relative data should be<br />
transmitted only if it is true that the sensor did not<br />
move much while the data was being collected. And I<br />
think that this is true of ladar data being collected<br />
in simpleSim and usarSim and transmitted in a single<br />
message (holler if not).</p>
<p>I do not think the second assumption is tenable.<br />
Communication delays are likely to cause a significant<br />
difference in where the vehicle is between the time the<br />
data is collected and the time nav data is read by<br />
Prim. We are seeing significant scatter in the data<br />
(hit points are showing up on the other side of walls<br />
from the vehicle). A discrepancy in vehicle position is<br />
the likely cause of some or most of the scatter.</p>
<p>All three problems can be solved simultaneously (for<br />
this case) by defining a SensorData1DRelative subclass.<br />
It would have a sensorPosition data member of type<br />
PM_POSE. The isGlobal flag would be taken to refer to<br />
the sensorPosition in this subclass.</p>
<p>Alternatively, the vehiclePosition could be included,<br />
but this seems much inferior, since then information<br />
about where the sensor is on the vehicle needs to be<br />
transmitted from Servo to Prim, and Prim needs to<br />
calculate the sensor position.</p></div>