I would think any professional GPS receiver (ie RTK capable) would have 3D velocity and accuracy estimates available. I've never seen one that didn't. Of course that doesn't mean there aren't any out there.
Two questions. For the L1/L2 unit it seems to be only NMEA, is that right? The problem with NMEA is it doesn't give vertical velocity (or only with extensions) and it doesn't give the speed and position accuracy reporting we get with uBlox. It would be very worthwhile to write a driver for the GPS so that those are given, as the EKF uses those to provide greater position accuracy (it helps a lot with the weighting of the other sensors vs the GPS).
The second question is whether you've considered using the GPS_INJECT_DATA MAVLink message to carry the RTCMv3 data instead of having a 2nd radio link. It is far more convenient to carry all data from the ground station over one link. The GPS_INJECT_DATA message is designed for RTK GPS modules so that they can send arbitrary binary blobs from the GCS to the GPS via the autopilot.
Cheers, Tridge
Tersus GNSS > Andrew TridgellDecember 13, 2015 at 8:11pm
Hi, Andrew,
Great input!
we are investigating the solution how to send out the vertical velocity. It's very critical in your application?
yes. we will do a quick test using the GPS_INJECT_DATA Mavlink. Once we have some results, I will let you know
Vertical velocity allows the EKF to produce a more accurate position/velocity estimate, otherwise the only vertical velocity estimate comes from differentiated barometer and integrated accelerometers. Good vertical velocity is essential for many navigation tasks (eg. landing and takeoff). It is also important that the GPS provides good estimates of the accuracy of its readings, including horizontal position accuracy, vertical positiion accuracy and velocity accuracy.
You could provide vertical velocity either with a NMEA extension, or with a completely different protocol. ArduPilot has support for the native protocols of 3 RTK capable GPS modules now (Piksi SwiftNav, Septentrio and Trimble). Each of those can provide NMEA too, but it is far better to use the native protocol.
We'd be more than happy to add a driver for the native protocol of your receiver if it has one.
Another very important property of a good RTK GPS is that it provide good performance when RTK data (eg. RTCM) is lost. It's no good having a great RTK GPS then the vehicle behaving very badly if there is communication lost to the GCS. That is the weak point of some RTK systems. The performance needs to be at least as good as a uBlox. Having L1+L2 should really help with that.
Just to make clear I'm understanding this right; your system is not designed to receive corrections from external ntrip servers?
Or can I buy one unit, connect to the national cpos correction service here in Norway and enjoy cm precision on one unit?
Roger
Tersus GNSS > Roger AndersenDecember 13, 2015 at 4:05am
Hi, Roger,
our board can read RTCM message. so if you can receive message from the ntrip server, then convert to serial port, and feed into the Precis board. then it works,
our future board will have WIFI function, then it will be easier.
Cheers, Winston
Hullam Nagy > Tersus GNSSDecember 20, 2015 at 9:11am
Hi TersusAdmin,
In your DATASHEET OF PRECIS-B01 you mentioned:
"For details of Precis board configuration, please
refers to Precis user manual."
But I could not find it. Could you send me a link of this user manual?
Replies
Which company's RTK receiver is used on PRECIS-B01?
Seems to be
http://www.unicorecomm.com/www/english/2014923/n02678138.html
according to that site they support a custom protocol.
NMEA-0183,Unicore Protocol
so it may have the data we need already.
http://www.gps.net.cn/Images/UpFile/20121210111251914.pdf
I would think any professional GPS receiver (ie RTK capable) would have 3D velocity and accuracy estimates available. I've never seen one that didn't. Of course that doesn't mean there aren't any out there.
Looks interesting!
Two questions. For the L1/L2 unit it seems to be only NMEA, is that right? The problem with NMEA is it doesn't give vertical velocity (or only with extensions) and it doesn't give the speed and position accuracy reporting we get with uBlox. It would be very worthwhile to write a driver for the GPS so that those are given, as the EKF uses those to provide greater position accuracy (it helps a lot with the weighting of the other sensors vs the GPS).
The second question is whether you've considered using the GPS_INJECT_DATA MAVLink message to carry the RTCMv3 data instead of having a 2nd radio link. It is far more convenient to carry all data from the ground station over one link. The GPS_INJECT_DATA message is designed for RTK GPS modules so that they can send arbitrary binary blobs from the GCS to the GPS via the autopilot.
Cheers, Tridge
Hi, Andrew,
Great input!
we are investigating the solution how to send out the vertical velocity. It's very critical in your application?
yes. we will do a quick test using the GPS_INJECT_DATA Mavlink. Once we have some results, I will let you know
thanks,
Winston
Hi Winston,
Vertical velocity allows the EKF to produce a more accurate position/velocity estimate, otherwise the only vertical velocity estimate comes from differentiated barometer and integrated accelerometers. Good vertical velocity is essential for many navigation tasks (eg. landing and takeoff). It is also important that the GPS provides good estimates of the accuracy of its readings, including horizontal position accuracy, vertical positiion accuracy and velocity accuracy.
You could provide vertical velocity either with a NMEA extension, or with a completely different protocol. ArduPilot has support for the native protocols of 3 RTK capable GPS modules now (Piksi SwiftNav, Septentrio and Trimble). Each of those can provide NMEA too, but it is far better to use the native protocol.
We'd be more than happy to add a driver for the native protocol of your receiver if it has one.
Another very important property of a good RTK GPS is that it provide good performance when RTK data (eg. RTCM) is lost. It's no good having a great RTK GPS then the vehicle behaving very badly if there is communication lost to the GCS. That is the weak point of some RTK systems. The performance needs to be at least as good as a uBlox. Having L1+L2 should really help with that.
Cheers, Tridge
Just to make clear I'm understanding this right; your system is not designed to receive corrections from external ntrip servers?
Or can I buy one unit, connect to the national cpos correction service here in Norway and enjoy cm precision on one unit?
Roger
Hi, Roger,
our board can read RTCM message. so if you can receive message from the ntrip server, then convert to serial port, and feed into the Precis board. then it works,
our future board will have WIFI function, then it will be easier.
Cheers, Winston
Hi TersusAdmin,
In your DATASHEET OF PRECIS-B01 you mentioned: