The Combine Forum banner

Ardusimple RTK

20K views 59 replies 22 participants last post by  Math 
#1 ·
One big question and that is in terms of output. While serial is a given, should the module have ethernet (wired) output as well as bluetooth? Wifi really has its issues in terms of real time, and I strongly feel it would be disastrous to output via wifi - also saves a lot of money in design and production.



So if you could have bluetooth, wired ethernet udp output, and serial output, would that suffice? Also enclosed in an IP67 box that sits on the outside on the cab or inside that outputs an nmea sentence with position, heading, roll and speed and the basics that AgOpenGPS can parse in a single sentence? Also of course be full RTK.



Would you use udp output? or just serial?
 
#3 ·
I believe a serial and wired ethernet should be a minimum. Bluetooth can be added inexpensively. I am on the fence on whether to house the simplertk2b boards and the "Arduino" boards in there own IP67 enclosure on the roof and run power + ethernet to them or house the simplertk2b boards in the cab next to the other PCBs and just have 3 SMA connections going to the roof (2X GPS receivers + one LORA radio/GSM antenna). I think the latter option would be cleaner from a wiring perspective.

I want to go down the UDP route but i am still using serial for now.

Side note but very applicable,
Based on dopperlgrau's comment in the PCB thread the simplertk2b board will output heading and position but only in UBX format so we will need an Arduino or ESP32 to convert the UBX messages to NMEA then we need to send that message serially or broadcast it via UDP.

Got some information from ardusimple:



  • If you use an LR kit with corrections coming over XBee, you only need to connect to 1 UART. This UART will give RTK position + heading, but only in UBX protocol
  • If you use NTRIP server, you will need 2 connections, one to send corrections to simpleRTK2Blite, and another one to read RTK position+heading in UBX protocol.


So I have to do a (small) redesign to free up two pins on the esp32 for an other UART that can be connected to the "XBee-Module". Means a second (or one larger) port expander is needed. (An ESP32 has so many IOs, and still not enough ...)
 
#5 · (Edited)
As an "ESP32 guy" I'd say: you get wifi and bluetooth so cheap, it'll be a bad idea to forgo this option.


Some prices (without VAT, only the parts) to back my claim:

  • ESP32-WROOM-32 module about 3,3 EUR, includes micro controller, wifi, bluetooth. Need only a few additional parts (resistors, capacitors) so total maybe 4 EUR
  • Ethernet about 4,6 EUR
    • The RJ45 connector with integrated magnetics: 3,1 EUR
    • Transceiver (LAN8720) 0,9 EUR
    • some more resistors/capacitors,ferites (one for higher Voltage)
  • RS232: UART <-> RS232 converter and D-Sub connector each about 1 EUR => 2 EUR
In addition you'll need a bit for power supply, USB (if you want to be able to program it without additional hardware), so I'd say saving 1 or maybe even 2 EUR on the micro controller isn't worth missing the wifi-feature.
 
#11 ·
Is CAN out of the question? Just notice some of the newer stuff is handling the positions over CAN now.

You just need to send the tractor company’s a polite message to share their can messages before you completely decimate their guidance business with your open source solution!

That might be when the men in black show up though...:22:

They seem to be getting smarter putting the basics behind password protected gateways as well. They really don't want to play very nicely, so it kinda leaves CAN out along with the mystery of which pgn's being used.


The other plan is to make librairies for UBX and use directly.



Ethernet wired udp, serial, and wifi. Would that be the minimum?
 
#13 ·
I also put myself on the pre-order list for the simpleRTK2B+heading kit.

CAN output would be handy but my top 4 output choices would be
1) Serial (both USB and DB9)
2) Ethernet
3) Bluetooth
4) Wi-Fi

I realize that NMEA2K is proprietary but it seems that equipment manufacturers are going this route along with others but how many options can a guy need?
That IP67 enclosure would be very welcome.
 
#18 ·
Hello,


If I understood well, the interest of the simpleRTK2B+simpleRTK2Blite is to have a dual antena system that can provide a very stable heading ? That provide directly in the GPS sentences (not in NMA but in UBX format) a more stable heading than the BNO055 : the heading calculation are directly done by the 2 boards and sends to the receiver ? With this system, the BNO055 is no more requested.


By reading the Ardusimple product page, I also discover that it is possible, with a 3 GPS antena configuration, to do a fully attitude calculation (so pitch/roll compensation). I do not know this method to calculate attitude. I made some resarch for my personal knowledges and I found some informations and publications (not fully read for now) :
https://www.novatel.com/solutions/attitude/#whatWeOffer
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19960017562.pdf


Has this solution already been considered, in order to replace MMA8451 or Dog2, especially if there now cheap GPS module like simpleRTK2Blite on the market ?
Did you know if it's more or less precise than an IMU ?


Math
 
#19 ·
Well the ArduSimple boards don't contain micro-controllers, so the relative antenna positions is pulled from a NED vector (North, East, Down from UBX-NAV-RELPOSNED). The math involved is high school level geometry, early teens stuff in my rough recollection of UK schools, probably late teens in USA.

I know people who've spent a lot of money on electronic compass solutions, and been very highly dissatisfied. The simple dual antenna arrangement is quite effective, especially if one can decide on a left-right, front-back orientation for the vehicle, based on the angle you've got critical interest in. Precision comes from the separation you can achieve between the antennas.

Not sure I'd build a 3-antenna system with ZED's, I'd probably opt for an L1 NEO-M8P solution for the secondary and tertiary antennas, would likely be fine on a tractor with a large open field. It doesn't even need a full RTK fixed/float solution to get a good vector model.

I do have a 3-shield motherboard on it's way.
 
#60 ·
Hello



Well the ArduSimple boards don't contain micro-controllers, so the relative antenna positions is pulled from a NED vector (North, East, Down from UBX-NAV-RELPOSNED). The math involved is high school level geometry, early teens stuff in my rough recollection of UK schools, probably late teens in USA.

I know people who've spent a lot of money on electronic compass solutions, and been very highly dissatisfied. The simple dual antenna arrangement is quite effective, especially if one can decide on a left-right, front-back orientation for the vehicle, based on the angle you've got critical interest in. Precision comes from the separation you can achieve between the antennas.

Not sure I'd build a 3-antenna system with ZED's, I'd probably opt for an L1 NEO-M8P solution for the secondary and tertiary antennas, would likely be fine on a tractor with a large open field. It doesn't even need a full RTK fixed/float solution to get a good vector model.

I do have a 3-shield motherboard on it's way.

Thank for your answer, I did not know the NED vector bedore. But I still doest understood how the NED vector is generate by the 2 boards without micro-controleur : you still need a micro-controleur to calculate the NED vector based on the data of the 2 antena ?


Thank,


Math
 
#20 ·
Math:- "Did you know if it's more or less precise than an IMU ?"


I thought the IMU offers relative positioning but wont accurately show the exact heading,

A super magnet would 'Bend the heading reading' from the IMU as it passes by. ( talking indoors, at close range, as an extreme case.)
Does the IMU heading need to be realigned by a GPS/other compass occasionally, or often like every minute?



For indoor work the IMU or Lidar or RealView is essential and the GPS is useless.
Outdoors, the GPS system is quite robust and exact accuracy can be closely achieved, whereas the IMU has no chance since that the earths magnetic field is not a perfect shape and external magnetic forces effect you differently from point to point.
 
#21 ·
https://github.com/aortner/f9dualheadingarduinomega


here is my first test and example of a dual heading and roll system with 2 ublox f9 and one arduino mega.

agopen is connected to the arduino mega receives nmea and sends rtcm.

mega is connected via uart to both f9.

passes trough nmea form first and parses and calculates heading und roll from second f9
 
#22 ·
https://github.com/aortner/f9dualheadingarduinomega


here is my first test and example of a dual heading and roll system with 2 ublox f9 and one arduino mega.

agopen is connected to the arduino mega receives nmea and sends rtcm.

mega is connected via uart to both f9.

passes trough nmea form first and parses and calculates heading und roll from second f9

Cool! is there any plan to put it all in 1 sentence like PAOGI ?
 
#25 ·
[It says I can post links now. I'll see if it works...]

[It still won't let me post links... Something about message count. I have about had it with TheCombineForum...]

I used the configuration files from here to set up moving baseline:
Search for "ublox-C099_F9P-uCS" and "github"

I had to swap uart1 and uart2 in the configuration to get it to work with the ArduSimple boards. And if you are using the radios instead of wires between the boards you probably have to lower the baud rate for the board-to-board connection.
 
#26 · (Edited)
Andreas, At first I had the same question as jsampson but after looking at your code it appears you are providing RTCM corrections to both boards and calculating heading based on the relative position of one antenna to the other, then you are using the MEGA to calculate the roll and heading from the difference of the two receivers and sending it to AGOPENGPS and AGOPEN is sinding back RTCM to both boards via the NTRIP caster.

Is my assessment of your code correct? And could we see a picture of your setup? I'm sure i know how you are physically wireing the two boards to the MEGA but just want to make sure.

I am assuming that your main receiver is off center from the tractor and you are accounting for this within the antenna offset in AGOPENGPS?

Excellent work! This looks like a simple solution to obtain roll/heading and fix data.
 
#27 ·
no, i am not providing the same rtcm to the two boards.

receiver A is getting rtcm from my base via agopen-arduino mega - uart to f9
receievr a is also running as moving base and provids itself rtcm to receiver B via xbee uart

i would also add the two config file at my repro the next days.
 

Attachments

#32 ·
Why not let gpsd (https://gpsd.gitlab.io/gpsd/index.html) running on a raspberry pi handle the gory details of receiving the data from the GPS(s) and then the data can be shared on any interface. The heavy lifting of parsing NMEA or ubx at 10Hz can be moved out of AoG and replaced by a simple json query to the gpsd daemon running on the rpi. gpsd is getting better and better support for F9P as we speak, and the new 3.19 version is about to be released.
 
#33 ·
But most folks aren't using an pi with AOG, nor do I think they really need the complication of another computer in the mix. For those already using a pi for other things it might make sense.

If gpsd (or compatible program) could run on Windows alongside AOG, then that might be an option worth implementing. In the meantime I'm sure Brian is open to patches that add gpsd json requests to AOG. That's what open source is for after all.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top