Is it possible that there are simply just too many ‘parameters’ in the Rover firmware? (bloated code)
For the bulk of us who use it, we are simple creatures when it comes to requirements:-
Drive straight at constant speed from waypoint to waypoint - THATS IT!
Maybe someday this will be possible.
At the risk of sounding callous, you are speaking for yourself and not necessarily “the bulk of” users.
I chose ArduPilot specifically for its high degree of compatibility and flexibility at the known expense of simplicity. While my use case seems simple at face value, autonomous lawnmowing, it’s actually full of complex problems: path/coverage planning, GPS precision/accuracy, compass/heading issues complicated by whirling iron parts, etc. I’ve been HIGHLY encouraged, particularly recently, with the development team’s progress, receptiveness to feedback, and often very fast response time to incorporate fixes or features.
I do sympathize that simple waypoint navigation seems unnecessarily complex at times, but that, again, is a result of the intentional flexibility built into the software. For highly configurable flight controllers in a 6DOF flight environment, a rate controller like ArduPilot makes a ton of sense. For land navigation, that same rate controller can be somewhat difficult to tune properly for direct-to-fix navigation.
As such, I see your request for “simpler” control as a request for more complexity. I think at the root of it, you are asking for a heading controller as opposed to a turn rate controller, which would entail MORE parameters, and likely an additional library for inclusion to the code base.
The next few iterations of the firmware may address this in a slightly different way than changing the feedback controllers, though, and I look forward to it. @rmackay9 is working hard on incorporating S-Curve navigation into the Rover branch which may indeed help Rover-4.1.x or 4.2.x function more like you (and I) prefer.
I’ve noticed the dev team is highly attuned to the complexity of the parameter list and quite hesitant to include more of them. There are some great discussions in the GitHub issues and development topics where you can see their concern for adding complexity and, likewise, their desire for keeping the user experience as straightforward as possible.
Yuri, most certainly I speak for myself and I’m very grateful to those that have made this technology possible.
I also use a DJI drone for mapping from the air in areas where the water levels are very low offering a unique opportunity to capture that type of data.
When using this product along with Pix4D or DroneDeploy, I charge my batteries and plan my missions the evening before.
The following morning, weather permitting, within seconds my drone is in the air and as long as I have batteries on a circulation of cooling and charging the job gets done with perfect passes waypoint to waypoint the entire day.
No fiddling for 1-3 hours for an EKF issue and “Flight mode failed” error, or taking off fine then 2 hours in and now the craft is weaving across the water like a drunken sailer burning daylight with unusable data.
I heard of S-Curve Navigation this morning for the first time and looks very interesting.
DJI makes a great product for sure, and if you’re willing to shell out the money for their more capable platforms, they are very plug-and-play for even complex tasks.
The beauty of the ArduPilot ecosystem for aerial platforms lies not in its simplicity, but its highly adaptable configuration. So when the off-the-shelf systems don’t meet needs, you can almost always bend ArduPilot to your will on almost any platform. Of course, that means you’ll have to spend significant time “fiddling,” at least at first.
With my Rover mower, I have things dialed in to the point where I simply set up my telemetry/fixed base station, which only takes about a minute to deploy, fire up the mower and wait about 2 minutes for a good EKF alignment, and then let it do its thing, sometimes for hours at a time. Granted, it took a LONG time to get that level of setup simplicity, but some of that has been my own obsession with this as a hobby rather than simple utility.
Took me 3 years to dial our 3m craft in and as long as we don’t deviate from 3.5m/s we get very good performance.
Just imagine a struggling farmer that has had his crop growing for the season and come harvest, day one, his autonomous harvester starts up and does a great job.
The next morning it takes him 1-3 hours before it will even go into ‘Auto’ and 2 hours in it just starts wondering across the entire field destroying his crop.
I hear you. There’s a very steep learning curve to climb, and it’s sometimes a struggle. But check out this success story.
https://ardupilot.org/index.php/casestudies/case-automatic-tractor
I’ve definitely kept @John_Easton’s issues with “wobbly path” in mind and I think the improved vectored thrust included in Rover-4.1.0 should help and of course the upcoming S-Curves should too (that might be 4.2 or 4.1.x).
I think it would be good to take another look at the wobbly path issue with 4.1’s vectored thrust enabled so if you can come up with a log file I’m very happy to have a peek at it.
The “bloated code” question comes up every year or so and a few people have already responded but my 2 cents is:
Anyway, I think that the core issue is you want your boat driving in a straight line so let’s see a log file and dig into the details.
… after a bit more discussion, we think part of the problem is that we don’t have enough easy-to-use setup screen in Mission Planner which means users need to enter the parameter list screens. I don’t want to make promises I can’t keep but I might try and put some effort into designing some screens for MP.
Yes Randy, you were certainly key to getting the 3m AIMy’s running true, and they do a great job as can be seen below in our recent trip to Clanwilliam dam near Cape Town (South Africa).
However, if the speed is changed even slightly, or the weight distribution is changed slightly, she starts to ‘wonder’ off the exact path. This tells me that the software and the hardware is totally capable, but takes a really long time to find that ‘sweet spot’ in the settings.
Our new 4m AIMy that is currently only in ‘proof of concept’ stage, has good and bad days and is a lot more of a challenge as she carries a lot of ballast to make her a semi submersible in rough conditions and runs a lot faster at around 5.8m/s (21kph) when collecting depth data only.
When the final product on the 4m AIMy is completed, that is when I would like to work very closely with you as it is going to push the boundaries to the max as she is expected to be a ‘do all’ craft.
This means she will run light in calm conditions but as the wind picks up she will start to fill the ballast gradually to keep her stable as well as be capable of precise steering wpt to wpt at slow speeds for sidescan data and high speeds for contour only data.
This is going to be a massive challenge.
