#1 SensorData1D needs improvement

open
nobody
None
5
2005-10-26
2005-10-25
Thomas R. Kramer
No

The SensorData1D class in sensorData.hh needs
improvement. There are at least three problems with it.

1. The isGlobal data member is a boolean. However, the
sensor data being passed from Servo SP to Prim SP is
neither local nor global; it is relative to the
position of the sensor.

2. SensorData1D is designed to be used for several
different purposes, but there is no place where the
documentation of what it means for a specific purpose
belongs. We could use subclasses with no additional
members to provide a place for documentation. If we do
not do that, we should decide where documentation
belongs in cases of this sort.

3. The most severe problem is that since the data being
passed from Servo SP to Prim SP is relative to the
location of the sensor, it is necessary to know the
location of the sensor in order to use the data. The
sensor location is currently being found in Prim SP by
getting the vehicle location from nav data, knowing the
location of the sensor relative to the vehicle, and
computing the position of the sensor. It is assumed
that the vehicle did not move much while the data was
being collected. It is also assumed that the nav data
read in Prim SP is not appreciably different from what
the nav data was in Servo SP at the time the data was
collected.

I think we can agree that relative data should be
transmitted only if it is true that the sensor did not
move much while the data was being collected. And I
think that this is true of ladar data being collected
in simpleSim and usarSim and transmitted in a single
message (holler if not).

I do not think the second assumption is tenable.
Communication delays are likely to cause a significant
difference in where the vehicle is between the time the
data is collected and the time nav data is read by
Prim. We are seeing significant scatter in the data
(hit points are showing up on the other side of walls
from the vehicle). A discrepancy in vehicle position is
the likely cause of some or most of the scatter.

All three problems can be solved simultaneously (for
this case) by defining a SensorData1DRelative subclass.
It would have a sensorPosition data member of type
PM_POSE. The isGlobal flag would be taken to refer to
the sensorPosition in this subclass.

Alternatively, the vehiclePosition could be included,
but this seems much inferior, since then information
about where the sensor is on the vehicle needs to be
transmitted from Servo to Prim, and Prim needs to
calculate the sensor position.

Discussion

  • Logged In: YES
    user_id=351136

    Hey! I did not assign a priority, and I did not finger CJ to
    fix the problem. The system did that on its own. I guess CJ
    was chosen because I used the servo category, but, as often
    happens, the categories available were not adequate.
    SensorData1D is equally important in at least Servo and Prim.

    I will be happy to make the changes to sensorData.hh I
    proposed, if it is OK with the rest of the team.

    Tom K.

     
  • Logged In: YES
    user_id=1323519

    I think that we have begun to address this problem by having
    a transform as part of the status message. I believe that we
    may really want two transforms; one to global and one to
    vehicle relative.

    The idea is as follows: Assume that sensor 'a' is connected
    to rotator 'b' which in turn is attached to arm 'c' which in turn
    is attached to the vehicle.
    The arm would contain a transform to take any point in its
    local coordinates to global and vehicle. Rotator 'b' would read
    this transform in order to create its own transform to take any
    point from its local coordinate system to global or vehicle
    coordinates. This process would be chained through all of the
    components until we get to the sensor. The sensor would
    publish a transform that would be a combination of all of the
    preceeding transforms and would take a point from sensor
    coordinates into global or vehicle.

    I would like to discuss this because I still see the same, if
    not worse delay problem with this technique. If we do this, it
    may take a long time for the vehicle position to propogate all
    of the way to the sensor (several status messages would
    need to be updated before the transform becomes stable).

    The only alternative that I am aware of is to have the sensor
    read the status of all of the components that affect its final
    position. In this case, we could have a field in the settings
    message that points to where a component is attached so
    that this chain could be auto-determined.

    If anyone has a better or different idea, please post. If not,
    lets talk about the alternatives after RoboCamp. Thanks.

    Steveb.

     
    • labels: 780360 -->
     
    • assigned_to: cj_scrapper --> nobody