I purchased a used Ryobi 48v electric zero turn mower. It seems the motor control encoders are simple 0-5 potentiometers with 2.5v center equaling zero movement (5v full forward → 2.5v stop → 0v full reverse).
I’m looking for a simple way to generate an equivalent signal from ardupilot. Is there some way to do this using the stock firmware? I could potentially customize the firmware to generate an appropriate PWM signal to do this but was wondering if this has already been handled in the existing code. Preference is to keep the additional hardware addons to a minimum too; I’m sure the hardware can do the job (maybe with some minor PWM filtering)
Most autopilots only output 3.3V on GPIO pins. You should use an intermediate DAC on a separate piece of hardware to properly generate the signal, IMHO.
Thanks for the reply.
Thinking about it more it seems the thing to do is to just mechanically couple a traditional servo to a standard potentiometer. Simple and completely isolated.
I can add a DPDT switch which will permit me to toggle between audupilot control and manual steering too.
I think that’s actually far more error prone. You want neatly linear output, which you’d likely get from a DAC. You’ll get backlash and likely non-linear output with servo throw.
I understand the attraction. But if I could avoid mechanical linkage where pure signal control is possible, that’s the route I’d take.
Kind of coincidentally, I ran into your post today regarding the Nudge plugin you hacked together. It was helpful to get me started on a project with Mission Planner today. Thanks!
Agree it would be preferable to use a DAC but frankly I’m willing to tradeoff a little backlash with the advantage of complete electrical isolation. If this were a critical or mass produced commercial solution I could devise some optocouled DAC with an isolated supply but compared to the slop of mechanical linkages in my existing gas powered mowers this should be at least as good if not better. AP does a fantastic job of making up for mechanical deficiencies.
Glad the nudging plugin is of some use to you. Is there a repo just for these or would it be a good idea to do a PR to the main code? I have some others ideas in the works too.
I disagree, but so be it. You’ll get much better results avoiding mechanical solutions like that.
You can just PR against the main codebase, and it might be included.
I actually don’t use Nudge at all, but I used your code as a template along with @Eosbandi 's skeleton repo. FYSA, there’s a bunch of built in UTM utility methods/functions so you don’t have to do the geodetic calcs yourself.
Oh that’s very helpful to know, thanks.
Writing that plugin was a real effort of rummaging through the MP source and dusting off the old C++ chops. That skeletal code will help a lot.
Sadly some useful stuff isn’t public in the classes for example the ability to work with ‘rubberbanded’ waypoints (those selected with ctrl+drag)
Getting yet further off topic, is there a way to reload plugins at runtime? Each change required restarting mission planner.
I’m unaware of a mechanism to reload plugins. I’m a very novice C# coder, and even more novice at coding for Mission Planner.
I hate that you have to parse the UI element to get waypoints (or fence items), but it seems that’s the only way from a plugin. And in fact, I’m using an even more hacky way to store fence items, since they vaporize if you don’t have a vehicle connected.
I just tried controlling it with a 10k pot. It seems to have at least 10 degrees of neutral deadband which should help it deal with any backlash. It’s probably a “feature” to make neutral easy to hit. Frankly I’m surprised they didn’t opt for a hall sensor or something more robust but I’ll take it.
I’ll post updates as I go. Thanks again for the input!
1 Like
A little off topic again, but here’s a snippet for you if you’re doing more work with the FlightPlanner:
// convert user polygon to UTM
List<PointLatLngAlt> drawnPolygon = new List<PointLatLngAlt>();
Host.FPDrawnPolygon.Points.ForEach(p => drawnPolygon.Add(p));
List<utmpos> drawnPolygonUTM = GeodeticPolygonToUTM(drawnPolygon);
List<utmpos> GeodeticPolygonToUTM(List<PointLatLngAlt> polygon)
{
if (polygon[0] != polygon[polygon.Count - 1])
{
// ensure a closed polygon before converting
polygon.Add(polygon[0]);
}
int utmzone = polygon[0].GetUTMZone();
return utmpos.ToList(PointLatLngAlt.ToUTM(utmzone, polygon), utmzone);
}
Looks like a handy snippet for sure. Nice to see the host polygon is accessible in the plugin. I’d be interested to know if they’d be open to exposing more elements by way of getters and setters.
Whatcha working on?
I wrote a Lua script yesterday to do a very rudimentary version of BendyRuler around fences, but rather than just avoid the fence, it recaptured the original path (as for mowing) after the fence was cleared - a feature missing from the native OA algorithm.
It worked, and I’m quite proud of the result I achieved, especially in a short timeframe and few lines of code. But there are a ton of edge cases, and it seems that rather than tracking those down, I ought to do this:
Write a MP plugin that simply plans the mission around fences. It’s sorely missing from the feature set, and it’s a lot “smarter” than forcing the little STM32 to do all the heavy lifting around known obstacles.
Sounds like a great idea. I’ll be very interested in tracking your progress as I use MP exclusively for planning mower missions myself.
Curious, what have you been using in the way of obstacle avoidance? I’m still working on improving that myself as my current method is to watch it like a hawk with my finger on the radio failsafe 
Nothing. But I have some ideas on that, too.
1 Like
Just don’t go down the Slamtek Rpi C1 Lidar route as did I. The thing puts out gobs of data that overwhelms the FC. It might be made to be workable with a coprocessor but frankly I don’t think anything will be more reliable than a simple physical bumper.
Not interested. I’m about to array a couple of cheap ultrasonic sensors not unlike automotive parking sensors. But that’s a next week/month project.
And if you really wanna kick yourself, have a peek at the utility functions in PointLatLngAlt.cs. Your nudge plugin’s business logic almost becomes a one-liner with the likes of newpos().
https://es.aliexpress.com/item/1005004402592653.html
Input is PWM (not 1-2ms) and it will not move a DC motor.
As the autopilot transmits 1-2ms RC specific PWM then this device doesn’t seem useful.
Also it doesn’t look isolated. I have a concern about ground loops.
Nice. Not surprised there was a better way to do what I did. It was my first go at it after all.
I’d really like to see the plugin tools get more supported and complete. It is a great way to extend functionality in MP.
1 Like