Consistent Turns for mBot

#1

I’m working on a program that requires the mBot to make consistent turns in place. I’ve been fiddling around and it seems that to make this happen, I need to set one motor to a power setting that has a difference of at least 4 (plus or minus) because using the same power setting for both results in one motor not moving and the other making the mBot turn using the non-moving wheel as the center point of the turn. The code consists of a start block followed by two motor blocks (one for each motor) set to run the motors in opposite directions, a wait block set to 1 second, and then two additional motor blocks to stop the motors. The move block for turn left/right seems to follow the “steering” pattern of making the turn using the non-moving wheel as the center of the turn, so no luck there. I realize that the motors do not have encoders and therefore accurate turning may be difficult to achieve, but I’m open to trying other approaches.

Has anyone else experienced this issue and if so, what was your solution?

#2

Haven’t tried what you’re doing … but what motor speeds are you using? (If you’re not aware, the motors may not even start reliably at speeds below the 50-75 range).

Also, I would think that any changes you might being trying to observe with such small speed changes (i.e. <5 as you indicate) might be pretty inconsistent.

#3

Yes, I’ve noticed that at lower speeds the motors don’t start reliably. I’m using 100/-105 which seems to be the most consistent. Higher speeds have the issue of braking that increases the error of the turn. I’ve varied the difference in increments of 5 and noticed that when the difference exceeds about 20 that the inner wheel starts exhibiting the same behavior as if the difference were less than 4 (although it does seem to turn a bit). Still investigating though. Without encoders on the motors, I am having to find a balance between speed, time, and battery charge level (I’m using a 3.7V 2500mAh LiPoly battery for power).

#4

The Gyro might come in handy for that.
See this other post for a similar project

#5

Yup, my thought as I ordered a gyro module and a compass module today.

Great minds? :wink:

#6

Yes, I would also suggest to use a gyro module for hacing the bot run straight and make predictable turns, and a compass moddule to correct for the gyro drift and receive geographical orientation.

May be we should set up a new thread or even topic where we could discuss and share code specifically for gyro and compass modules.

@Pioneer, how about settig up a separate forum category dedicated for discussion and code-sharing, with topics for the different sensors?

#7

As I wait for my gyro/compass modules to arrive, I’ve been playing around with other ideas to try to control turns. One of the ideas was to use lines and the line following module to make movement stop. The program I’m using looks like:

You will notice that the “stop” block causes the motors to stop and then to back up a little bit to compensate for the overrun that occurs during the turn. The overrun is caused by the time it takes for the line following sensor to detect the line and the time it takes for the motors to stop when the line is detected. Obviously a stepper motor would be more accurate, but this approach seems to give reasonable, if not completely accurate turn control. I’ll concede that it’s a somewhat inelegant approach to the problem, but what the heck, it’s Sunday and I’m experimenting. :grin:

Thoughts anyone?

#8

I’d second that idea. It might be good to have subcategories dedicated to sensors, movement, etc. in the forum as well. It would help to promote the mBot and other products.

#9

@srothe, thanks for your suggestion, we would take your advice into consideration, thanks again.

#10

The experiment is awesome. We could easily spend a fotune getting better more accurate parts but working with the mBot is cool since it has the basics and you can do a LOT with this and some clever programming.

Don’t you get 3 states with the line follower? Are you just looking at one?

The delay in response comes mostly from the code not running on the robot and instead it is running on the PC and sending commands and receiving sensor info via the serial connection. I have found that there is a very significant lag which actually makes your coding more complicated due to the possibility of missed events such as button presses or things that last briefly.

#11

The class I’m teaching in February will only have the basic mBot to keep the costs down for the kids (they take the robot home at the end of the class), which is why I’m trying to avoid requiring additional purchases for the class. I’ll be pointing out other Makeblock products that would make some of the programming in mBlock easier as we go.

Right now I’m writing a short “book” to support the class which I’ll self-publish afterwards (I want to see how the materials work in class first) and then I’ll be moving on to create additional tutorials, etc. in mBlock and Arduino as part of the ongoing classes I’ll be teaching. I’ll be publishing those as well.

With regard to the line follower, I can get three states, but for my purposes I was only testing to see if both line following sensors are over the line. I hadn’t thought about the serial delay, but you’re likely spot on with that and it explains some of the other behavior I’ve seen with sensor readings.

#12

I’m doing more or less the same thing you are. I have my basic curricula outlined and the class will include an mBot in its basic form. I’d love to collaborate on observations from actual class activities since there will be a bit of trial and error.

#13

Happy to do so. My grandfather (who was a devastatingly well-educated and generally smart guy) told me that no one individual has all of the good ideas. :slight_smile:

#14

More on consistent turning. Well, after running a further series of tests tethered via wifi, I’ve come to the unfortunate conclusion that the time lag over the air just does not allow the kind of accuracy that is needed to solve a maze (or maybe I’m just tired of looking at the problem in Scratch right now). I may come back to this in the future if there is a version of mBlock that supports full code generation, but it’s time to move on and get things done before the holiday.

#15

how would you make a 90 degree left turn?

#16

I am programming my mBot to do a route. and I am in a programmers block. hehe, I don’t know how to make my robot to make a 90 degree left turn. I also don’t really know where to start.

#17

Hi bloopy,

Here is a mBlock program material for mBot to you for reference.
You may refer to the Move in a Square material part to write your program.

#18

One of the issues with time-based turning (a kind of dead reckoning) is that as the batteries run down the turns become less accurate. This compounds the issue associated with non-encoded motors (i.e., the ones that come with the mBot). What I ended up doing with the maze was using the line following sensor to detect a line when the mBot turned. Short of using some sort of motor encoders, the turns will always have a small “slop” factor that will need to be compensated for.

#19