Hobby Components Maze Runner (HCROBO0052)

[andrew]

Ok, thanks. I'll take a another look at the code while you do that. Nothing jumped out at me when I looked at it before but I'll take another look with the fact that it is stepping though the calibration process at the correct rate in mind.

[DaveA]

I've been looking at the workings of the CalibrateLineSensors() routine in the library (line 620 on in the .cpp file). The actual motor control parts are straightforward enough so I've copied them to see if they would run in a simple sketch as per the library call, ie rotate one way then the other.
I've attached the .ino file
I've done the 2 routines, one for clockwise, one for anti-clockwise, looped with a few delay's so I can follow what's happening. I note that the initial "Motor 0" commands in the first clockwise run are commented out in the library. I've tried this with and without them.

As it stands, it should alternate between clockwise and anti-clockwise but in practice it just does the 2nd part, the anti-clockwise. If I comment out the 2nd part then it does do the 1st part (clockwise).
If I actually swap the 2 routines, it is still only the 2nd one (now the clockwise one) that runs.

If I comment out the very first HCMRunner.MotorSpeed(LEFTMOTOR, 0); function, the right motor behaves as before but the left motor now does as it should and rotates in both directions.
If I comment out the right motor function instead then the opposite occures.

So, the obvious thing to do is comment out them both (how it is written in the library) then it will all work, right?

What happens is that it just runs the 2nd part again but it now seems to do a reset on each loop (plays the turn tune in void setup()).

I'm not sure what this is telling us. The motors do work and follow commands after a fashion. I've tried lots of these little sketches and I can't make sense of how a lot of them behave and some do cause this resetting loop. This can happen if I stall the motors briefly, but they are free running in normal use.

Cheers

[andrew]

I was just going to post you a test sketch to try this morning that ran the motors in a particular direction just before running the calibration routine but after seeing your post I gave your sketch a quick try and I'm seeing the same weird behaviour.

What's even more weird is if I add some serial print statements to track what part of the sketch is currently running it all starts to behave itself. Even stranger is you can make the clockwise routine work by adding print statements after is which is bizarre. Behaviour like this is usually an indication of an uninitialised variable or array overrun.

I've not go much time to look at it today but to find this bug I'm going to have to strip apart the library and isolate each part so this may take a little time.

. I've tried lots of these little sketches and I can't make sense of how a lot of them behave and some do cause this resetting loop. This can happen if I stall the motors briefly, but they are free running in normal use.

If it's resetting it's most likely the motors causing a brownout from drawing too much current. This should only happen though if you do something like stalling the motors or the battery is getting weak.

[DaveA]

Thank you for your continued interest and perseverence with this.

So that I'm not misleading you, just a quick update on my observations in my last post after your comment:

If it's resetting it's most likely the motors causing a brownout from drawing too much current. This should only happen though if you do something like stalling the motors or the battery is getting weak.

I think my resets were due to brownout from a low battery as you suggest. The 5v line was dipping to ~4.7v when the motors were starting but the battery was still showing ~8.2v off load. I do keep an eye on battery voltage as they run down fairly quickly.

I've checked the rest and it all still holds true, as you have seen yourself. On a new battery (I'm thinking of buying shares in Duracel), with the first 2 lines commented out, it does indeed rotate in both directions but interestingly it still starts with the second routine (anti-clockwise) first and then it behaves "normally" as it loops.

If I might ask, since my sketch is running oddly on your robot as well as mine and you are looking for bugs in the library, does the demo Maze Solver sketch still work normally on your robot? In particular using the exact same example sketch and library that I am using, downloaded from the forum?

Cheers

[andrew]

If I might ask, since my sketch is running oddly on your robot as well as mine and you are looking for bugs in the library, does the demo Maze Solver sketch still work normally on your robot? In particular using the exact same example sketch and library that I am using, downloaded from the forum?

Yeah defiantly works fine with our MR. I actually downloaded the one off the forum to make sure but tbh there has only ever been one update to the library and that was to fix a bug in the maze solving routine. There's been no updates or reported issues sine then. If you want to be sure the correct version is V0.2 (17/02/16).

At the moment I'm concentrating on your test sketch because it's simple and I can replicate the issue with it. As I mentioned before I can make it work simply by adding a print statement so that's what I'm focusing on in particular. Interestingly the serial Tx pin just happens to be adjacent to the pin used to drive the right motor in reverse. They also share the same digital port so I need to take a look at that to make sure one isn't messing with the other. It could just be a red herring though.

But because it's not obvious what could be causing it I've been stripping down the library to the bare minimum. Unfortunately this took me a bit longer then expected and I've run out time to work on it today so again please bear with me.

[DaveA]

I am unable to find anything wrong with the electronics on my robot but I'm far from being an expert in either this or the software. I will await the outcome of your investigations before trying to do much more.

However, regarding your comments on the library:

......there has only ever been one update to the library and that was to fix a bug in the maze solving routine. There's been no updates or reported issues sine then. If you want to be sure the correct version is V0.2 (17/02/16).

In fact the current download from your forum seems to be V0.1 (copy attached) The version stated at the beginning of each file is:

08/01/16 version 0.1: Original version. The date stamp of the library files is 12/01/16.

I can't find any option to download V0.2 so I think perhaps this needs to be looked into.

Cheers

[andrew]

In fact the current download from your forum seems to be V0.1 (copy attached) The version stated at the beginning of each file is:

Sorry I'm an idiot! I did downloaded the library but made the rookie mistake of forgetting to delete the existing library from the the library folder. I've now uploaded V0.2 to the forum. You can give it a try if you like but I don't expect it to make a difference as I've been seeing the issue with V0.2.

I only had a bit to time to look at it today but I did find a clue that suggests the problem is something to do with the interrupt timer which is used to generate the PWM for the motors. Assuming nothing gets in the way I'll have some time to spend on it tomorrow morning so I'll update you tomorrow.

[DaveA]

I've tried the V0.2 library and it made no difference. I didn't think it would either from what you had said but at least it's another possibility eliminated.

I'll leave you to look into it in your own time. No hurry.

[andrew]

I've attached a copy of the HCMRunner.cpp file to this post. Can you replace the one in your libraries/HCMRunner folder with this version and see if it works....

HCMRunner.cpp

[DaveA]

Definite progress! It is now attempting the calibration

The robot rotates clockwise slightly more than 180 deg and then anti-clockwise by slightly less (from straight ahead) but no third rotation. It then sets off along the line in a zig-zaggy manner (with a bias to the right). This is on a "T" pattern. It found the first left and turned 180 but missed the straight on and turned right coming back

Overall it's very slow and hesitant (on a good battery) and keeps loosing the line.