icaropires / objectlevel_fusion Goto Github PK

• Prepare structure for doxygen documentation
• Document each class/function/method/file following doxygen structure

Steps

• Feature Selection

  • Transform feature from object coordinate system to vehicle coordinate system (use transformation matrix)
    • Choose feature according to Table 3.1 (see dissertation) for some features (which?)
    • In some cases, special "reduced features" with just one dimension are used
  • Identify feature constellation
    • Determines the transformation applied to the two objects positions
    • Options
      • Common corner feature
        • Don't need geometrical association
      • Common side feature
        • Check consistency of the side
          • If succeeded, don't need geometrical association
          • Fails if the result is not small enough, then use reduced features
      • Features lie on common side
        • Use reduced feature
      • Features unrelated
        • Heuristic approach used
          • Two-dimensional state vector association test of all four corner features
            • If a common corner feature is found (i. e. association result of one or more common features lies below a certain threshold)
              • minimum common feature result is used for complete state vector association
            • else, reduced features are used
              • If the result doesn't meet the threshold, the association failed

• State Vector Association (track-to-track association)

  • Omit x or y if using reduced feature
  • Don't consider attributes that the sensor is not capable to measure
  • Implement the extended Mahalanobis Distance with Attribute Information
    • Basically, a Mahalanobis Distance that considers the probability of the existence of the objects and their classification vectors
  • Check the result of state vector association against the threshold before putting in the association matrix

• Geometrical Association

  • Applied when reduced features are used
  • Essentially, returns true if the objects overlap when projecting the features into one dimension, else returns false

• Calculate the association matrix

  • Association matrix must have N columns representing the N global fusion-level objects
  • Association matrix must have M columns representing the M sensor-level objects
  • Calculate the first cost matrix out of the association matrix
  • Calculate the second cost matrix M x M
  • Calculate the complete cost matrix (concatenation of the other two)
  • Implement the auction algorithm loop

Aeberhard illustration

Not every sensor is capable of generating all attributes from object model definition. For this reason, is necessary to adapt (probably matrix JA) to correspond to the capabilities from each sensor.

It will be very convenient to have any linear algebra operations as matrix generation, multiplication, transposition, etc.

• Find out which linear algebra library is usually used for this kind of application
• Integrate this library
• Multiply any matrices to check it is working

This is blocked by #14

Deploy Doxygen documentation at some free server.

• Setup linter checking in cmake and package.xml files with the package ament_lint_auto
• Add linter checking to CI

Add message types according to the object model specification. Types to create:

• ObjectModel
• Classification
• Dimension
• ExistenceProbability
• ShapeFeatures
• Track

• section 2.2.1 from PhD thesis

• Rewrite CTRA model from EKF temporal alignment using the state from object model
• Adapt all vectors with length 6 to 8 and all matrices 6x6 to 8x8
• Adapt experiment file att experiment/temporal_alignment_EKF.ipynb
• Adapt unit tests

• An user must be able to add new sensors that will have its data fused
• Data from non-registered sensors must be ignored
• The registration must be implemented as a ROS 2 service (inspiration)
• Must have an option to unregister the sensors

• Information that must be provided about the sensors:
  • Delta x, when compared to the vehicle
  • Delta y, when compared to the vehicle
  • Rotation, when compared to the vehicle
  • List of attributes from Object Model that the sensor is able to provide
    • Adapt EKF to consider such list
  • Sensor accuracy and precision information
    • Pass the measurement noise matrix
    • For now, the measurement noise matrix will follow the current CTRA implementation, with a state of size = 6
    • The order of attributes will be {x, y, v, a, yaw, yaw_rate}, to be more similar to the object model definition

• Adapt python mock publisher script to register the sensor

Currently, what is being used as the object model is a single object, but must be an objects list.

• Implement temporal alignment
• Add tests

• Section 3.1.2 from the PhD thesis
• A linear Kalman Filter

It's a good practice to limit the size of the strings that can be sent through the ROS services and messages. This issue is about limiting them.

• Limit the strings sizes that can be sent in all srvs and msgs
• Adapt the checking in the code to be bounded by the same limits

Reference on how to limit them: ros2 documentation

This issue doesn't need to be done if #15 is completed.

Currently, in sensor registration and temporal alignment, the matrix R is 6x6, because the CTRA model from EKF has a state of size 6.

To complete this issue is necessary to be able to transform a matrix with covariances to attributes {x, y, Vx, Vy, Ax, Ay, yaw, yaw_rate} to {x, y, V, A, yaw, yaw_rate} and vice-versa.

Create a very simple function capable of performing object association (maybe only useful in the best cases).

This function will be used for demonstrations until a more robust function is implemented.

• The application must be built in the docker environment
• The application must be executed in the docker environment
• The tests must be run and break pipeline if failed

• Add spatial alignment implementation
• Add tests

• Section 3.1.1 from the phd thesis

• Write correct building configurations to cmake and package.xml
• Setup Google Tests in cmake and package.xml files
• Setup Google Mocks in cmake and package.xml files
• Write docker files to ease application and checking executions, independent of the environment