MOWSTOCK – 2023, April 21st and 22nd

Want to “Thank” all involved in MowStock gathering!

Several folks drove a long way and in the end, we had 6 functioning autonomous mowers show up. So for the moment we claimed we had the “Worlds Largest Gathering of DIY Autonomous Mowers”! (Lots of laughs ensued.)

I think we all learned a new thing or two and generally had a great time. The most interesting part for me, besides meeting folks face-to-face, was seeing and discussing the different logical and mechanical approaches we took to the same problems.

Looking forward to the next time we can gather up. Onward!

3 Likes

Congrats to everyone !! Sorry to miss it. Onward and upward!

@ktrussell @Yuri_Rage and others: Recent video with 2 mowers working (for some reason it seems the default viewing resolution is low, and that one must manually select high resolution replay when viewing these videos from google photos):

1 Like

Looks nice, Chris. You have a lot of tree cover there. Do you loose RTK often? I have a potential area I may cut that will have a lot of trees. Currently, I’m mostly in the open.

Also, are you using active object avoidance (LiDAR or something similar) or just planning missions around your trees?

I do occasionally lose RTK, and it seems that it happens more under heavier tree cover… and I also have a hypothesis that it happens more when the trees are wet. When the GPS fix level is 4 or less, I pause, and wait, and resume when GPS level is 5 or 6 again. (This logic is implemented in my companion computer, not on the autopilot). I estimate this happens every 10-20 minutes in the most heavily wooded parts of my lawn. Usually the GPS drops to 4 for <5 secs so not a major factor. About once every 10 hours I have a pause that’s more than 5 seconds. I’m sure I will learn more about this as I mow at more properties this season.

Do you know if there’s a difference between GPS fix level 5 and level 6? Right now I’m mowing with either 5 or 6 because I think they both indicate an acceptable level of precision. But I actually don’t know this for certain.

No active avoidance, just mission planning around trees and obstacles. We record a perimeter, and record obstacles, using a mower. Then we use those recorded perimeter and obstacles as inputs to an automatic mission planner that builds the back-and-forth strips and navigates around the obstacles. We used the logic in this whitepaper as a starting point A novel solution with rapid Voronoi-based coverage path planning in irregular environment for robotic mowing systems | SpringerLink

Then of course, before beginning a mission, we visually scan the yard to ensure there are no new obstacles. Which works pretty well but not perfectly. Yesterday a mower met up with this yard waste bin.

GPS level 5 is RTK Float. Level 6 is RTK Fix. I have found that float is pretty bad. I stop if RTK drops below 6. @Yuri_Rage wrote a Lua script that does that. It can easily be tweaked to do what you are doing with your companion computer. A couple of years ago, a companion computer would have been required to do it, but the Lua scripting has enabled a lot of functionality right in the FC.

Thanks for the white paper reference. I am using the built-in Bendy Ruler OA with exclusion fences around trees. Unfortunately, the way it is implemented leaves a triangle after the obstacle. I have to manually insert some waypoints to fix that. It has worked well for me with that modification, however.

1 Like

@ktrussell @Yuri_Rage I have been experimenting with the horizontal accuracy reported by the GPS (h_acc in the mavlink message). It seems it may be a finer-grained accuracy indicator than the GPS fix type. The lowest value for h_acc (i.e. most accurate) I see is 14mm. When mowing in the open, it generally varies between 14 and 18mm. Then under heavy trees it can increase up to 50 or 60 mm. What do you think about using the horizontal accuracy (rather than the gps fix type) as the basis for stopping mowing when GPS accuracy falls?

Nothing wrong with that approach. Would need some testing to determine its true validity.

I haven’t had any issues just pausing on anything worse than RTK Fixed.

1 Like

Chris - I love the paper you wrote on path planning and optimisation. Much to think about.
Re obstacles, im thinking about monitoring vibration levels on theh mower - running over branches should generate a stop rather than push on through…

1 Like

(I didn’t write the paper… I just used it as the basis for my path planner)

I think the h_acc approach would be worth pursuing, but I have been very happy with just stopping when I lose RTK Fix, as Yuri says.

@Yuri_Rage’s TerrainDetector script might be a good start on using vibration levels to take some action. It has been a big help when I am mowing in rough terrain. It slows the ground speed when rough terrain is detected.

1 Like

Is path planning better compared to the Survey Grid from the MP? Did you build a custom software for it?

Survey Grid in mission planner is quite good (as is the spiral pattern). We used it a lot, including manually editing the generated paths to mow around obstacles.

Ultimately, however, we needed to automatically (i.e. quickly) generate a path for a property, including mowing around obstacles, so we built custom software to do this. (We actually generate several for each property with different strip headings, because we learned that mowing the exact same path week after week creates ruts in the grass). While we were at it we implemented a double-wide strip around the perimeter, a double-wide strip around each obstacle, and automatic repositioning from region to region. We’re satisfied with the results, although the paths it generates aren’t quite as efficient as doing it by hand. Here’s a screenshot of our custom path builder:

Chris,
if I may ask, are you generating regular *.waypoints file for the ardrurover with your custom software or generated path can be formatted & fed to the autopilot in some other data structure? Are there any autopilot limitations related to the number of waypoints?

Our companion computer sends waypoints to the autopilot using mavlink messages… It sends 100 waypoints at a time. The companion computer receives waypoint lists from a master controller program running in the cloud, which is where the master database of the missions is stored.

You could call your custom path planner something like Terra Rover Obstacle Navigation , to go with your Master Control Program :laughing:

Seriously though, that path planner looks great!

1 Like

I know it’s probably central to your business model, but I’m sure we’d all love to see an open source implementation of that planner, @Christopher_Milner. Zero pressure intended, of course. Excellent work, regardless!

2 Likes

I think what Chris has done with the custom path builder is what many would like to see in the GCS to route around known obstacles in the planning stages. Looks like it would be a lot of work to implement, but would be a big addition for the Rover people for sure.

1 Like