KevinG's Autonomous zero-point turn Lawn Mower

Hey Yuri! You are my hero!


Thanks for the efforts on getting GPS-for-yaw working. I’m very surprised to hear that with ArduSimple it must be setup so that the two GPSs are connected together.

I’ll add @ktrussell’s 3 suggestions to our “requires investigation” section of the Rover-4.1 issues list.


but what about using the lite version and the classic version, should we also use wires or we can stack the lite on top of the classic? @ktrussell @Yuri_Rage

1 Like

It appears those boards are designed to be stacked “piggyback” style, specifically to support GPS heading applications like this. I have no experience with them, personally.

I am talking with someone from ardusimple and quotting them

"Your setup will not work, since the flight controller is connected only to the rover, so corrections forwarded by rtk injection tool will collide with the corrections from the moving base.
If you want to use corrections from a fixed base, we suggest you use an alternative radio link, only for the corrections (we have radio links for this purpose ranging from 1km to 50km in ideal conditions).

Seemed weird that the lite board would not be connected to the flight controller since it has a header for that

Without more context, it’s very difficult to help. As far as I know, both boards should be connected to the flight controller via their serial port headers, with the standard (bigger) board designated as the (EDIT) rover.

Recommend you get Josep’s attention in this thread:

1 Like

Joseph from Ardusimple posted a tutorial on setting up the Ardusimple classic and light boards piggyback on the gps-yaw-debugging thread.

Randy (@rmackay9), I was looking over the Dev Call post yesterday and saw that a suggestion from me referenced this long thread. I think many of the issues/enhancements I might have mentioned have been taken care of.

So to summarize: The only request I have is that there be a parameter for specifying the baud rate to which Ardupilot will configure UART 2 on the two GPSes for their direct connection when using GPS_DRV_OPTIONS=1.

Otherwise, I am super happy with the auto config and how well GPS for Yaw is working.

1 Like

can you explain why this is needed? It is set to 460800 now, and that should be a good level for RTCMv3. We could make it configurable, but that would make the code more complex so I’d need to have a good reason.
Note that you can do this:

  • use GPS_AUTO_CONFIG to get standard settings
  • wait for it to finish config and save settings
  • then disable GPS_AUTO_CONFIG and connect with u-center to customize some settings you want

My reason is that I am sending RTCM3 from my Fixed Base to the Moving Base outside of Ardupilot. I am using telemetry directly from the Fixed Base into the UART2 Receive line on the MB and sending RTCM3 from the MB to the Rover on the transmit line. The RTCM3 from the fixed base is coming in at 115200, as that is the rate my LoRa board supports as far as I can tell, so that is the baud I need to set for UART2, and thus also the baud needed on the Rover’s UART2.

The diagram below shows my setup, which personally, I think is a superior way to get the RTCM3 from the fixed base. It ties up zero resources of the flight controller. But, I realize others may have a different opinion.

I certainly can work around the auto config issue if it is a lot of complexity. It would just be one new parameter from Mission Planner and that value used to set the baud rate for both GPSes rather than a constant. I didn’t think it would be complex at all, but I certainly don’t know. It is somewhat of a nuisance to go into Ucenter every time a new version of ArduRover comes out. I try to keep up with the betas and/or dev versions. Currently, I am keeping my local repository up-to-date and compiling my own version with 115200 baud in to the AP_GPS_UBLOX.cpp.

If it is too much trouble to add this feature, I will likely figure out a way to fix the issue externally. I can get the baud rate to 460800 by hook or crook. Again, I just expected it to be easy and add flexibility. I do know one other person who is using my exact scheme as well.

Thanks for considering the request. No hard feelings either way. :slight_smile:

1 Like

ok, that is quite unusual. Normally that global RTCMv3 data is sent over mavlink to the flight controller, which distributes it to the right GPS ports.
If you want to continue sending it into UART2 on the moving base then you’ll need to manually configure the settings. You may find that 115200 isn’t enough for the RTCMv3 data between the GPS modules though.

I’ve been running this way for over a year very successfully. I see no reason to use any resources in the flight controller when there is a 2nd port that can take the RTCM3 directly. I guess a future update to RTCM might use more bandwidth, but so far so good.

Thanks for considering the enhancement. I’m a little disappointed, but I’ll work around it. I appreciate all you guys do!

@Tridge and @rmackay9, I feel dumb but happy. I hate to admit it, but I just changed the baud rate on my Adafruit Feather M0 LoRa board to 460800 and it worked! I really thought I had either tried it before or that I had read in the docs that it did not support that rate. Anyway, all is well with me on the stock code now.
I just thought I’d climb out of my embarrassment and confess it! :slight_smile:



Great news! That keeps things simple for us in the flight code so happy days. Txs for the feedback.

One more 2 cents worth: In my experience, I have rarely seen baud rates that are hard coded. They are almost always configurable. It seems like that would be something you would want. BUT, it is not a show stopper, just an observation.

EDIT: I do realize that in this case (and many) that there is a minimum that will work.

I appreciate all you all do!

1 Like

I am getting back to building my zero-turn mower and I just wanted to make sure I install the correct firmware into my orange cube. I have been away from the blog site for a while due to family issues and an injury situation (a roof collapsed on me). Anyway, I am back and I have a bunch of my electronics temporarily wired together on my workbench.
I am using the Orange cube with the intention of doing GPS-Yaw steering using a simpleRTK2B and a simpleRTK2Blite boards (piggyback connection). My question is which version of the version 4 firmware do I use? I noticed Josep from Ardusimple used Ardurover v4.1.0-dev. I notice on the firmware download site the latest is 4.1.3. Which one will be best for me to use?

1 Like

Glad you’re back and doing well!

Download the latest stable, which is 4.1.3. There are no negative changes that impact the moving base configuration.

I notice on the firmware for the Orange Cube there are 2 versions. What version of Ardurover 4.1.3 do I use?


You don’t need bdshot - that’s for copter ESCs.

1 Like

Well Yuri I decided to move some of my questions to the blog site at the risk of showing my lack of knowledge but it might help someone else also. I am still learning this system but making solid progress everyday. I am starting to understand the parameter and configuration settings but I am still having trouble. My goal right now is to move my first servo motor with the joystick. I have an independent 5.3 volt power to the servo rail. I have the two D845 servos plugged into the rail and I know there is power on the rail. I have the Flysky FS-I6X joystick connected to the FS-IA6B receiver and the two are properly bound together. Here is the test setup:

On the radio calibration page in Mission Planner I can move the paddles see the signal move up and down.

What have I missed here? A simple movement of a servo arm would make me smile.