Mecanum Wheel Robot Issues

Hi Steve @codecage,

   OK, but I also suggested that you try swapping the pin that MR_BI2 is actually using.

Your code says:

#define MR_BI2 2

which I assume means MR_BI2 is using GPIO 2.

(Sorry, I haven't double checked whether '2' refers to a pin number or a GPIO number, but I am guessing it is the GPIO number. Should it be the pin number, then just make the appropriate adjustments to what I am suggesting.)

So, can you find a suitable spare GPIO pin that is equivalent (ie it will do everything you require GPIO 2 to do, which is probably just be an output that can be set high or low in software) ?

If so, if I use 'x' to represent the GPIO number you just found:

1. Move the wire connection from GPIO 2 to GPIO 'x'
2. Change the software line #define MR_BI2 'x' to #define MR_BI2 'x'

------

Then see if your problem goes away ... or at least changes in a significant way.

• If this changes the problem, then maybe there is something 'special' about GPIO 2, that is best avoided.
• If it doesn't change the problem, the enigma retains the upper hand...and the search continues...

Best wishes, Dave

@davee

OK Dave, I liked and tried your suggestion.  Moved the MR_BI2 from GPIO pin 2 to GPIO pin 15.  Just a one position move on the wiring coming off of the ESP32.  Close but no cigar!  Motor movement was identical, but the Blue LED was no longer lighting up.  On my ESP32 the onboard Blue LED must be linked to GPIO pin 2.  Will investigate that later.

Bad motor driver (TB6612FNG)?  So I swapped the position of the two motor drivers.  What was the front motor drive is now the rear motor and visa-versa.  Thought the problem might be on the Front Left motor.  Again no cigar!  Rear Left Motor still same issue.

I even swapped out and reprogramed another ESP32.  Same issues!

Now I'm really frustrated...  I then took the Rear Right motor which was connected to the AO1 and AO2 pins on the motor controller and moved them to the BO1 and BO2 pins.  And then connected the Rear Left motor to pins AO1 and AO2 pins. Want to guess the results?

The issue follows whatever motor is connected to BO1 and BO2 on whatever motor controller is the Rear motor controller!!!

It has to be a wiring issue on the Rear motor controller or a code problem!  Back to investigating!

Hi Steve @codecage,

  So the first test showed that the blue LED coming on was just a distraction, although avoiding GPIO 2 is probably a good idea. No cigar maybe, but worth at least a coffee?

 Sorry, but as I am not in the same room, watching and recording all of the swaps, etc., it is a bit difficult for me to 100% follow all of the variations you have tested, but I suspect you have identified the channel of the motor controller that was initially proving troublesome.

{ I am a bit confused by your paragraph "Bad motor driver (TB6612FNG)? .... ", as I am not completely clear whether of the software or ESP pins, or the motor controller, or the motors got moved. }

Is your interpretation that a channel of the TB6612 has gone bad? If so,read on..

The easiest (physically) would be to replace the TB6612 ... but obviously this is harder if you don't have a spare.

I have never seen a TB6612, but a quick look at the data sheet suggested it was a rather simple device, and that each motor driver half works a bit like a 3 input AND gate. Hence, by 'permanently' setting inputs to one row of the truth table, it should be possible to check all of the inputs and outputs with a meter, looking for a discrepancy.

ie looking at https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf

e.g. hence, with a spare copy of your code to 'hack' with, you should be able to set fixed pin levels and then use a meter (as well as your eyes on the motor) to check the levels coming out of the pins.

e.g. Delete the contents of the loop() function

  and add 3/4 lines into the bottom of the setup() to just control 1 motor to a fixed setting  (edit these lines and recompile for each different test)

e.g. the first test might be

• Ensure/setpin STBY HIGH (to make sure chip not in standby)
• SET PWM HIGH (100% power ..)
• Set IN1 LOW
• Set IN2 HIGH

Motor should be rotating counterclockwise (fast) and

• OUT1 should be LOW
• OUT2 should be HIGH

-----------

This way you can use your meter to check the inputs and outputs of the device.

If all is well, then edit the file so that IN1 is HIGH and IN2 is LOW, and check the motor spins the clockwise direction, with OUT1 HIGH  and OUT2 LOW.

----------

Probably a good idea to start with a practice run on the 'working motor channel' ... then repeat with the troublesome one.

If all of the inputs (logic and power, including ground) to the chip are correct, but one or more of the outputs are not then you have your suspect. Make sure disconnecting the output does not change the situation, in case your wiring has a short.

---------

Obviously,if any of the inputs are not what you expect, then you have a programming, or ESP GPIO output or wiring or TB6612 input problem ... again your meter and some judicious unplugging should identify the culprit.

--------

NB it is probably a bit tricky, but it is always best to confirm the voltage on the chip pin itself. It is not unusual for a bad connection, etc. to mean that a pin of the  chip is not seeing the same voltage as what should be the same wire at (say) the edge of the board.

---------------

Sorry the above is tedious to describe, and even worse to do, but it maybe the only way to determine the exact cause.

Good luck and best wishes, Dave

@codecage Slightly confusing, Steve. You said you moved the driver and the problem moved with the driver to the rear motor. So far that indicates a driver-related issue. You then swapped esp32 and the problem remained indicating the board itself is ok. You then swapped left and right motor connections and saw that the problem followed the driver pins, i.e. B01 and B02.

At that point, I would have swapped drivers to see if the same motor attached to B01 and B02 was still the problem. My hunch is it will not change which means the issue is between the driver and the esp32. It could be wiring, but more likely code. I would re-write the affected section of code from scratch in a new sketch then paste it over the old code in case there is a stray 'funny' char in there somewhere (remember the red issue?)

@zander and @davee

I'm on it like ducks on June bugs.  Will report back later!!

Thanks for your help.

@codecage

I perused the post chain and your remark on using the ledcWrite()" method instead of the "analogWrite()" caught my eye.  I've not done much in C / C++ for 2 or three years now so I see I'm getting rather out of date, and will have to do a refresher at some point in time.

But I did look at your code to see if the old brain box was still working but I did not see anything untoward in your code.  As mentioned by others and you are probably aware not all GPIO pins on ESP32 are always useable for all purposes, and it does not seem consistent with all varieties of ESP32's which can get a bit confusing.  

Looking at the C++ code does leave one a bit boggle eyed and I was reminded of a similar test program I did in python that created each motor as an object and I think that this sort of coding is where the use of object oriented programming and the use of classes comes to the fore.

So one class for a motor, but many instances of the motor class, one for each motor.  I was going to keep such thoughts to myself, but I vaguely remember you mentioned learning some python from the paul mcwhorter tutorials some time back when dear old Robo Pi was with us, so just in case its of interest I post the code which may tempt you to use C++ classes for this exercise of even do it all in python.  For my money python saves much eye boggling, but each to their own.

Its a very simple test example and the board I used was a rpi pico (the code is of course micropython not python).  The pico allows PWM on any GPIO pin and and the pin numbers will all be different to the esp32, but, of course one can put micropython on the esp32 if desired.   

I've not added much to helping you solve your problem, but it was a bit of fun for me to look out some of my old motor driver testing code as I had it in mind at some point in time to enhance it to cater for Mecanum wheels in the DriveBot class to enable a bot to be sent any which way.

from machine import Pin, PWM
from micropython import const
import time

HalfSpeed = const(32768) # duty_cycle 50% (65535/2)


# Define a class for a motor with a pin assignments for Forward, Backwards and PWM signals
# a defaul pwm frequency is also assigned, but this can be changed with a method call.

class Motor:
    def __init__(self,pin_1, pin_2, pin_pwm, pwm_freq):
        self.pin_1 = pin_1
        self.pin_2 = pin_2
        self.pin_pwm = pin_pwm
        self.pin_pwm.freq(pwm_freq)
        
    def change_freq(self, freq):
        self.pin_pwm.freq(freq)
    
    def forwards(self, speed):
        self.pin_1.value(1)
        self.pin_2.value(0)
        self.pin_pwm.duty_u16(speed)
        print(self, ' motor fowards')
        
    def backwards(self, speed):
        self.pin_1.value(0)
        self.pin_2.value(1)
        self.pin_pwm.duty_u16(speed)
        print(self, ' motor reversed') 
    
    def stop(self):
        self.pin_1.value(0)
        self.pin_2.value(0)
        self.pin_pwm.duty_u16(0)
        print(self, ' motor stopped')


# Define a class to hold a list of motor objects for a robot to drive all motors as
# defined in the various class methods
class DriveBot:
    def __init__(self,motor_list):
        self.motor_list = motor_list
        
    def all_forwards(self, speed):
        self.motor_list[0].forwards(speed)
        self.motor_list[1].forwards(speed)
        self.motor_list[2].forwards(speed)
        self.motor_list[3].forwards(speed)
        
    def all_stop(self):
        self.motor_list[0].stop()
        self.motor_list[1].stop()
        self.motor_list[2].stop()
        self.motor_list[3].stop()


# create motor objects from the Motor class and pass in the pin arguments and the initial pwm frequency
mFR = Motor(Pin(0), Pin(1), PWM(Pin(2)), 1000) # 1kHz
mFL = Motor(Pin(3), Pin(4), PWM(Pin(6)), 1000) # 1kHz
mRR = Motor(Pin(7), Pin(8), PWM(Pin(10)), 1000) # 1kHz
mRL = Motor(Pin(11), Pin(12), PWM(Pin(14)), 1000) # 1kHz

# put all the motor objects into list
motor_list = []
motor_list.append(mFR) # Front Right
motor_list.append(mFL) # Front Left
motor_list.append(mRR) # Rear Right
motor_list.append(mRL) # Rear Left

# Test run the motors in sequence
for m in motor_list:
    m.forwards(HalfSpeed) # duty_cycle 50% (65535/2)
    time.sleep(2)
    m.stop()

# create DriveBot instance
bot = DriveBot(motor_list)

# Test drive bot - all motors forward
bot.all_forwards(HalfSpeed)
time.sleep(2)
bot.all_stop()

@byron 

Thanks for your comments.  The objects and classes idea is great, but for this application which was some test code only, I'm going to leave as is.  And as you'll see in the following post, I've resolved the issue.  Maybe once I finish assembly of my robot car I might take the final code and work on implementing the objects and classes idea.

Again, thanks for your input, much appreciated.

@davee & @zander,

Well I sit here with egg on my face.  All is working as it should!  Even after all my double checking of wiring it seems I had a bad connection from the GPIO 13 pin of the ESP32 to the BI1 pin of the rear motor controller.  Replacing that wire with another resolved the issue.  I really believe the bad connections was in the solderless breadboard itself (thanks @dronebot-workshop!) as the wire seemed perfectly fine when tested with an ohm meter.

But the Blue LED issue still remains a minor mystery.  Guessing it is just GPIO 2 is tied to the Blue LED on the ESP32 I'm using.

@codecage I have had that problem a few times. Once I get my workshop moved, one of the first things I will do is check every breadboard I have for reliability. Those that are NOT reliable are in the bin.

Does anyone know of a brand etc, that is reliable?

Hi Steve @codecage,

  Good to hear your problem is finally sorted - congratulations on solving another mystery! 🍺 🍺 🍺 

(I didn't see a cigar emoji!)

----------

  I guess if you have a 'blink' program that actually drives the blue LED you could trace through the code to see which GPIO it thinks it is driving. If it is '2', then it is a 'feature' ... i.e. it is 'sort of' documented in the library code that makes 'blink' work, and will probably to most similar boards. If, by any chance, 'blink' uses a different GPIO port, then the mystery deepens.

------

Note, whilst avoiding GPIO 2 for anything other than flashing the LED is the easiest strategy, if you actually need to use GPIO 2 as well, then as a simple 'slow' logic output, it is probably fine to allow it to drive the LED as well.

It would get a bit more tricky if you tried using for other things, such as GPIO input, as the LED would be in parallel with the input, and may 'eat' some of the incoming signal. In that case, module surgery to remove the LED or its series resistor is probably the best course of action.

---------

  No need for you to feel any embarassment ... even with fully soldered PCBs, it is not unusual to find breaks in connections, including ones hiding under a respectable looking solder joints, as well as shorts between conductors ... and they can all be very difficult to track down.

Of course, solderless breadboards can be really handy for trying out ideas .. just be ready for them to play tricks on you! Having got a circuit to 'work', then a more permanent arrangement is advised, if it is part of a project.

--------

Solderless breadboards and the like are always prone to giving dodgy connections ... the tiniest bit of oxidation of the metal surface or a deformed spring means a poor or no connection that is impossible to see. That is why I mentioned measuring the voltage on the chip itself when checking to see if you had faulty motor driver chip.

Personally, whenever I get circuits that are playing games, I try to either use an oscilloscope to see the dynamic voltages, or make the circuit 'static', so I can trace round with a meter at my leisure, making sure the voltage is the same on all parts of the same 'conductor'.

------

Best wishes and good luck for the rest of your project,

Dave

Hi Ron @zander,

Our messages have once again been in parallel in the ether...

As for:

I will do is check every breadboard I have for reliability. Those that are NOT reliable are in the bin.

Does anyone know of a brand etc, that is reliable?

The cynical side of me says, obviously bin any breadboards that are showing signs of trauma or fail a basic test, but testing them for reliability maybe harder than finding the proverbial pin in a haystack. Similarly, I suspect that most are manufactured in obscure parts of China, with 'brand names' being of little value.

Personally, my few solderless breadboards have been 'forced' to accept wires and pins of varying sizes, and I accept that the holes and springs will sometimes get damaged, so I will need to replace them as required. However, even if I was 'more considerate' to the boards, the springs are usually low tension and have platings that will oxidise or corode, so I see them as 'short term only' use.

I suspect that in many cases, with the exception of particular holes/contacts that were badly manufactured or subsequently damaged, they are more likely to work when the wires have recently been inserted, as the insertion will wipe off some of the oxidation, but a circuit built some time ago may start to fail as fresh oxidation builds up.

Hence, whilst I think they can be very useful for quickly linking something together, I would always transfer a circuit I wanted to 'keep' to a soldered alternative.

Just my views and guesses .. not necessarily backed up with evidence.

Best wishes and hope your health is holding up, Dave

@davee I suspect you are more correct than not, but I doubt either of us has as much experience together as the sum of the members so asking the members for input is still possibly worthwhile. That is offset however by the extremely low participation rate, only a little more than a half dozen or so ever participate. This is something I really need to get some input on so I will post it in a few other forums as well.

Hi Ron @zander,

  If I make a contribution, it is obviously limited to my own experience, knowledge, etc., and I make no claims to infallability, etc. I hope anything I say is correct, but obviously welcome others contributing, including pointing out my mistakes, which inevitably will occur.

Sadly, as you say, contributions from more than a handful of people are comparatively rare.

Best wishes all, Dave

@zander 

I think Bill has mentioned he as had the best luck with solderless breadboards from Jameco Electronics, but you might ask him to verify.  I seem to remember that he has gone to them exclusively, but I could be wrong.  I have sure been wrong in the past a few times, that's for sure. 

@codecage Actually, that sounds familiar, and now that I have searched my Amazon history, I did

buy one of their big triple boards and 2 of the boards that allow you to put the esp32 with different pin spacing across the middle power rail. I have not noticed if they are better or not but will pay attention and do some testing when I get my shop set up again.