Announcement

Collapse
No announcement yet.

Questions about VRX 2019 Rules

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Brian

    > I believe that would be a reasonable approximation of your physical setup - true?
    That is not true.
    We are thinking that in /imu topic, we obserce
    - acceleration
    - angular velocity
    - absolute orientation by terrestrial magnetism
    We agree that we could observe the vehicle heading.
    But, in the real system, if we use terrestrial magnetism, we need to calibrate it in every time.
    That is why, we are using NMEA gps to avoid calibration.

    Apart from that, now the GPS sensor publishes the topic in 15 Hz in the simulator.
    But the real sensor publishes the information around 1Hz.
    So we integrate NMEA sensor as 1Hz sensor, and IMU as high ratio sensor.
    And so, both NMEA sensor and IMU is necessary for us.

    Best Regards,
    Ryodo

    Comment


    • #17
      Hi Ryodo,

      Thank you for the discussion.

      The simulated IMU provides the orientation relative to the world frame, so there is no need to calibrate the sensor information. This can be thought of as a true north heading sensor, similar to what you would observe from a GPS based system that provides heading. This is also equivalent to a magnetic sensor with appropriate calibration and declination applied.

      The VRX simulated GPS measurements are published at 20 Hz. While this is much faster than a typical standalone GPS sensor which typically updates at 1, 2 or 4 Hz, it is representative of the solutions many of the teams employ. The reason for this is that many teams use an integrated GPS-aided IMU solution that provides a high update rate navigation solution (position, velocity and attitude estimates).

      If you would like to reduce the update rate for the simulated GPS there are a few ways to consider. It is great that you have your own estimator that uses both GPS and IMU information. You could formulate that estimator such that it works with a variety of update rates - using all the information it has available. You could also formulate the estimator such that it only accepts GPS updates at 1 Hz. As an alternative, you could develop a small ROS node that subscribes the 20 Hz input and re-published the GPS fix (on a new topic) at 1 Hz.

      With VRX we have tried to have the customizable sensor and propulsion configurations support as many of the team's hardware solutions as possible, but supporting each team's exact solution isn't feasible as we'd have ~20 individual configurations to create, test and debug. We are here to help you make the VRX simulation behave as close as possible to your physical configuration.

      Brian

      Comment


      • #18
        Dear Brian

        Thank you for your reply.
        I understand that IMU sensor is publishing the "calibrated" information from world frame.
        But we are worry that, the IMU sensor is not the same sensor model as GPS typed sensors.
        For example the drift noise model is different from GPS and IMU sensor.
        On this topic, the hector_gazebo_plugin is using same sensor model for both GPS and IMU sensors.
        So we are thinking, this plug in is not enough (to say strongly, it is wrong) simulating real sensor.
        We deeply understand that you have a lot consideration for robot configuration for every team.
        And we are really appreciate that. Thank you very much.
        But this sensor simulation issue, it should be modified, we believe.
        And about maintenance, we already released the nmea_gazebo_package as deb packages. (Can get by apt-get)
        So, we believe the cost of maintenance is not so high.

        On the details about this sensor model topic, Masaya Kataoka, who is our team member, is close to.
        Thus, he will describe more details.
        Thank you again for your kind correspondence.

        Best Regards,
        Ryodo
        Last edited by Ryodo Tanaka; 07-11-2019, 01:18 AM.

        Comment


        • #19
          Ryodo,

          This is a great discussion. Thank you for bringing up these points as I'm sure this will assist other teams as well.

          I've started an issue within the VRX project at https://bitbucket.org/osrf/vrx/issue...heading-sensor
          This will help us all work on this collaboratively and document the technical details. In the issue I've proposed a few steps for us to look into this issue to try and determine the best way forward.

          One way that your team might help with this is to describe the model used in the plugin: https://github.com/OUXT-Polaris/nmea_gps_plugin This would help everyone understand the technical differences between the sensor models.

          Thank you,
          Brian

          Comment


          • #20
            Brian, now, I just implement a gausian noise sensor model.
            I will add multi path sensor noise model soon. (It will be implement suddenly jump of the gps position.)

            Comment

            Working...
            X