Mobs of kangaroos hang around the farm, and compete with the stock for the available feed. This is a serious problem. Livestock in this country are currently dying due to lack of feed in the drought, and the mobs of kangaroos are making the situation worse.
The robot has a camera which monitors the paddock.
The pictures from the camera are analysed via a neural-net object classifier, which recognises kangaroos.
If any kangaroos are visible, the rover approaches the them with its lights flashing, and makes a growling sound through the speakers (a recording of a growling male kangaroo).
The kangaroos will not be distracted by the sight and sound, and (being prey animals) will not eat in the presence of the distraction, and will eventually leave.
When kangaroos are no longer visible, the rover returns to the observation position, and back into monitoring mode.
A neural-net running on a modern computer should detect kangaroos reliably enough to control a robot. Even a 90% reliability would be enough for the kangarecogniser to be highly effective. If the rover occasionally responded to phantoms, then so be it (provided it didn't consistently respond to the same one, such as the same bush on the property which looked something like a kangaroo, or a QANTAS logo on a nearby billboard).
These photos, taken with a mobile phone camera, feature many kangaroos. The first photo contains three in the foreground, and many more behind. They are easily recognisable to a human as kangaroos, but actually the images are quite poor.
The foreground kangaroo actually looks like this.
And the clearest one in the background looks like this.
A human could pick this, but a neural-net might struggle.
The (Galaxy S8) phone camera is 4032x2268 pixels.
A 'hi-res' 8M Raspberry Pi camera is only 3280x2464.
The 5M Chinese cheapies are only 2592*1944.
An alternative might be to put a zoom lens on the rover's camera and do some scanning, but that would involve more moving parts.
A few years ago everyone and his dog went out and bought a hover-board for around $AU350, and they are now appearing secondhand on Gumtree for around half that. These have quality in-wheel motors, and a sturdy frame capable of carrying a 100kg weight around on a flat surface, and move quickly - much more quickly than Grandma's wheel-chair is designed to.The hover-board base can be bolted to a frame, and a front caster wheel put into it.
So $AU140 and a 50 minute drive and this little gem was mine.
After riding it up and down the verandah for a few hours it was time to begin the dissection.
And here it it is with all its inner glory laid bare, with a single BLDC (Brushless DC) motor controller connected to one of the motors.
Note the ZS-X11B BLDC motor controller. I ordered a ZS-X11A on eBay, so of course they sent me a ZS-X11B. Thanks guys.
Apparently this is pretty standard from the suppliers of these things. So I ordered another one the same, and got lucky - they made exactly the same mistake again so I got two the same (I could hardly have demanded a refund of an item on the grounds that they sent me the right one this time!) The ZS-X11B relies on Hall sensors, but that's okay - the motors have them.
In fact this worked out well - Hall sensors are actually critical for manoeuvring at low speeds.
The rover should not try to come into contact the kangaroos, but merely to approach them. It should stop at some (configurable) distance away from them. There is no real issue with going into the middle of a mob, we are not trying to herd them in a particular direction (though that might be stage-II), but just to make them feel uneasy enough to eat elsewhere.
Kangaroos behave like prey animals. They won't put their heads down and eat with a potential threat nearby, because the have to take their eyes off the threat source. They will eventually just go elsewhere.
The rover should know the boundary of the paddock (and the location of fences which it can't cross). It should make an estimation of the location of any kangaroos it sees (based on the rover location, the size of the kangaroo, and it's direction). If the kangaroo is judged to be outside the paddock it should be ignored.
There are many ways to control the hoverboard motors, but three options were explored.
There was a prefectly good solution within the original hoverboard - it already had a twin motor controller in it. This is the most promising mechanism, but it will take some effort to reverse engineer the protocol, even following the basic formula which others have published. Unfortunately yours truly didn't consider this option when dismantling the hoverboard, and left some of the connectors rather short.
The protocol is, apparently, 26300 baud, 9 bit (!!!) bytes with no parity. One start bit, one stop bit, in 6 byte packets. Normally bit-bashing two pins at this speed wouldn't be recommended on an Arduino Nano, but we can take some short-cuts.
This looked like a solid (though expensive) option with lots of positive interweb reviews, but:
These are cheap and available on ebay/amazon/aliexpress. Many buyers on the interweb have complained that they get a different model than the one they ordered (the sellers can't tell the difference between a (Hall-less) ZS-X11A and a (Hall enabled) ZS-X11B, but you take your chances). They are quite cheap and powerful enough for a light rover, and can be controlled by PWM on an Arduino (but see the issues below).
Also the camera is not yet fitted (though there is a peep-hole in the front), and there are no flashing lights or speaker for growling.
Later testing suggested a problem with the ZS-X11B BLDC motor drivers which took a long time to work around.
When the rover is actually being run, the motors would just cut out, and not respond to the signals from the Arduino. On further investigation, the ZS-X11B drivers were shutting down, and required a full power cycling to reset them (they don't have a 'reset' pin).
I thought this was caused by the frequent reversing of the motors as the rover changed direction, but this was not the case. Modifications to only run the motors in one direction (ie never run either motor backwards) did not work - the drivers still crashed.
The solution was simple, but took much longer to find than it should have - the trick is to never actually fully stop the motors.
The Arduino Nano is used to drive the ZS-X11B, and driven by PWM via
one line of code
if (motorPower < 4) motorPower = 4; // NEVER go to absolute zero. Anything less than 4 seems to causes the ZS-X11B to crash.
Seemed to save the day, except that the rover would never actually stop - it would move slowly like a Tesla in 'creep' mode.
So the second solution was to use relays to turn off the power to the ZS-X11Bs whenever the power is set to zero (for more than 500ms).