Hobby Components Maze Runner (HCROBO0052)

Hobby Component self build kits
andrew
Site Admin
Posts: 1143
Joined: Sun Aug 05, 2012 4:15 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by andrew » Fri Mar 05, 2021 1:42 pm

Definite progress! It is now attempting the calibration
That's great. I can go into more detail if you like but basically the weirdness was being caused by some code being optimised out by the compiler. I guess over the years since this library was written the IDE has been through several updates and something must have changed in the way it compiles the code. I've put a bit in the code to stop the optimiser messing with it so that shouldn't be an issue anymore.

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.

It sounds like for some reason the left motor is spinning faster than the right motor. I assume it wasn't doing this before you originally re-flashed it? I'm just trying to figure if it's hardware related or not.

With regards to the calibration process with it first rotating more than 180 degrees, which also sounds like a symptom of one motor rotating too fast, you can tweak how much it turns by changing a value in the HCMRunner.h file.

If you open that file up in a text editor (if using Windows don't use notepad, it's rubbish and get the formatting wrong, use something like notepad++) on line 55 you can set the amount of time it does each calibration turn for (LSCALROTATIONTIME). The default is 1200. Try lowering it a little to see if it improves the calibration process any.


Could you also give the sketch below a try. All it will do is stick both motors into full speed forward. Does it look like one motor is spinning faster than the other? I.e. does it veer off in one direction?

  1. #define RIGHT_MOTOR_A 3
  2. #define RIGHT_MOTOR_B 2
  3. #define LEFT_MOTOR_A 5
  4. #define LEFT_MOTOR_B 4
  5.  
  6. void setup()
  7. {
  8.   pinMode(LEFT_MOTOR_A, OUTPUT);
  9.   pinMode(LEFT_MOTOR_B, OUTPUT);
  10.   pinMode(RIGHT_MOTOR_A, OUTPUT);
  11.   pinMode(RIGHT_MOTOR_B, OUTPUT);
  12.  
  13.   digitalWrite(LEFT_MOTOR_A, HIGH);
  14.   digitalWrite(LEFT_MOTOR_B, LOW);
  15.   digitalWrite(RIGHT_MOTOR_A, HIGH);
  16.   digitalWrite(RIGHT_MOTOR_B, LOW);
  17. }
  18.  
  19. void loop()
  20. {
  21. }
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

DaveA
Posts: 16
Joined: Mon Apr 24, 2017 6:56 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by DaveA » Sun Mar 07, 2021 12:24 am

Could you also give the sketch below a try. All it will do is stick both motors into full speed forward. Does it look like one motor is spinning faster than the other? I.e. does it veer off in one direction?
I'll just cover this first. Using a hand-held 9v lithium battery pack now to remove battery doubts, the motors both run strongly (covers 2m in ~11 secs). It does veer off but to the Left. Not dramatically but enough to trace a circle of about 3 meters diameter. This might sound a lot but it's not really noticable over the 20 - 30cm sort of distances on the maze. I don't think I would have noticed this originally while it was navigating correctly. Interestingly, if I swap the wheels, the effect is much less (~20cm off line over 2m, still left) because the diameters of the wheels are 0.5mm different!! By putting a broad rubber band over the smaller wheel, it will now run exactly true. The voltage to both motors was identical.

I'd love to be able to say that this solved the problem but unfortunately it hasn't. In fact because it is rotating the same distance clockwise and anticlockwise to finish in the same place, any speed differences should cancel out.

I'll explain more fully what happens in the calibration routine. On a 9v power pack it actally rotates ~270 deg then back to the start and on to the same angle anti-clockwise then back to the start but it consistantly finishes about 15 degrees to the right of the line. I captured the calibration results on one run. It then moves along the line but the motors alternate, making continual left-right corrections (~2/sec) like it was bouncing off 2 walls. It manages some turns, gets others wrong but often loses the line and gets confused. All the time the motors are alternating quite slowly giving a zig-zag motion
.......line 55 you can set the amount of time it does each calibration turn for (LSCALROTATIONTIME). The default is 1200. Try lowering it a little to see if it improves the calibration process any.
I tried this (values 1000 and 750) and I could see the effect on the rotation angle but it did not change the behaviour.

I did a sketch to just rotate the robot one way and then the other for 3 secs each and it did finish at the start point within a degree or 2.

Looking like a sensor problem or some remaining problem in the calibration routine?

Cheers
You do not have the required permissions to view the files attached to this post.

andrew
Site Admin
Posts: 1143
Joined: Sun Aug 05, 2012 4:15 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by andrew » Sun Mar 07, 2021 9:14 am

Thanks again for the answers. That tells me it's unlikely to be a hardware issue as far as the motors are concerned. You're always going to get some slight speed difference with DC motors but it sounds like it's nothing as bad as when it's following the line.

I'm not going to rule out a hardware sensor problem but from your tests I don't see anything that suggests there's a problem with them. It could be a software sensor related problem though, as with the motors it could be something that's changed in the compiler at some point.

I'm going to have another look at the library to see if I can spot something and get back to you.
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

andrew
Site Admin
Posts: 1143
Joined: Sun Aug 05, 2012 4:15 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by andrew » Tue Mar 09, 2021 3:06 pm

Just had another chance to look at it and thought I'd confirm my suspicion that the current issue is still down to the optimiser removing code. So what I did was download an old version of the Arduino IDE that was available around the time the library was written (1.6.0) and just to be sure installed it on a clean computer, then compiled V0.2 of the library directly downloaded from this forum. Firstly the motor issue wasn't there and it does look like it's doing a better job of following the lines.

Would it be convenient to give that version (1.6.0) of the IDE a try? If so you can download it from here:

https://www.arduino.cc/en/Main/OldSoftw ... ases#1.6.x
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

DaveA
Posts: 16
Joined: Mon Apr 24, 2017 6:56 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by DaveA » Tue Mar 09, 2021 11:58 pm

I've tried this on another computer, as you say and I'm pleased to say it works!!!

It behaves exactly as I remember it. Sighs of relief all round. Thanks for staying with this. An excellent piece of detective work.

I know the kit has been on your range for a while now, but will we be seeing a V0.3 of the library to work with the latest Arduino IDE?

I'm surprised that Arduino allow this sort of thing to happen with their "upgrades".

Cheers

andrew
Site Admin
Posts: 1143
Joined: Sun Aug 05, 2012 4:15 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by andrew » Wed Mar 10, 2021 11:58 am

Great! Thanks again for trying this. That now confirms it's an optimiser issue and at least I know where to look without having to check every function.

Arduino does very occasionally make updates to the IDE that breaks older libraries but to be fair this looks like it's just something I should have tagged in the code so that it couldn't be optimised out. So it's likely it's an oversight on my part. The problem is that the optimiser looks at the code and removes anything I thinks is pointless however it doesn't know about interrupts when it does this. The library makes use of a timer interrupt that runs in the background controlling things like the motor speed and reading the sensors. When for example you change the speed of a motor you are writing a speed value to a variable and the timer interrupt in the background constantly reads this variable to determine what speed to set the motors too. So for instance you could change the speed of the MR by first setting the speed to 50% waiting a little, then setting it to 100%. The problem is the optimiser doesn't know about the timer interrupt is running in the background eading this variable and just sees is that you wrote a value to a variable twice but never did anything with it in between and so just removes the first write. Hence the weirdness you see.

I suspect the same thing is happening to another variable somewhere. Probably one that has something to do with the line sensors. I just need to find which one and prefix it with the keyword 'volatile'. That will tell the optimiser to leave anything that writes to it alone.

Interrupts are very usefuk things but they add a layer of obfuscation that can make bugs very hard to find.

I'll have another look at the library but again please bear with me because we are so busy what with the Covid situation that we have very little time at the moment to work in things like this. But I won't give up on a fix.

However as a temporary solution you may be able to download the portable (zip) version of the 1.6.0 IDE and have it run in parallel with you're current installed version. That will hopefully save you having to use a second computer to compile the code.
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

DaveA
Posts: 16
Joined: Mon Apr 24, 2017 6:56 pm

Re: Hobby Components Maze Runner (HCROBO0052)

Post by DaveA » Fri Mar 12, 2021 7:17 pm

Thanks for the technical explanation of how this has occured. I was going to ask about that. It's been an interesting saga and I've learned a lot.
I'm happy to leave it with you to look at in your own time.
I'm just pleased to know that my robot is not faulty and there's plenty I can try with it.

Cheers

Post Reply