Setting up a new simpleRTK2B+heading with a separate simpleRTK2B fixed base (see new tutorial from @jolivart). Sharp learning curve on setting all this up on the piggyback board with trying to learn everything from new. I finally got this setup and working (at least on test bot - rtk float or fixed on both boards with GPS yaw reporting), but not without a huge amount of headaches. I am currently sending RTCM3 corrections from the fixed base through Mission Planner. The simpleRTK2BLite (acting as a Rover) is getting the RTCM3 corrections on UART1 from the Moving Base (SimpleRTK2B) on UART2. The same UART1 is tied to the Pixhawk serial connector on the Lite board. My RTK data was not working on the SimpleRTK2BLite when plugged into the Pixhawk. I had to remove the single RX cable into SimpleRTK2Lite from the JST connector to stop TX coming from flight controller in order for the internal piggyback connection to work. I tried switching GPS_Inject to just GPS1, but this didn’t help. Someone more familiar may have realized earlier not to have RX coming into the a port from 2 different sources, but the documentation on the Lite board is not great. I assumed UART2 from Lite communicated to UART2 of Big Board and took a long time to figure out what was going on. Can someone with much more knowledge verify my findings?
I am fairly new to the simpleRTK2B (less than a week), but from my testing and experimenting this is what I found. Someone correct me if I missed something here. Planning on direct injection to Base and skipping Mission Planner. Baby Steps.
I read later after having ordered the SimpleRTK2B+Heading that 2 SimpleRTK2B boards would have been a better route due to how the piggyback connection occurs.
@jolivart@Yuri_Rage@ktrussell First of all thanks to everyone that have paved the way to making things much easier on the rest of us.
I need some help on an additional item that one of you guys could probably verify my thoughts. I have the piggy back simplertk2b boards. I am having problems injecting RTK data directly to the Moving Base board. From the diagram that Kenny has on his Youtube video (ArduRover 4.1.0-Dev Moving Base Config (GPS for Yaw) using UART2 for RTCM3 Corrections - YouTube), I should be injecting RTCM3 data from the fixed base into the RX2 on the Moving Base (TX2 as labeled from Lite side). I am not seeing my RTCM3 data in U-Connect when I connect it this way. My thoughts are the same as the thoughts above. As these pins are directly tied to the UART1 of the Lite board. The Lite board is sending UBX-NAV messages to the Pixhawk through TX1 which is tied to RX2 (labeled TX2) on Big Board. The injection just gets garbled into the existing comms and doesn’t work (nor should it).
Are my thoughts sound on this? Does anyone know if I could inject RTK data into the USB of the Big Board (Moving Base) or is the only option to physically separate the 2 boards and jumper them together adding in UART2 on the Lite to work around connection issue with the piggyback. This is all without XBee so if boards are separated, then then they would have to be mounted again or wire external USB to talk to Lite Board to update/monitor.
I’m sorry. I don’t have much experience with the piggyback boards, and I don’t particularly like them for the precise reason that you’re having so much trouble. They are not well suited to ArduPilot in my opinion.
ArduSimple recently released a new config that may alleviate some of your problems. Check their website.
I am using the new config file/tutorial (ArduPilot simpleRTK2B+heading configuration + external corrections). I figured out a way to make this work with doing direct injections outside Mission Planner, but again 2 SimpleRTK2B would be the way to go for anyone that comes across this forum before ordering. I read a bunch before ordering, but just missed that suggestion. In order to make this work using the new tutorial is to move all the Pixhawk communication to UART2(XBee Module Socket) on the SimpleRTK2BLite board. This frees up UART1 to receive data from Big Board’s UART2 and to allow RTK external data to be injected on Big Board’s UART2. In order for UART1 on the Lite Board to not interfere with the RTK injection on UART2 of Big Board, UART1 output needs to not output any data (UBX/NMEA/RTCM). This also means killing USB connectivity using the Big Boards MicroUSB to the Lite Board as it uses UART 1. Any additional configuration/upgrades needs to be done through a FTDI MicroUSB attached to UART2/Xbee Socket.
Wish I had ordered 2 of the Big Boards, but hope this helps anyone who comes across this and needs help getting this to work. Sitting with rtk Fixed on both boards right now with GPS Yaw working using external RTCM injection across Yuri’s ESP-Now-Burst-Serial-Bridge (GitHub - yuri-rage/ESP-Now-Burst-Serial-Bridge) link from fixed base.
*** After further testing, the UART1 from the Lite Board is messing up the GPS inject on the Big Boards TX2 (no oscilloscope to see if it outputs timing when not putting out messages). When I separate the boards, then Big Board sees RTK injection. Put them back together and injection gets messed up and Big Board can’t read messages. Separating the board seems like only option for direct external injection. I think I am going to turn the Lite into my Fixed Base station and free up the other Big Board to do this right. How frustrating!
For what it’s worth, I followed these steps ArduPilot simpleRTK2B+heading configuration + external corrections , and it worked first try. My config is Pixhawk4 + SimpleRTK2B + Raspberry Pi (running mavproxy sourcing ntrip corrections using the mavproxy ntrip module) .
I have GPS yaw and also precise rover location. My receivers are 1.18 meters apart.
How are you injecting the RTCM data into the moving base (big board) in your setup? I was having issues trying to inject into the moving base board with the rover board (lite board) connected to it at the same time? I bought a serial XBee board to plug the Lite into as a way to configure the Lite. Any insight might help figure out how to do this. I separated the boards and have everything working, but would be better space used if I could get them to work connected together.
I have a companion computer (RPi) that is connected to the Pixhawk (via regular UART). Companion computer runs mavproxy. Within Mavproxy I use the ntrip module. The ntrip module gets corrections from a rtk2go site, and sends them to the Pixhawk, which sends them to the GPS.
It’s been a while since I posted an update… Today all systems were working and I was mowing. This rover has a 3-blade 54" deck and mows much faster than my prior 42" deck.
Christopher, that is an awesome build! I was going to ask about runtime, but I see your answer below. That is quite good. I have not been on here as much as I should, so I apologize for the late response! I’ve got a little work to do to get my “new” mower running and have not had time. Some GREAT friends gave me a big jump start. I’ll report soon!
I look forward to hearing more about your mower as you get more time with it operating.
Unless something has changed with ArduPilot recently, don’t use 10Hz. It will work and may lull you into a sense that the faster rate is even working better, but @tridge proved quite conclusively to me that the higher update rate is detrimental and results in higher EKF yaw innovations (at least on a Cube Orange with ArduSimple hardware as of early last year).
EDIT: Just saw that you’re using 4.1. 10Hz is a bad idea for sure with that firmware. I know there have been some improvements to the uBlox GPS drivers since, but I don’t think any of them overcome the message rate limitation with moving baseline configs.
Unless a developer weighs in to the contrary, keep your update rate to 5Hz.
If you are experiencing issues with straight line tracking, it’s not a GPS position problem, but rather a known limitation of the position controller in Rover 4.3+ which is under revision as we speak. We have collectively given S-Curve nav a bad name by blaming it for the issues, but in reality, it isn’t the S-Curve turns to blame, but rather the entirely new nav controller that happens to also calculate S-Curves.
If I recall correctly, your vehicles are all electric, which should make tuning the position controller a bit easier than the boats and hydrostatic stuff that has proven very stubborn to tune well with the new control scheme.
I have noticed a bit more left & right “seeking” while driving a straight line after upgrading from 4.1.x to 4.3.x, but, performance is acceptable to me. I have a 1.37 meter wide deck and I space strips by 1.2 meter, allowing 0.17 meter of overlap. I’m sure I haven’t squeezed all I can out of the controller tuning. That said, if there’s an improvement in the pipeline, I’ll gladly use it! Of course it would be nice to squeeze another 0.1 meter strip width, another 8ish % efficiency.
For me the biggest efficiency gain will come from turning without stopping (i.e. not doing pivot turns). Depending on the lawn I’m mowing I can spend up to 30% of my time (and battery) doing pivot turns…
In my experience the electric drivetrain has lent itself to the Ardurover tuning pretty well.
U-blox max frequency specs with ZED-F9P firmware v1.32 are:
7Hz with full constellations
10Hz with GPS+GLO+GAL
many people use it at 10Hz with full constellations but they may lose some epochs from time to time.
Unfortunately I don’t field experience working at high frequencies with Pixhawk+Ardupilot
@Yuri_Rage could you take a look at this logfile and let me know what you suggest? The mower would arrive at a waypoint, then, start to turn, but would turn very quickly and overshoot the heading at which it should leave the waypoint, then oscillate around the path (gradually oscillating less and less) towards the next waypoint. https://drive.google.com/file/d/1OlXQAcEqRX3eC52ald0IPRtXZYj4QTFI/view?usp=share_link
cc @rmackay9 in case you want to take a look… I think the lower level speed and tuning controllers are working well, and I started with the recommended default values from here Tuning Navigation — Rover documentation (mostly).