Is the Uart limitation of 115200 truly hardware on the M2, or can some higher speeds be added?
Ive been running GGA and VTG at max speed 921600 on some comparable test hardware, and have found clearing the data much faster has many benefits. Especially if numbers need to get processed afterwords like on a drone or machine. Also makes the rtcm3 be usable faster to the gps.
Even being able to go to 460800 drops the GGA transmit time 7.5ms to 2.5ms, compared to the 10ms transmit time of 115200.
921600 drops GGA transmit time to 1ms. The more NMEA messages you need the better going faster is.
The baud rates up to 115200 give accurate results, and they are just enough for many applications. So, it’d be great if you can share more details on how the higher rates would help you. How do you work with the NMEA stream in real-time and post-process the data?
The GGA and VTG data are being sent to a Teensy4.1 micro controller. The main task of the controller is to sync the imu reading of a Bno085 with the GGA and VTG information into one message. When sent the new message greatly improves the stability of the moving platform.
The issue is delay, the less delay between the gps fix and the imu data the more stable the control over rough ground. This effect should also work for drones in flight.
You have to wait for the GGA to finish to trigger the imu reading, longer wait times reduces the stability of the data noticeably.
Here is a video of AgOpenGPS $PANDA imu synchronization in action
Currently I can use the M2 with ethernet to TTL adapter with this system, but its slow and does not perform as well.
The trimble with native ethernet 100mbps, and Spark fun board at 921600 work much better for rover due to less lag. <=1ms including processor time.
Hi, your machins are getting heavily advanced Mr
The gnss or its output is not the issue here, its the software or controller that fuses GNSS/IMU into a 3D oriented position in space. I`m not sure how capable Teensy is but the way things work (at least with drones and precision instruments) is to rely more on the IMU and dead reckoning method.
In another way you could have gnss postion every 5 second and the IMU would compute the rest just fine. the Bno085 is good for 100Hz and should keep the orientation for at least 5 second with good enough accuracy.
I would start looking into the software and what kind of option there is.
What program are you runing?
The teensy 4.1 runs at 600mhz, and has a 10/100mbps ethernet port. Its capable of getting the data compiled and sent in +-0.001s after GGA is fully delivered.
The gps triggers the entire setup, once the GGA is fully transmitted. The gps runs at 10hz.
Both the F9P and BD970 outperform the emlid due to higher data transfer rates. The imu syncing helps immensely on rough ground.
Yeah, sorry. Its seems like the hardware is ok but the code is lacking (need more development).
This is few months ago and it seems imu and gnss is fused, thats it.
Creating good code is difficult and demanding especially when open source.
This project could benefit from looking into the drone with lidar. E.g GNSS/IMU/ODO/LiDAR-SLAM but without the lidar part and the accuracy. https://www.researchgate.net/publication/343782138_GNSSIMUODOLiDAR-SLAM_Integrated_Navigation_System_Using_IMUODO_Pre-Integration
Since its a slow moving vehicle in the ground without the high accuracy demand, this should be feasible with Pyton I think. You dont need a 5000$ imu for this.
No need to stress the data between the controller and gnss
My 2 cent is to slow down the gnss data rate and rely more on the imu. The imu can handle it self for few seconds. Run 2 or 3 imus to smooth out any deviations.
I think the M2 will have to stay in a slower support role of base position.
There is a reason even commercial machine control currently all run at a base rate of 10hz, Even a slow moving tractor is moving too fast for 5hz and you end up with wavy steering control. With faster equipment like sprayers 20km/h 5hz really had obviously poor control. Even at 10km/h every 10ms of delay puts your measurement off by 2.78cm (2.78m/s *100cm/m / 1000ms/s *10ms = 2.78cm), to clear a 82 character GGA message at 9600 would delay you 85ms from gps uart to final read at the processing devices uart, so you have travelled unknowingly 24cm into the neighbours fence at 10km/h. 9600 really throws a wrench into things, if you add VTG it takes longer to transmit the data, than the time you have to available transmit the data at 10hz. Going fast with data has nothing but benefits.
Ive tried multiple Bno IMU already, but you do not gain much. Bno085 is really the leader currently in affordable IMU technology its very stable on its own.
Much like the internet speeds moving to 1GBps, because of the obvious benefits. 9600bps is almost like printing off sheets of paper and entering it by hand at the next device, meanwhile what you wanted to measure has passed you by a long time ago.
Increasing NMEA speed has very tangible control benefits, data cannot begin to be processed until its transferred.
RTK with external imu.
Well, there is a major difference in your setup and the commercial ones. I reckon they have the imu built in or hard wired to the core, (like the built in imu M2 has). This way it process the raw data from both gnss and imu at a much higher rate taking into account psudorange and tightly coupled integration strategy.
When both raw data from imu and gnss is processed like this, then yes, faster rate is better and more accurate for moving estimates.
With external imu and rtk solution from serial, it can not utilize and process fast raw data from either components. Even though a solution can be output at 5/10 or 14 hz, it has already been introduces with several delays, we are talking many ms. With moving objects you are computing a position based on many milliseconds old data and trying to fuse this with an imu with ditto data, you`re in for a real mess. Faster gnss would just chock the system and do no good. Its better of to rely more on the imu as it also computes the attitude when dealing with external imu and FIXed solutions.
This is also somewhat why they dont do RTK mapping. With PPK you process all raw data with higher accuracy and resolution.
Yeah they go faster, I am not reinventing the wheel. I am just pointing out that Emlid has painfully slow data transfer rates that are most likely just software related.
The system works great, even better than commercial, just not with the slower M2.
I cannot do PPK, the Tractor must perform in the first pass in real life.
@PotatoFarmer
Are you certain that the transmission speed is the issue here? At 115200 baud a 140 byte message can be transmitted in 10 ms which would be just enough for a rate of 100 Hz.
The GPS won’t give you a precise position at 100 Hz though (unless we are talking about much more expensive setups). So at these data rates you have to perform dead reckoning anyway and that would cut the theoretical offset of a few centimeters down to millimeters.
Im looking to get the max uart speed from the internal chip of the M2. That way GGA and VTG can be fully transmitted in less than 1ms.
This allows the downstream microcontroller to read the full position and sync the gyro position and form an entirely different nmea sentence to be sent to the guidance system in less than 1ms
So the only real lag is the time it takes for the gps to compute the position from the satellites.
This is already working equipment, using two other brands of receivers. One which shares hardware with the m2’s internals.
I’ve looked into your question with our devs. Supporting higher baud rates is a complicated task that depends on both the software and hardware abilities of the unit. So, we can hardly do it in a short time. Still, we’ll research the options further. If there’s any news about it, we’ll let you know.
In the meantime built some custom performance hardware to accomplish the task on the rover side specifically for a PoE ethernet only version of AgOpenGPS.
