We have a mobile robot using ardusimple devices configurated as follow:
- simpleRTK2B (using ZED-F9P, used as “heading” board) –> srtk2b+heading_rover_F9P_FW_HPG112.txt
- simpleRTK2Blite (using ZED-F9P, used as moving base and rover) –>srtk2b+heading_lite_movingbase_FW_HPG112.txt
- XBee Long-Range
The rover recieves the correction from a simpleRTK2B board configurated as base station (with its XBee LR module) (config file: srtk2b_base_FW_HPG112.txt). We need this configuration not only to get a good gps position but also to get the heding of the platform in order to know the position and orientation of the robotic platform.
We check the RXMRTCM message to control that the heading board receives the corrections from the moving base board, and to control that the moving_base board receives the corrections from the base station. Apart from that, we changed the navigation rate to 5 Hz and the baudrate to 460800 as ublox recommeds (in moving base application note).
Using this configuration, we obtain not enough good accuracy for our localization purposes. If we only use a base-rover configuration (without the heading device) the accuracy is much better (under 3 cm).
We are using a ROS driver and we have observed that the moving base stops publishing its messages when a certain accuracy is reached. We are not sure if this is a right behaviour.
The bit from flags in UBX-NAV-RELPOSNED message corresponding to ismoving needs to be 1 in the moving base and also in the heading board, does it?
Also, we have some doubts about how to place both antennas (heading and moving base). Can they be placed at different heights? Should they be x-aligned or y-aligned?
Thanks in advance,
A fews checks:
1. You mention you increased the baudrate to 460’800. In which interfaces? If you only did it in the interfaces for moving baseline corrections, you might be experiencing buffer overflow on the other interfaces, as the units are trying to send too many messages over there.. When this happens the rtk solution starts behaving strange. You can confirm this by checking the message ubx-nav-comms, there’s a flag of “overflow”. Is this your case?
2. If above is not your case, I would suggest to go one step back and try the system at 1Hz with our configuration files as you downloaded from our configuration page. In this setup, does it work reliably?
3. Did you also increase the baudrate of the static base station? This is not necessary, as the corrections of the static base station are valid for a few seconds, and it will create a problem in the LR radio link, as it cannot cope with so many corrections. Is this your case?
4. Regarding antenna location for moving base – rover antennas. There’s no problem if they are not at the same height, you will get the relative vector between them. Important is that distance is minimum minimum 0.5 or 1 meter for achieving sub 1 degree accuracy.
3. Regarding antenna installation, it is not relevant
1. We have increased on the simpleRTK2Blite board (moving-base) the UART1 conection with the rover board to 460800, keeping the Xbee UART baudrate at 115000. On the simpleRTK2B board we have increased both UART1 and UART2 baudrate to 460800. We can not find the UBX-NAV-COMMS message, so we can not check the overflow flag. Could you indicate to which message from u-Blox ZED-F9P Interface Description document corresponds the ubx-nav-comms message? Do we have to increase the Xbee UART baudrate to 460800?
2- Your proposal consists of set to 1 Hz and 115000 baudarate all the above configurations, does not it?
3- On the base station we have increased UART1 baudrate to 460800 and navigation rate to 5 Hz. Following you sugestion we will decrease navigation rate on the base station back to 1 Hz and UART1 baudrate to 115200 and prove with your default configuration.
4-5 As it is indicated in ZED-F90 Moving base application (Application Note document), mounting the two antenas on the X-axis will give heading information. In our robotic platform, the x-axis is aligned with the forward direction, then, do we need to align both antennas with the x-axis (in a similar way that represented in the Figure 2 in page 5 of the application note)?
Thanks for your support
From what you describe, there is high probabilty that problem is coming from static base station working at 5Hz. The rest from your answers seem ok. Let us know how the results are.
We have chnage the frequency of the base station and it seems to work better. Nevertheless, the results are worst than using only the base station – rover configuration (without the heading option). Do you have any idea? Is there any way to check both configurations at the same time to compare them? Some times the signal suffer from strong jumps that makes imposible to use it to localize our platform.
Apart from that we have some questions regarding to the obtained results:
– The view of sky is very important to receive a good gps value. In our application, some times the robotic platform travels close to buildings and it seems that the accuray of the position decreases. When the platform comes back to an open area, it does not recover the previous accuracy. It seems that the position suffers from accumulative errors. Is it possible? Could you describe what the expected behavior would be?
– For the base station we tested two types of antenna: ANN-MB (without ground plane) and Survey Multiband antenna. Depending on the weather conditions, the survey multiband antena provides better results. For the moving platform with heading, we use two ANN-MB antennas. Could be improved the performance using the Lightweight helical antenna type? For size reasons we can not use the survey multiband antenna on the robotic platform. Would you mind to recommend us the better antenna configuration in order to get as much as accuracy as possible?
(In order to show our results, we would like to attach some images to the post, but I do not know how to do it).
Thanks in advance.
– There should be no degradation on RTK position when using heading add-on, as long as you read the position from the moving base. The position of the new rover will have accumulated error of both the fixed base station – moving base, and moving base – rover connections. So if you read the position of the rover yes it might be a bit worse than previously without moving base. But solution is to read RTK position from moving base only.
– Regarding recovery when losing view of the sky. There might be some period of recovery yes, but if you have RTK corrections it should go back to the “good” track very fast. I’m afraid you might be experiencing loss of RTK corrections and this is why it seems like it takes so long to go back to the “correct” path after a challenging environment.
– In terms of performance, Survey is the best, and ANN-MB is better than helical. Our recommendation to increase performance without jumping to the survey version, is to add a ground plane of minimum 15cm diameter.
– We have test with your configuration files downloaded from your configuration page, and using the u-center application, we have checked that the moving base stops providing the position messages once it starts to send the corrections to the rover. I mean, at the beginning it publishes the messages and once it receives the corrections from the base station and its accuracy is good enough, then the moving base stops publishing the position. So we can not read the rtk position from the moving base as you suggested. We recorded some data from both the moving base and the rover in static position. How could I send you this files? We did these tests with the survey antenna for the base station and the other antennas with the ground plane.
– We have check the flags value from UBX_NAV_RELPOSNED message in order to detect if there is a lost of data. We checked the refPosMiss and the refObsMiss and there are only occasional miisings indicanted by refObsMiss value, but these missings do not correspond to those areas where we observed evident jumps in the position.
Thanks in advance
you can send logfiles to email@example.com
1. How are you reading the position from the moving base? NMEA or UBX-NAV-PVT should be used.
We have sent the log files to the indicated email.
We try to read the position from the moving base using the pvt message, but as we mentioned before, once its accuracy is good enough, the moving base stops publishing the messages.
It was a configuration issue, resolved by on-site support.