A robot based on a hover-board, to shoo mobs of kangaroos off the paddock.

WIP warning

This project is a work in progress. In particular, check the issues with the BDLC motor controllers below.


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.

Working plan

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.

Some people object to moving kangaroos off the farm on the basis that it is their 'natural habitat'. It is not. Before the land on the farm was cleared and turned to pasture, it was bush. Many people associate kangaroos with the bush (fondly remembering 'Skippy the Bush Kangaroo'), but there are actually very few kangaroos in the bush because there is no grass. The land was turned into pasture, bringing kangaroos, and allowing them to breed up into plague proportions in many parts of the country. Shooing them away is quite humane - certainly more humane than the government bodies managing annual 'culls' - paying bounties to professional hunters to kill them.


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).

Kangaroos   Kangarouter
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.

Low Resolution KangarooThe foreground kangaroo actually looks like this.

Very Low Resolution Kangaroo 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.
It must be fixed so that the sides don't swivel in relation to each other (that's the mechanism that a hover-board uses to work out whether you want to turn).
The caster wheel should be in front, not the back (it's fashionable to put a caster wheel or caster skid at the back, but that will cause tip issues if the rover needs to brake suddenly).
The (in-wheel) motors are three phase brushless DC motors, which require appropriate controllers.
Suitable controllers are available on eBay for around $AU15 each.
It should be possible to use the original battery from the hover-board, though some have suggested that a higher quality controller might be required for 36V.

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.

Here are two detailed photos for anyone who wants to look at the circuitry.
And here is a close-up of (I presume) the built-in bluetooth speaker. That might be useful for the kangarouter to make growling noises.

Issues - joining the mob


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.

Issues - coveting thy neighbour's paddock


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.

Brushless DC motor control

There are many ways to control the hoverboard motors, but three options were explored.

The original hoverboard controller


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.

  • The packets for the two motors will in sync, and can be written at the same time.
  • The bits in the packets can be pre-computed, requiring very little computation per bit at time of send.
  • The bits can be written by writing directly into registers (instead of calling digitalWrite()), and hence
  • each bit can be written in very few clock cycles
  • There is some example code for this in the HoverboardNativeDriver module in the allegrobotics github, but it has not been tested. Experiment at your peril.

    BLD-300B Controllers


    This looked like a solid (though expensive) option with lots of positive interweb reviews, but:

  • Even though there is supposedly a digital interface (and this is actually partly detailed in the specifications), it's not clear how the connection works. It seems to do RS232/Serial through a RJ12 plug, and there are no well established standards for how RS232 should be wired over RJ12. A simple mistake could be very costly.
  • They run very rough at slow speeds. They go really fast, and seem pretty smooth at high speeds, but at slow speeds they judder like a worn clutch. Autonomous robots need to operate smoothly at slow speeds.
  • They are expensive.
  • ZS-X11B controller


    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).

    Build - hardware

    Kangaroos So we take these bits away.
    Kangaroos And we are left with the useful bits - basically the battery, the in-wheel motors, and the base.
    Kangaroos  Kangaroos
    So we fit these to a frame (some anodised 25mm aluminium tubing), and put a caster wheel on the front, and voila.
    (Actually I later replaced the caster for a smaller one and shortened the base.)
    Kangaroos The Arduino, controlling both ZS-X11B controllers are here in a temporary box. The voltage converters are for (later) 36V control to come down to 12 and 5V to power the Arduino, the Raspberry Pi and other components (not yet installed). This rig was basically for testing the motors controllers with the Arduino (but see later notes below).


    Motor test.
    medium small


    Controlling the ZS-X11B with an Arduino
    There are actually several types of ZS-X11B boards. The one I used has a pin pair between the hall sensors marked "PWM" for PWM input, and another three-pin group with a jumper (almost, but not quite like the one pictured). The jumper goes on the middle pin, and one other (one CW or ACW direction). So
    • GND from the Arduino connects to the GND pin on the PWM jumper. This is the one closest to the outside of the board (not labelled in the pictured version).
    • A PWM output from the Arduino is connected to the PWM input pin on the PWM jumper. This is the on the inside of the board (not labelled in the pictured version).
    • A digital output from the the Arduino goes to the middle pin of the CW/ACW pin trio (ie the outer pins seem to be 5V and GND, and the middle one is the input to the motor controller.
    See issues with this below.


    Kangaroos Everything seems to work, so put it in a proper box.
    I made space for normal SLA batteries because I didn't actually have any way to charge the 36V lithium ion battery which came with the hoverboard.
    Actually the original hoverboard controller has a charger in it, so I could have used that.



    There is a weird mix of batteries here. It's just for testing.
    There is no collision avoidance or detection on the rover.

    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.


    WARNING: Drive Failure wih the ZS-X11Bs

    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
    analogWrite(motorSpeedPin, motorPower);
    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).

    Cool links

    Get Allegrobotics updates on twitter
    How NOT to do kangaroo recognition - a fun clip to watch, but watch to the end and apparently any moving thing here is recognised as a kangaroo.
    How I hacked the self-balancing scooter - Drew's Blog.

    Leave a comment

    Something I'm doing wrong? Solved my problems? Got a better idea? Got a similar problem?
    Think I might have solved your problem? Ninety-nine problems, but your robot ain't one? Say so ..