It has the 4072.0 message, so presumably the secondary unit in the Moving Base configuration. Not the primary receiving data from the radio link.
RTK Float means it’s resolving to around 20 cm, if it doesn’t transition of RTK Fixed, you’re going to have to look at the quality/effectiveness of your antennas
So if the float means resolving around 20cm, i have set my base station at the accuracy of 2.5 metres as a initial and now kept as it is. Should I have decrease the base station accuracy to 20cm?
I think you probably first need to get all of the plumbing working first.
I would probably avoid using Survey-In methods, as these aren’t particularly accurate or repeatable. I would recommend using a fixed and consistent value for the position, so the data collected over time is consistent. Set this position in via UBX-CFG-TMODE3.
I would use a Post-Processed Survey method to determine the position, using a solidly fixed/permanent mount for the antenna.
But yes, if you’re spending this much effort to get cm accuracy, you don’t want to be introducing metres of error.
I followed the youtube video fr updating the firmware on simplertk2b lite. Got this error when updating firmware for simplertk2b lite board. I tried it with different com port, tried with separate ftdi ttl cable to UART of the Simplertk2b lite board but still this error arrives.
You might need a suitable USB-to-XBee adapter.
I would use 38400 baud as a default for a working ZED, and perhaps 9600 baud if it’s in SAFEBOOT mode.
Failing this, perhaps work directly with the support staff at ArduSimple about specific techniques for the Lite board,
Hi clive,
I have inserted the moving base on top of the budget board and make it as a heading kit. Above that moving base I connected radio through uart pins. Now when I connect my usb cable on xbee socket and given to pc to configure and get data from moving base as per said in this website https://www.ardusimple.com/simplertk2heading-hookup-guide/ Now i didn’t make any changes in the moving base and rover configuration files given in that website.
Since i got instructed by my tech lead that fix data will get in moving base, i was seeking to get fix data in moving base. But I got 3D/Dgnss/fixed only in rover board, and no fix in moving base. In the both moving base and rover board the no rtk led is stops glowing. So, I have doubt that maybe there’s some problem with the software. So now we’re trying to launch ublox package in ros using linux laptop, to check whether we acheived rtk. is there a some process in rover board to make the data send to laptop. I have also asked to ardusimple team, and your inputs also more valuable to us.
This is I got in moving base
And this I got in rover board
Show how your PixHawk connector is wired up, that you’re using to get data off the Moving Base (Lite) unit.
No, currently we’re not using pixhawk connector.
We power and configure the moving base using xbee port.
The usb on the top is xbee port and i connect it to laptop. At the final output we will use Intel NUC
The top-side XBee should be configured for RADIO connectivity. It shouldn’t be outputting anything. The Pixhawk connection is where you typically take/expect the position feed.
The down-side XBee on the Lite should be pushing RTCM3 to the Budget.
For the top-side XBee to output position, you’d need to manually enable UBX-NAV-PVT and SAT for the time being.
Our requirement is position and orientation in the rover. So that we will feed that to Intel NUC. Now are you saying that position and orientation will get from pixhawk connector of the top or bottom board?
Ok, you’re showing me screen shots of uCenter, I’m telling you what’s going on.
Yes, you can get both a position and an orientation from the lower Budget unit, HOWEVER the position is a Second Order one, it’s derived from the upper Lite unit that has an actual First Order position solution from the Fixed RTK Base.
If you want the best cm level solution, you’d take it from upper Lite unit with the RTCM3 fed via the RADIO link.
I don’t see a RADIO in your stack. So would need to assume you’re going to push in data via NTRIP, this would need to be the upper Lite unit.
@Rakesh16 have you considered a magnetometer, like hmc5883l, for heading? You would need to calibrate it once in the rover, but should be a cheap solution for a compass.
Generally they are very difficult to calibrate and keep in calibration, whether its effected by the metal of the vehicle, equipment, outside, or iron ore in the surrounding rocks and ground.
As an additional sensor, disciplined via dual-antenna GNSS, it can augment for sure.
Hi clive,
Currently we got fix data on both rover and moving base. In ros driver We tried running the ublox driver GitHub - KumarRobotics/ublox: A driver for ublox gps to get gps data in ros system. While launching the node I get this error “ERROR: txbuf alloc”. The baudrate is set to 115200. In the forum u-blox Portal. Here in ubx-cfg-nmea I change the verbose channel to 16 channel receiver. But I don’t know what message to reduce in GxGSV output. In GxGSV output I got this messages
Kindly help for this
Thanks for guiding throughout till here
Regards,
Santhosh.
At the top-level GSV there you can Right Click to Disable (Child) Messages, or descend into UBX-CFG-MSG and you can cherry pick settings.
Typically you don’t need/want GSV at 5 Hz, do select the ports you’re using and plug in the Hz value to decimate back down to 1 Hz.
The “txbuf,alloc” means the volume of data on the slowest port is too high.
Operating at 10hz is our requirement so I am unable to decimate to 1hz. I hope that disabling gsv messages won’t affect the gps fix and heading.
You misunderstand, you don’t need satellite visibility messages at 10 Hz, perhpas not even 1 Hz, they generate a lot of message data that’s not needed. You can have the solution rate and the GSV messages rate set separately.
As of my understanding, i disabled the nmea->GxGSV at the rover board
Is the Base Station having data volume issues? Throwing warnings?
Is it interfering with the task of getting RTCM3 data to the Rover(s)?
You should cull messages you’re not using. Knowing what satellites/bands are available is a useful diagnostic, but doesn’t need to be a flood of data. The UBX-NAV-SIG messages might be more concise and efficient at communicating data than NMEA GSV
Hi Rakesh,
That sounds like an exciting project! For cost-effective GNSS RTK, many teams use u-blox modules like the ZED-F9, it supports both base and rover setups and delivers centimeter-level accuracy with proper correction data. It also offers decent heading with dual-antenna configurations. For setup, ArduSimple boards are beginner-friendly and well-documented. I’d recommend checking their tutorials and videos they walk through configuration and data streaming clearly.