Difficulty in receiving the correct position and orientation
Closed this issue · 16 comments
Describe the bug
Hi there, I am Orish Jindal, initiating this request on behalf of TRIC Robotics, CA.
I am using the Parker 3DMGQ7 device along with a Reach Emlid M2 as a base station for RTK correction support. I am using the RFD900x radios for their mutual communication. I am able to receive RTCM messages and the Parker sensor is showing the 'fix' state on both gnss1 and gnss2.
The issue is that when I subscribe to the topic: nav/relative_pos/odom, I am supposed to get the position and orientation in the NED frame which is not happening in my case. When I place the X direction of the sensor in the North, it doesn't show a near 0 yaw. Also, I tried to crosscheck the issue by echoing the message on the topic: nav/heading which showed that the heading/yaw is drifting continuously (keeps incrementing) even when the sensor setup is stationary. Please help me with this issue.
Environment:
- OS: Ubuntu 20.04
- ROS Version: noetic
- Sensor(s): 3DM-GQ7
Launch Parameters
The params.yml file is not updated, used the default one.
Hello,
For the sensor to get a heading fix, you will need to edit the antenna offsets in your params file to match what they are in your setup. Please reference the following for how to measure these:
https://s3.amazonaws.com/files.microstrain.com/GQ7+User+Manual/user_manual_content/getting_started/Getting%20Started.htm
https://s3.amazonaws.com/files.microstrain.com/GQ7+User+Manual/user_manual_content/installation/Antenna.htm
Please monitor the filter status topic as well and make sure the filter enters the "Full Navigation" mode.
Hope that helps!
Nathan
Hi, Thanks for the reply.
I already made appropriate configurations for the same on SensorConnect, will it automatically fetch the data or should I make changes in the params file separately?
Best,
Orish
The default params file has the following flag set, which overrides any of the device's saved settings:
device_setup : True
You would need to set this to "False" to bypass the ROS driver's setup of the device. Be warned, that certain features may not work if the setup you have in SensorConnect does not provide the equivalent of what ROS expects. We consider this as an advanced option and should only be used is special cases... overriding the params for ROS is the preferred method of setup when using ROS.
Hope that helps!
Nathan
I changed the params.yml according to my requirements, please refer to the file at https://github.com/ojindal/params.yml/blob/main/params.yml. I am currently using dual antenna for the filter heading.
When I echo the messages on the topic /nav/aiding_summary, it shows:
dual_antenna:
enabled: False
used: False
Please guide me further. Thanks
Hello,
Is the system outside, with both antennas pointed towards the sky with unobstructed views? Also, if you are near a building, you may be experiencing multipath, which may prevent a dual antenna heading fix.
Assuming the above is okay, we would need either pictures or a diagram of how the system is mounted to check for any errors in setup. If you would like to provide this privately, you can email me at nathan.miller(at)parker.com.
Hope that helps,
Nathan
Hi Nathan,
The test setup is indeed outside with mostly unobstructed views. It seems that we don't have much trouble getting both gnss 1 & 2 into a fix state. Interestingly the dual antenna status topic and the /nav/heading topic are reporting different headings (1.22 rad & 0.627 rad)
Here is the fix status of gnss 1:
Here is the fix status of gnss 2:
Here is the output of the dual antenna status msg:
Here is the output of /nav/heading topic:
Here is the output of /nav/aiding_summary:
Interesting... looks like the dual antenna has a valid solution as well. You can see at the top of the /nav/aiding_summary that the gps_tow is 0, meaning no aiding has been processed in the filter yet (implying it is not in full nav mode.)
Could you provide the output of the /nav/status topic?
Thanks,
Nathan
This the output of the /nav/status topic
filter_state: 2
dynamics_mode: 1
status_flags: 1
Ah, ok, sorry, I should have saw this earlier...
Your heading alignment selector is set as follows:
filter_auto_heading_alignment_selector : 0
But this is a bitfield, so if you want to enable dual antenna, you need to set bit 1, which is a value of 1:
filter_auto_heading_alignment_selector : 1
Please give that a go and let me know if the filter initializes.
Nathan
This is the output of the /nav/status topic now:
filter_state: 2
dynamics_mode: 1
status_flags: 2
and this is the output of /nav/aiding_summary
gps_tow: 0.0
gnss1:
enabled: True
used: True
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
gnss2:
enabled: True
used: False
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
dual_antenna:
enabled: True
used: True
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
heading:
enabled: False
used: False
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
pressure:
enabled: False
used: False
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
magnetometer:
enabled: False
used: False
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
speed:
enabled: False
used: False
residual_high_warning: False
sample_time_warning: False
configuration_error: False
max_num_meas_exceeded: False
But the heading shown by /nav/heading is still icreasing continuously while the sensor setup is stationary.
The filter state needs to transition to 3 or 4 for the heading to be valid (we are looking for it to be 4, or "Full Nav")... I'm trying to decipher why it isn't transitioning as it is not clear. Out of curiosity, could you disconnect your RTK correction source, restart the device, and see if it start up correctly? Initialization with dual antenna usually takes less than 30 seconds, but can take up to a minute in challenging environments.
It is possible that your antenna offsets are slightly off or there is some type of interference that is causing the dual antenna to not get a fix. Also, is the system experiencing strong vibrations? That could inadvertently complicate the dual antenna fix.
Nathan
Another way we can debug this is to output a raw file that we can process on our end. If you change the settings below to the values listed, the driver will generate a raw data file. You can send this to the email I provided above and I can take a look at it. Please record at least 5 minutes of data. After recording this test data, you will probably want to disable it for your testing by setting raw_file_enable : False
raw_file_enable : True
raw_file_include_support_data : True
raw_file_directory : "/home/your_name" <- Change this to a directory on your computer
Hi Nathan,
Data sent.
Seems like the device is in Full Nav mode most of the time when testing, although I have seen instances where this drops. Currently our system is stationary so there should be no major vibrations.
Thanks!
This issue is stale because it has been open for 2 weeks with no activity. If the issue is still not resolved, please leave a comment describing what is still not working
This issue was closed because it has been inactive for 2 weeks since being marked as stale. If the issue is still not resolved, please reopen the issue, and leave a comment describing what is still not working