perimeter fence detection

There seems to be very little information about the robomow perimeter fence, apart from the obvious that an alternating current is passed round the perimeter wire producing a magnetic field.

To detect the magnetic field I first attempted to reuse the sensors built I to the robomow on the assumption that they were induction coils with a lm386 amplifier, but I got no signal from them.

I got hold of some 100mH induction coils and wired them up to the lm386 amplifier and discovered the signal!!!

It appears to be a square wave of about 4.5kHz with roughly a duty cycle of 25%, the following image is the data captured by the Arduino.

I could clean up the signal, either with some extra electronics, or via a software algorithm, but as I’m only interested in the amplitude of the signal (it will be larger then the inductor is over the wire) I don’t think I’ll bother …

… just as an aside the inductor goes absolutely mental when it’s near my induction hob!!! (as you’d expect)

testing the motor controller

So I’ve received the motor controller so thought I’d give it a quick (safe) test out of the mower. Basically I hooked it up to an Uno I had lying around to the motor controller (not the L298 shown in the picture, but that is all fritzing seems to have), hooked the motor controller up to a 5V supply (an Uno output) and them measured the output of the controller on one of the analog ports.


const int pwmPin = 5;
const int dirPin = 7;
int counter = 0;
int changeCounter = 0;

int currentSpeed = 0;
int targetSpeed = 0;

void setup() {
 pinMode(dirPin, OUTPUT);
 pinMode(pwmPin, OUTPUT);

digitalWrite(dirPin, HIGH);
 analogWrite(pwmPin, 0);


void setMotorSpeed(int target)
 if (currentSpeed < target)
 currentSpeed += 5;
 analogWrite(pwmPin, currentSpeed);
 else if (currentSpeed > target)
 currentSpeed -= 5;
 analogWrite(pwmPin, currentSpeed);

void loop() {


// Change the target speed every 100 loops
 if (changeCounter > 100)
 if (targetSpeed == 0)
 targetSpeed = 130;
 targetSpeed = 0;
 changeCounter = 0;

double a0value = 0;

// read the average value over 100ms -ish
 double loopTime = 100;
 for (int i = 0 ; i < loopTime ; i++)
 a0value += analogRead(A0) / loopTime;
 delay (1);

 if (counter > 2)
 Serial.print(a0value * 5 / 1023.0);
 Serial.print("v ");

 Serial.print(" ");
 counter = 0;

cutting motor investigation

With the top of the RL2000 off I put it into “service mode”, one of the service mode options is to test the cutting motors. The test puts all three motors on full speed for about 10 seconds (IIRC).

With the test running I placed a multi meter across the terminals and found that the full 25v was being applied to each of the motors, the surprising thing was the current usage. Considering they were under no load (there is no grass to cut in my garage) the 3 of them pulled a total of 3-4A,

Considering when mowing normally the total load is only 4-5A this represents a significant portion of the batter usage. The RL2000 does have a mode where the cutting motors are slowed down, with this in mind I’ve decided to use a motor controller to reduce the speed of the motors to increase mowing time.

mainboard design (rough sketch)

after a few issues regarding re-soldering of the prototype board I thought it best to actually design the thing rather that just rely on the thoughts bouncing round my mind … I think I’ve remembered everything.


nano #1 reads the voltages of the battery and the charger and measures the current, it uses these to control the charging relay which disable the link between the battery and the charging spikes (after all we don’t want to create a weaponised lawnmower that can electrocute small children who get too close). It also controls the cutting blade motors.

nano #2 reads the edge sensors and the front and rear bumper resistor ladders.

nano #3 primarily controls the drive motors, in addition it reads the data from the 9DOF sensor on it’s own I2C bus.

The pi zero w communicates with nano’s #1&2 via I2C (with the pi being the master which allows it to run the bus at 3.3v), however as nano #3 is using I2C to communicate (as the master) with the 9DOF device it will communicate with the pi via I2C

project restart

Well after a bit of a break it’s time to get back to it, I’ve decided to ditch the arduino mini’s and go for nano’s instead just to make it easier to reprogram them during development.

All the materials have now been purchased although I’m still waiting for the motor controllers to be delivered.

Time to start building…

battery management

in the years that i’ve had the RL2000 i’ve been through a couple of sets of batteries mainly due to issues with docking causing the batteries to completely discharge which isn’t good for them. so my first priority with the project is to ensure that I can monitor and control the battery usage/charging function.

the advantage of having a mostly functional existing system is that I can piggy back on the existing sensors and read what is currently going on.



bill of materials

my first consideration was the sensors/controllers that i would require

  • voltage/current sensors to detect battery status (charging controller etc)
  • sensors to detect the perimeter wire
  • 9 degrees of freedom sensor (9DOF) to track the motion
  • drive motor controller
  • blades motor controller
  • bumper sensors

my first thought was to use an Arduino Mega to control all of these, however the trouble with all Arduinos is that they are single core/single threaded devices, okay you can do pseudo threading but’s not really the same thing.

so i’ve decided to go with a pi as an I2C master and have a few Arduino Pro Mini (5v) devices each performing an individual task with overall control being performed by the pi. the obvious advantages to this is the processing power of the pi is a lot greater, persistent storage is easier, remote debugging is easier and i can use a high level language to perform the overall master control (probably java or C++ haven’t decided yet)