Meerkat Evo


Evoluzione delle specie


Seems there's another Evolution 2020, so don't get confused


I published the plans and instructions for the original Meerkat around 2 years ago, and in that time Meerkat has done a lot of teaching work, not to mention being built quite a few times from my instructions.


But over the last while he's been sitting there not doing much because of what I thought was a dead motor, and because my day job needs full attention.  But not that long ago, I got inspired to give Meerkat a proper update.

In automotive parlance, this new version is an update of the existing model rather than an all-new model.  So I've decided to call the update "Meerkat Evoluzione 2020"

Back in the workshop again...
So what is the feature list for the reborn 'Kat?  How is this for a start?

  • Cliff detection.  Stairs are the enemy of most robots, so we'd better find them before we call off.
  • Power monitoring.  So Meerkat knows how much power is available.
  • Location recording, if not autonomous navigation.  This might be a big ask for a Mega256, but let's give it a try.
  • Radio telemetry.  Just like a real rover.

Running Repairs

But first things first, there is the matter of that dead motor.  I propped Meerkat up on a stand and ran it with no obstructions, so all motors will go forwards.  No matter what command was given, the motor didn't rotate.  Then I looked closely at the motor controller:



Did you spot the problem?  D4 is not lit up like all the others.  It's unlikely this is a bad LED, so either the L293 is broken, there's a bad connection or the GPIO line is dead.

Unfortunately, when I was trying to measure, I managed to short the 9V rail from the batteries to the 5V rail and did lots of nasty damage to the controller, so that was the end of the test process (and the controller.  There are some SMD diodes I don't have the tools to replace and they seem to be blown now.

Even worse is the fact that this particular board is no longer carried, leaving me to replace it.  I have a few boards on hand (motor drivers get damaged around me), but nothing that will drive four discrete motors.

It's not the end of the world, because I've learned that while being able to control the speed of each of Meerkat's wheels independently is nice, there is little, if any practical value in doing so.  From now on, we will be controlling the motors on each side from a single channel.  This simplifies the code, and reduces the amount of wiring I need as well.

I happened to have a Deek-Robot clone of the Arduino Motor Shield R3.  I am not sure if the genuine item is still manufactured, but it's a very simple L298N board, and many companies are producing them.
Changing to the shield controller did simplify the wiring, because now only power and motor wires are required, but it did mean changes were required to the software configuration.  The drive process is also slightly different, since this controller implements a "brake" function.  Fortunately because the code is written as a series of layers, only the physical control definitions needed to be changed (and then, not by much).  We also lost two analog ports (used for power monitoring) because the shield exposes the L298's output current sense functions.  Just move A0 and A1 to A2 and A3 respectively.  No biggie as the Mega2560 has plenty of analogue inputs anyway.

It did however, mess up the SPI functions for the SSD1306 display panel  The most obvious solution is to use an I2C display, so that's the path we will take.

Don't fall down the stairs

Meerkat usually runs around indoors and my house has a few flights of stairs which, for a robot is pretty life-threatening.  As it turns out, cliff detection is not too difficult to achieve.  I am using a simple Infrared reflection detector.  Usually these point straight ahead, but in this case, the board is angled 45 degrees down and mounted it at the front, underneath the sonar assembly on the bottom deck.  These boards have a sensitivity pot, which I manually set so that the LED turns off when Meerkat gets close to the edge of a stair.

A cliff event will cause an immediate stop and a turn randomly to left or right.  Why choose the direction at random?  Simply because it makes it more interesting to see how the internal logic deals with the situation.

Where am I, and where am I going?

Here's where it's going to get really interesting...  GPS receivers are really cheap and pretty easy to use.  Recently I published an article on a logging GPS speedometer, and it used so little memory I started to wonder if I could put simple heading control into the unit.

Just to be clear, this is not full navigation, rather it is a way to maintain a heading in an effort to reach a waypoint as defined in the code.  The overall goal in code is to reach a set of coordinates, within a reasonable margin of error.

Meerkat knows from a GPS reading where he is, and also where he needs to be.  The math is complicated, but given these two pairs of X-Y coordinates we can determine the heading that needs to be taken.

This link gives a great example

Meerkat will attempt to get on heading (within 2 degrees) and then move off.  If the GPS-reported heading deviates from the calculated heading, Meerkat attempts to steer back onto course.

In this mode, each minute Meerkat gets it position and recalculates the heading.

So what if we encounter an obstacle?  It's simple really, the existing steering logic kicks in and once we are back on the straight path, the heading correction will start again.  This software is very much a work in progress, so keep an eye on the repo for updates.

Doing the dirty work

Note:  In the photos you will see that I replaced my original Arduino Mega2560 with a WiFi-enabled model.  This is not part of the upgrade as described here and was done because on removing the original, I found it had a damaged electrolytic capacitor (C2) so rather than risk failure, I replaced the board with what I had on hand.  We are not using WiFi in this example anyway.

The process is easy enough.  Firstly disconnect the motor driver and motors including the servo.  Remove the motor PCB.  Unplug the ultrasonic module and display (if installed), then remove the Arduino board.  Leave the servo and ultrasonics in place, but disconnected

To avoid having to rewire the motors, I moved to Arduino board so that it is approximately 1cm from the back of the chassis.  This requires drilling new holes for mounting.  When this is done, re-install the Arduino.

Using a 3V battery, identify the motors on the right side (looking from the front) and connect these to the "A" outputs.  Likewise, the left side are connected to "B" outputs.

Servo

The servo does not plug straight into the motor shield, because the pinouts are not compatible.  The connections are:

 Servo Pin
Plug Position
Wire Colour
Shield Pin
 SignalLeft
Orange or Yellow
D6
 V+Centre
Red
+5V
 GNDRight
Brown or Black
GND

Use three Male-to-Female jumper wires to make the connections.

Sonar

Sonar is connected directly to the Arduino with TRIG on 52 and ECHO on 53.

At this point, load the new software release (from the meerkat-evo repository) and Meerkat should work just like it did before.  An anticlimax maybe, but it's reassuring to know nothing broke.

In Conclusion

As with the evolution race cars, I have put together  a kit of parts to upgrade your existing Meerkat to full Evoluzione 2020 specification.  The kit contains:
  • Compatible dual motor control shield (brand may vary, but they are tested for compatibility)
  • Optical sensor for cliff detection
  • ACS712 current sensor
  • Voltage divider
  • GPS receiver
  • NRF24L01 transceiver (long-range configuration)
The upgrade kit does not include the Arduino or LCD display.  Unlike the race car, you don't send me back the old parts.  Use them in another project.

P.S.  To the nice people at Ferrari, this is all in good humour.  I am not for one moment comparing Meerkat to your products.


Comments

Popular posts from this blog

The QYT KT-7900D

Life with Deep Racer - Part 2

DIY Self-Driving - Part 9 - New Imaging