Line follower and Logic gates simplification

[Nexo]

Hello everyone!

I'm making a line follower (L.F), me and my team are on the first year of Electronics Engineering and decided to do a good L.F, a bit complex in order to learn a lot. We decided to use 4 sensors and 2 Stepper motors in order to have precision. The requirements are:

- Go forward.
- Stop.
- Turn left (45°, 90° and even a "round turn").
- Turn right (45°, 90° and even a "round turn").

This is the possible shape of the L.F:

http://prntscr.com/cbgz1t

1, 2, 3 and 4 are the sensors.

So we made a True table:

(Is in Spanish but the names are almost identical in English)

http://prntscr.com/cbh7iu

Then we got the functions for the motor one and two:

http://prntscr.com/cbgzj4

Then we used K-maps to simplify it (it could have also been optimized using De Morgan's laws)

http://prntscr.com/cbh07s

This is the resultant circuit:

http://prntscr.com/cbh0mx

As you can see, it is not too optimized because we would have to use:

- 4 INVERTERS = 1 IC
- 7 AND = 2 IC
 - 2 OR = 1 IC

TOTAL = 4 IC

So we tried to get rid of the OR gates using De Morgan's Laws as follows:

http://prntscr.com/cbh4yx

And the "final" logic circuit would be:

http://prntscr.com/cbhdpu

And we need:

- 9 NAND = 3 IC
- 4 AND = 1 IC

TOTAL = 4 IC

Is the same quantity of Integrated Circuits but quite less chaotic IMO, but still, I would like to use at least 1 less NAND gate in order to use only 2 NAND IC and have a total of 3 IC but I'm not able to do it and that's why I'm writing, can anyone give feedback about this idea? I would really appreciate.
Iy ou would change something, or add something, it will all be welcome.

Thanks in advance!

EDIT 1:

"Final" circuit has been updated with a better image.

[MK14]

Here is a link that might help.

https://www.cs.york.ac.uk/micromouse/Papers/Robot_project_jaseung_.pdf

Stepper motors, only move in very small "steps", they are NOT on/off devices, like normal DC motors can be. E.g. A stepper motor may move exactly a 1/200th of a full 360 degree circle. I.e. 1.8 degrees per "pulse".
The movement pulses are described here:
https://www.sparkfun.com/tutorials/400

and here:

http://www.nxp.com/files/microcontrollers/doc/app_note/AN2974.pdf

[Nexo]

Thanks for your reply and is true, I forgot to mention that this our project has 3 Modules:

Module 1: ADC - To convert the analog info to a digital pulse (I think digital and pulse in the same sentence is kind of redundant, I apologize if it is).
Module 2: Logic Circuit (This circuit) - To have an autonomous L.F.
Module 3: Control - Will use PWM (Timer 555) to generate the pulses to control the Stepper motor. The main reason my friend chose it was because  of the torque, he says this motors have better torque than a DC motor (Personally, I would rather use a DC one) without needing to much power to work and the second reason he gave us is that when the L.F detects that it has to turn, it would be easier to stop if using a Stepper Motor because the DC motor would keep rotating because of Inertia. I would love to read your comments on this.

[MK14]

Thanks for your reply and is true, I forgot to mention that this our project has 3 Modules:

Module 1: ADC - To convert the analog info to a digital pulse (I think digital and pulse in the same sentence is kind of redundant, I apologize if it is).
Module 2: Logic Circuit (This circuit) - To have an autonomous L.F.
Module 3: Control - Will use PWM (Timer 555) to generate the pulses to control the Stepper motor. The main reason my friend chose it was because  of the torque, he says this motors have better torque than a DC motor (Personally, I would rather use a DC one) without needing to much power to work and the second reason he gave us is that when the L.F detects that it has to turn, it would be easier to stop if using a Stepper Motor because the DC motor would keep rotating because of Inertia. I would love to read your comments on this.

What you are saying about the stepper motors, is basically correct.

But stepper motors, are usually used with microcontrollers, which can then calculate the exact pulse signals to send to the stepper motors.

Don't forget that DC motors, can be used with gearing and/or gear boxes (you can buy them ready assembled, as single units, from many electronic suppliers, at quite low prices, for many of them). If you need more torque, with some loss of max RPM.

What you seem to be missing, is any kind of RATE of correction. Which a purely analog or microcontroller solution would have given you. Without it, you may find that the robot is too unstable (but it MIGHT work).

What you seem to be showing is something which is either on or off, with no in-betweens. I suspect that would not work very well, as it could easily be unstable, and have other problems.

But it is possible that line-following is simple enough for you to get away with such simplicity.

Would a VERY slow progress, and wobbly solution, meet your needs ?
Or would you prefer something which works as well as possible, e.g. Quickest ?

EDIT:
Is the track layout, likely to be simple and straight forward ?
Or are they going to give it various, very tight turns, and twists and things, to try and catch the robot(s) out ?

EDIT2:
On reflection, I might be, being overly critical. It is possible that the problem is simple enough, and if you don't need particularly spectacular results. A simple solution, may work for it. I'm NOT 100% sure, either way.

I think if it is TOO unstable, it will lose track of the line, completely. So if it is TOO simple, it probably won't work.

Also there is probably noise/errors on some of the signals, some of the time (e.g. Due to vibrations and unevenness in the surfaces). A purely digital solution, may not cope with that, which could then end up losing control.
E.g. A Microcontroller, would have much more capability, to solve any issues and short comings in your control strategy.

[Ian.M]

Leaving aside the advisability or not of implementing a line follower in 'bang-bang' logic, to implement the logic functions you posted:
M1 = A' B' C D + A' B C' D' + A' B C' D;
M2 = A' B' C D + A B' C' D' + A B' C D';
only needs three 74 series logic ICs done with classic gates.

74xx04 Hex Inverter         
74xx02 Quad 2-Input NOR
74xx11 Triple 3-Input AND

However the logic diagram that implements it is a spaghetti mess. 

(All Logic wrangling done with Logic Friday
To get it down to 3 chips, I had to constrain its Map to Gates solver to only use inverters, 2 input NORs, and 2 & 3 input ANDs, then manually swap out two 2 input ANDs - one for a three input one and the other by DeMorgan using a NOR and inverters. .lfcn file attached)

IMHO if you need to do this in 74 series logic, use two 3 to 8 line decoders to fully decode the four input bits to 16 outputs representing all the possible 4 input AND terms then OR together the individual AND terms you need.   That way its *MUCH* easier to patch if you need to change the logic.

You could use a 74xx238 decoder with active high outputs and a 74xx32 quad OR, cascading two gates to get a 3 input OR, but it would probably be better to apply DeMorgan and use the more common 74xx138 decoder with active low outputs and a 74xx10 triple three input NAND to 'OR' the terms together.  That leaves you with a spare gate that can be used to implement another function of up to three terms.

[MK14]

Having a quick second glance on your truth table, I can see possible problems with it (ignoring that I'm not sure that it is the best, way, anyway).

It only seems to define the 6 logic states, you THINK, will always happen. In practice, it may well see, various versions of the SIXTEEN possible logic states, of the four sensor inputs.

Ideally you need to control/define those other ten, unintended logic states, as regards what they will do. Otherwise, you may have problems.

E.g. It could keep the last valid known "legal" state, until the next set of "correct" logic states are received.

As it is, the other ten states, will produce undefined behavior, which is not so good. E.g. It may result in it moving in completely the wrong direction (because of a slight bump in the track, causing a blip on the sensors), which may make it completely lose sight of the line it is suppose to be following and/or worsen the quality of the control.

As it stands you are relying on 100% perfect sensors (and track, which may have slight creases, distortions and dirt etc on it), all of the time. Room lighting, may also affect your sensors. E.g. There may be too much sunlight reflected onto parts of the track, invalidating your truth table, and causing your thing to go out of control.

EDIT:
E.g. One solution, would be that for all the 10 unexpected sensor states, could be made to just keep both motors on (1, 1), which is perhaps the safest short term solution, to invalid (hopefully temporary), sensor issues.
One way of doing that, would be to use a 74HC154 (4 to 16 way decoder), then going from there with diode steering logic and/or further logic gates. Similar to what another poster has been saying.
But I still don't think that it is perhaps the best way of doing this.

[Nexo]

But stepper motors, are usually used with microcontrollers, which can then calculate the exact pulse signals to send to the stepper motors.

Exactly, buy we don't want to mess around with microcontrollers just yet because, as I've mentioned before, we are in our first semester and we would love to do it this way because it is teaching us a lot. The pulses we'll generate with those 2 timers 555 can, as for sure you already know, vary base on the Duty cycle (which is also mentioned in the pdf you sent me (https://www.cs.york.ac.uk/micromouse/Papers/Robot_project_jaseung_.pdf - Page 3).
We can play around with the resistors values to do that. If I'm wrong, please do correct me.

Don't forget that DC motors, can be used with gearing and/or gear boxes (you can buy them ready assembled, as single units, from many electronic suppliers, at quite low prices, for many of them). If you need more torque, with some loss of max RPM.

True, if we don't find a suitable Stepper motor and decided to use a DC one, we might have to come back to this and figure things out.

What you seem to be missing, is any kind of RATE of correction. Which a purely analog or microcontroller solution would have given you. Without it, you may find that the robot is too unstable (but it MIGHT work).

Completely true, that is one of my main concerns right now, but we just started or semester 3 weeks ago and we are learning little by little, for now we are aiming to the best-case scenario, of course it will have problems and we'll have to solve every and each one of them to make it better. We have 3 more months to build something great.
Now, i'm intrigued by the "purely analog or microcontroller solution" could you give me some examples on this? It's beyond my current knowledge and now I have to study about this in order to try to implement it in our L.F. This is the idea, to have feedback and improve every single time. 

What you seem to be showing is something which is either on or off, with no in-betweens. I suspect that would not work very well, as it could easily be unstable, and have other problems.

Having a quick second glance on your truth table, I can see possible problems with it (ignoring that I'm not sure that it is the best, way, anyway).

It only seems to define the 6 logic states, you THINK, will always happen. In practice, it may well see, various versions of the SIXTEEN possible logic states, of the four sensor inputs.

Ideally you need to control/define those other ten, unintended logic states, as regards what they will do. Otherwise, you may have problems.

E.g. It could keep the last valid known "legal" state, until the next set of "correct" logic states are received.

As it is, the other ten states, will produce undefined behavior, which is not so good. E.g. It may result in it moving in completely the wrong direction (because of a slight bump in the track, causing a blip on the sensors), which may make it completely lose sight of the line it is suppose to be following and/or worsen the quality of the control.

As it stands you are relying on 100% perfect sensors (and track, which may have slight creases, distortions and dirt etc on it), all of the time. Room lighting, may also affect your sensors. E.g. There may be too much sunlight reflected onto parts of the track, invalidating your truth table, and causing your thing to go out of control.

True, we just did 6 in order to explain the other team-members what we are doing, we are 5 and only 2 of us have an idea about this and the others don't. But I will do the other states for sure because that will decrease the instability of the LF because will know what to do  in every possible scenario.

Would a VERY slow progress, and wobbly solution, meet your needs ?
Or would you prefer something which works as well as possible, e.g. Quickest ?

I think we are aiming to a reliable solution, we don't need something fast, although we've thought about controlling the velocity in turns and thinks like that but that might come later, that's the reason why we are doing a Modular project, in order to update each module as we want while we keep learning.

EDIT:
Is the track layout, likely to be simple and straight forward ?
Or are they going to give it various, very tight turns, and twists and things, to try and catch the robot(s) out ?

The teacher told us that the max angle we'll have to deal with is 45° but we are targeting a 90° angle turn and we asked him to let us make or own track layout which is as follows:

http://prntscr.com/cbj33l

EDIT2:
On reflection, I might be, being overly critical.

Please keep doing it, that's what we need and we thank you for that because you are giving positive feedback and that helps us to improve. Again, thank you very much!

It is possible that the problem is simple enough, and if you don't need particularly spectacular results. A simple solution, may work for it. I'm NOT 100% sure, either way.

In fact it is, as I said, we only must deal with a 45° angle turn but we want more and better because is the best way to learn.

I think if it is TOO unstable, it will lose track of the line, completely. So if it is TOO simple, it probably won't work.

True that. That's why I have to define all the 16 logic gates, that will provide more reliability.

Also there is probably noise/errors on some of the signals, some of the time (e.g. Due to vibrations and unevenness in the surfaces). A purely digital solution, may not cope with that, which could then end up losing control.

Another yet really interesting point. What would you recommend in order to deal with this possible problem?

E.g. A Microcontroller, would have much more capability, to solve any issues and short comings in your control strategy.

As far as I know, and I apologize for my ignorance, a Microcontroller uses programs based on C (or other language) to do what we are trying to achieve with logic gates. Can you give us more insights on this subject?

Again, we really appreciate your time and kindness!

Leaving aside the advisability or not of implementing a line follower in 'bang-bang' logic, to implement the logic functions you posted:
M1 = A' B' C D + A' B C' D' + A' B C' D;
M2 = A' B' C D + A B' C' D' + A B' C D';
only needs three 74 series logic ICs done with classic gates.

74xx04 Hex Inverter         
74xx02 Quad 2-Input NOR
74xx11 Triple 3-Input AND

Thanks for your reply!
I haven't thought about that 3-input AND which could eventually be used in our circuit, I'll read more about it and see if we have those IC in our city.

However the logic diagram that implements it is a spaghetti mess. 

Indeed, it is. But we'll try to deal with it

(All Logic wrangling done with Logic Friday
To get it down to 3 chips, I had to constrain its Map to Gates solver to only use inverters, 2 input NORs, and 2 & 3 input ANDs, then manually swap out two 2 input ANDs - one for a three input one and the other by DeMorgan using a NOR and inverters. .lfcn file attached)

Here begins my confusion, what does "to constrain its Map to Gates solver" mean?

IMHO if you need to do this in 74 series logic, use two 3 to 8 line decoders to fully decode the four input bits to 16 outputs representing all the possible 4 input AND terms then OR together the individual AND terms you need.   That way its *MUCH* easier to patch if you need to change the logic.

  No idea about what a "3 to 8 line decoder" is, I'll have to read about it, any recommended sites? Or could you explain a bit more the theory or why would I need to "decode the four input bits to 16 outputs"? What do those 16 outputs mean? IS it the 16 logic states? OR Am I use mising things up? 

You could use a 74xx238 decoder with active high outputs and a 74xx32 quad OR, cascading two gates to get a 3 input OR, but it would probably be better to apply DeMorgan and use the more common 74xx138 decoder with active low outputs and a 74xx10 triple three input NAND to 'OR' the terms together.  That leaves you with a spare gate that can be used to implement another function of up to three terms.

I'll come back to this once I've understood the previous part.

Again, thank you so much to both of you.
God bless you!

[MK14]

You have a lot of points, so I will just cover a few of them, initially.

You want to (at least initially), have a fairly simple, functionality, such as:



You probably simply CAN'T have sudden 90 degree, instant turns like you have in your suggested layout. The robot would (because of its speed), simply shoot past the 90 degree turn, and end up heading away from the line. Or would need an extremely clever and complicated robot, in order to handle it. Which would probably exceed your existing teams skill levels.

See example line following rules (which aid knowing how to design layouts properly), such as:

https://www.bcu.ac.uk/cmsproxyimage?path=/_media/docs/line%20follower%20rules.pdf

Take note of the LACK of SUDDEN turns:



Why did I mention, Microcontrollers ?
These things (Robots), can become VERY sophisticated and complicated:



Going massively beyond, what you can achieve with a few logic gates. Sorry!

But there can be simplistic ways of doing it.

Enjoy:

[Ian.M]

Here begins my confusion, what does "to constrain its Map to Gates solver" mean?

   
When you select 'Map to Gates' from the Logic Friday menu, it pops up a dialog that lets you select which types of simple logic gates of up to four inputs to use.   Assuming you've got a Windows PC, grab a copy and experiment.  Its fairly simple to use.

A 3 to 8 line decoder takes a 3 bit binary number and uses it to select one of its 8 outputs to activate.   As the decoders I mentioned have both active high and active low enable inputs you can use two of then to perform a 4 to 16 line decoding function, by connecting the  4th bit to EN on one and /EN on the other.

Here's the NXP 74HC138 and 74HC238 datasheets.

You have four variables (the sensor outputs after they have been processed to a single bit digital value), and if you feed them into a pair of 3 to 8 line decoders wired as a 4 to 16 line decoder, each output represents one row in the truth table or one combination of ANDing the four variables or their compliments.  It therefore makes it absolutely simple to implement an arbitrary four variable combinational logic function from its truth table.   

If you used Schottky diodes to OR the selected terms together you could make different logic functions as plug-in modules so you could easily 'reprogram' your robot by changing a single 18 pin DIL header carrying the diodes required for the desired terms.  Obviously it would need a pullup/pulldown resistor for the two output pins from the diodes, and preferably a buffer after that.

This approach to combinational  logic using a decoder rapidly becomes impractical for more than 4 variables.  Its single chip equivalent is to use some type of parallel ROM programmed with the desired truth table in binary, which as you can get 1Mx8bit EEPROMs, allows you up to eight combinational functions of 20 variables in a single 32 pin chip!

I would second the advice to use a microcontroller - UNLESS its a course aim to perform the task only with logic, in which case you are probably going to have to get very clever and build something fairly complex that does stuff like representing the sensor value as a PWM so you can process analog readings digitally without having to have either lots of parallel bits or clocked serial datastreams.   I doubt it can be done with simple combinatorial logic for anything except a smoothly curving line, as any sharp angles need knowledge of the previous state to distinguish between a gross tracking error where both sensors have lost the line and the process of continuing to turn to the side the line went to till its reacquired after driving forward to center over the point of the angle.

[MK14]

Here is an example of a really simple one (line follower):

http://playwithrobots.com/simple-line-follower-robot/









You really have two sensible choices, but I fear that you will choose neither, and it may not work out as planned.

(1)...Go really simple, and stick with simple. Seriously consider ditching pure digital, and have it much more analogue, if it helps. See how others have solved this problem.

(2)...Go with a Microcontroller. It allows a simple, initial solution. With the capabilities, to continually refine and add functionality, to quickly improve it as necessary.

Attempting a complicated digital gate logic solution, worries me, as it would be much harder to change, and would have all sorts of technical limitations and issues. Digital logic is mainly 0's and 1's, but you really need more complexity to the signals (which Microcontrollers easily can do), and need to make much more complicated decisions, than seeing if something is either 0 or 1.
Great things can be done, purely digitally. But it can take immense skill, experience and education (possibly self taught), to achieve things like that.
Otherwise, FPGA's would be considered really simple.

If you really MUST have a complicated digital logic design. Perhaps consider a different type of project, better suited to a pure digital logic solution. Such as a frequency counter or digital stepper motor controller (possibly with Microstepping) or something.

[rstofer]

For flexibility, you can use a 16-1 MUX for each motor.  You can implement any function of 4 variables with such a MUX.  You would need two, of course and they would be 24 pin devices.  Run all 4 sensor signals to the select lines and patch the 16 inputs to be whatever your output should be.

http://www.ti.com/lit/ds/symlink/mm54c150.pdf

There are many such multiplexers, I just grabbed to first datasheet that popped up on Google.

[Ian.M]

Unfortunately the 74150 never became popular in CMOS so you'll have a lot of difficulty finding it in anything other than original bipolar TTL.  Its also a honking big 24 pin 0.6" wide DIP package.  Fortunately you can use the readily available 74HC4067 ANALOG 16:1 Mux for the same function, provided you add a pull-up resistor to its output.   Two of those and four octal DIP switches to pull selected inputs low would let you implement two arbitrary combinatorial four variable logic functions, and reprogram them simply by flicking switches.  They do have an /EN  pin so with an extra inverter, you can cascade two of them to hadle five variables, simply paralleling the outputs, but this rapidly becomes impractical for larger numbers of variables.

[Nexo]

First of all, I really want to thank you for replying and sorry that it took me too long to reply back, college is quite harsh these days.

You probably simply CAN'T have sudden 90 degree, instant turns like you have in your suggested layout. The robot would (because of its speed), simply shoot past the 90 degree turn, and end up heading away from the line. Or would need an extremely clever and complicated robot, in order to handle it. Which would probably exceed your existing teams skill levels.

You're completely right, we made that layout without thinking about it. In our defense, we were just excited

I have question, why must a layout have corner markers? I've watched a few videos and I think those are use to produce a sound which I don't see more use, although I'm sure I'm making a mistake by assuming that. Hope you can clarify that for me.

Going massively beyond, what you can achieve with a few logic gates. Sorry!

But there can be simplistic ways of doing it.

True! And in fact, we'll focus on an analogue design. Thanks for your help!

When you select 'Map to Gates' from the Logic Friday menu, it pops up a dialog that lets you select which types of simple logic gates of up to four inputs to use.   Assuming you've got a Windows PC, grab a copy and experiment.  Its fairly simple to use.

I'll give it a try. Thanks!

A 3 to 8 line decoder takes a 3 bit binary number and uses it to select one of its 8 outputs to activate.   As the decoders I mentioned have both active high and active low enable inputs you can use two of then to perform a 4 to 16 line decoding function, by connecting the  4th bit to EN on one and /EN on the other.

Here's the NXP 74HC138 and 74HC238 datasheets.

You have four variables (the sensor outputs after they have been processed to a single bit digital value), and if you feed them into a pair of 3 to 8 line decoders wired as a 4 to 16 line decoder, each output represents one row in the truth table or one combination of ANDing the four variables or their compliments.  It therefore makes it absolutely simple to implement an arbitrary four variable combinational logic function from its truth table.   

If you used Schottky diodes to OR the selected terms together you could make different logic functions as plug-in modules so you could easily 'reprogram' your robot by changing a single 18 pin DIL header carrying the diodes required for the desired terms.  Obviously it would need a pullup/pulldown resistor for the two output pins from the diodes, and preferably a buffer after that.

This approach to combinational  logic using a decoder rapidly becomes impractical for more than 4 variables.  Its single chip equivalent is to use some type of parallel ROM programmed with the desired truth table in binary, which as you can get 1Mx8bit EEPROMs, allows you up to eight combinational functions of 20 variables in a single 32 pin chip!

Now I understan better, although I must read more about it. Thanks!

I would second the advice to use a microcontroller - UNLESS its a course aim to perform the task only with logic, in which case you are probably going to have to get very clever and build something fairly complex that does stuff like representing the sensor value as a PWM so you can process analog readings digitally without having to have either lots of parallel bits or clocked serial datastreams.   I doubt it can be done with simple combinatorial logic for anything except a smoothly curving line, as any sharp angles need knowledge of the previous state to distinguish between a gross tracking error where both sensors have lost the line and the process of continuing to turn to the side the line went to till its reacquired after driving forward to center over the point of the angle.

In fact is an introductory Analogue course, but we wanted to do something complicate but after all we decided to stick to a analogue LF. In the future, when we study digital, we'll try to build that complicate LF we wanted to build.
Now, we'll focus on the circuit provided by @MK14 in his reply: https://www.eevblog.com/forum/beginners/line-follower-and-logic-gates-simplification/msg1014134/#msg1014134

Although, we are still planning on doing a modular build in order to test the digital circuit and learn from that one too.

Here is an example of a really simple one (line follower):

http://playwithrobots.com/simple-line-follower-robot/

You really have two sensible choices, but I fear that you will choose neither, and it may not work out as planned.

(1)...Go really simple, and stick with simple. Seriously consider ditching pure digital, and have it much more analogue, if it helps. See how others have solved this problem.

(2)...Go with a Microcontroller. It allows a simple, initial solution. With the capabilities, to continually refine and add functionality, to quickly improve it as necessary.

We'll build this one and now we are aiming to build 100% analogue and leave the digital aside for this semester, although we are going to test it anyway (we already bought the parts  ). We are not that stubborn   

First one it is!

Attempting a complicated digital gate logic solution, worries me, as it would be much harder to change, and would have all sorts of technical limitations and issues. Digital logic is mainly 0's and 1's, but you really need more complexity to the signals (which Microcontrollers easily can do), and need to make much more complicated decisions, than seeing if something is either 0 or 1.
Great things can be done, purely digitally. But it can take immense skill, experience and education (possibly self taught), to achieve things like that.
Otherwise, FPGA's would be considered really simple.

If you really MUST have a complicated digital logic design. Perhaps consider a different type of project, better suited to a pure digital logic solution. Such as a frequency counter or digital stepper motor controller (possibly with Microstepping) or something.

I'll have that in mind! Thanks.

For flexibility, you can use a 16-1 MUX for each motor.  You can implement any function of 4 variables with such a MUX.  You would need two, of course and they would be 24 pin devices.  Run all 4 sensor signals to the select lines and patch the 16 inputs to be whatever your output should be.

http://www.ti.com/lit/ds/symlink/mm54c150.pdf

There are many such multiplexers, I just grabbed to first datasheet that popped up on Google.

Unfortunately the 74150 never became popular in CMOS so you'll have a lot of difficulty finding it in anything other than original bipolar TTL.  Its also a honking big 24 pin 0.6" wide DIP package.  Fortunately you can use the readily available 74HC4067 ANALOG 16:1 Mux for the same function, provided you add a pull-up resistor to its output.   Two of those and four octal DIP switches to pull selected inputs low would let you implement two arbitrary combinatorial four variable logic functions, and reprogram them simply by flicking switches.  They do have an /EN  pin so with an extra inverter, you can cascade two of them to hadle five variables, simply paralleling the outputs, but this rapidly becomes impractical for larger numbers of variables.

Thanks for your help! We'll have in mind your recommendations. 

Now I'll start again with the questions, I know you are helpful and that's why I'm taking advantage of that. I really like this forum 

I understand the next circuit but not completely (This is the main reason why we decided to do it analogue because we have so much to learn and to know a few components doesn't mean that we are ready to try a digital solution, thanks for making us understand that!).

http://playwithrobots.com/images/old/lfr-without%20mcu%20complete.jpg

We can say it has 3 Modules:

Module 1: Sensor - In this module I can't seem to figure out how is it going to be supply with a voltage, obviousely it will use the battery to do that but it will use the (i.e 9 volt battery) 9 volts or will use the 5V that the 7805 is going to supply? And how does this module connects to the Module 2?

Module 2: Control - In this module why do we need a D880? Could the same effect be achieve without a transistor? Or, reformulating the question, why do we need a transistor there?

Module 3: Power Supply - This module connects to the Module 2 using the third pin of the 4-pin connector, but then there is no connection between this ping and the actual circuit, right?

I'll post an image showing these question:

http://prntscr.com/ccd8of

Again, thank you SO MUCH for being so helpful, kind and patience. You are awesome 

[MK14]

I have question, why must a layout have corner markers? I've watched a few videos and I think those are use to produce a sound which I don't see more use, although I'm sure I'm making a mistake by assuming that. Hope you can clarify that for me.

I'm NOT 100% sure about the cornering markers, full explanation and reasoning. But have some idea, which I have put, below. Some people are real experts in this field (which is NOT me).

Very broadly speaking, there are three levels of technological, competition techniques, people use to make their robots. Take my descriptions very loosely, because competition rules may vary, over time and by country/organization. This is just to give you some idea.

(1)..Beginner
The robot (line-follower), makes steady (but somewhat slow) progress, following the lines, the fact that it finishes the track, is in itself, a great achievement. It just does the bare minimum (technically), to follow the line, and does little or nothing, to attempt to speed up the progress. But they can be fairly fast, so don't despair too much. Animal kingdom analogy: Tortoise or Rabbit.

(2)..Advanced
It uses extra track information if available (such as the corning markers you mentioned), by using extra sensors as necessary, it makes quite fast progress, and is rather advanced, technically speaking. It gets quite good speed responses, but not necessarily enough to win the competition. Animal kingdom analogy: Horse

(3)..Mega Advanced
Very advanced robots, (I can't remember if mapping the full track, is theoretical or has been done yet) actually map the entire track (if I understand things correctly, I'm not 100% sure how many use that specific technique, if NOT, they still use complicated things, to make it go as fast as possible), into their MCU memories, after the first pass (assuming competition rules are compatible with this). Allowing them to go at maximum speed, because it knows where it needs to slow down and speed up. Having very advanced control/sensing mechanisms, so that turns, can be taken at sensible, highest possible speeds, without losing control. Even in the first pass, the extra sensors and capabilities, may still help speed up its times, significantly.  Animal kingdom analogy: A very fast, animal lookalike, robot from Star Wars!

Both types (2) and (3), can potentially measure the individual wheel speeds, have accelerometers and/or gyroscope sensors, and have powerful enough microcontrollers (MCU), to make quick progress through the track(s). Using things like PID control loops, and other more advanced techniques.

(I'm making educated guesses, for this paragraph) The sounds you are describing, if made when the corner markers are detected, is probably to help the robot builder confirm that his robot is successfully/reliably detecting those markers. This in itself, can be a significant undertaking. Since a sensor(s) could easily mis-interpret a false sensor signal (e.g. sunlight) as one and/or a real corner marker could be missed.
If you try and detect them in practice, you may well find it is much harder to do in real life, reliably, every time, than you might initially imagine.


I'm very impressed with your analysis of this thread, and the decisions you have made as a result. You seem to be thinking this out logically, and making sensible decisions, as to how to move things forward (please ignore the pun).

A purely analogue design, means that you can have many overall adjustments, so that you can get the sensing just right, the basic speed slow enough to not lose control, and yet quick enough, to progress, reasonably well.

[MK14]

I understand the next circuit but not completely (This is the main reason why we decided to do it analogue because we have so much to learn and to know a few components doesn't mean that we are ready to try a digital solution, thanks for making us understand that!).

http://playwithrobots.com/images/old/lfr-without%20mcu%20complete.jpg

We can say it has 3 Modules:

Module 1: Sensor - In this module I can't seem to figure out how is it going to be supply with a voltage, obviousely it will use the battery to do that but it will use the (i.e 9 volt battery) 9 volts or will use the 5V that the 7805 is going to supply? And how does this module connects to the Module 2?

Module 2: Control - In this module why do we need a D880? Could the same effect be achieve without a transistor? Or, reformulating the question, why do we need a transistor there?

Module 3: Power Supply - This module connects to the Module 2 using the third pin of the 4-pin connector, but then there is no connection between this ping and the actual circuit, right?

I'll post an image showing these question:

http://prntscr.com/ccd8of

Again, thank you SO MUCH for being so helpful, kind and patience. You are awesome 

The LDRs, light dependent resistors. Can only make a very small current, probably a few milliamps (without checking the datasheet). Since they are somewhat high resistanced sensors.
But motors need lots of current. Again without checking the datasheet, I would expect it to be a few hundred milliamps, or maybe even more. So the transistors are acting as current amplifiers, taking (probably) milliamps from the light sensors, and turning it into hundreds of milliamps (maybe more), to power the motors.
Without looking up the transistors datasheet or analyzing the circuit, a very approximate rule of thumb is that the current gain (Hfe or beta) would be about x100. (Somewhere in the x50 to x200 or so, I guess)

I think that it says that connectors, J1 and J2 are connected together, via a 4 wire jumper cable. Which is how the two circuits, interconnect. But I have only had a somewhat quick look at it, so could be mistaken.

I have to agree with you, it would make a very good starting point (that hopefully works). If not, it looks rather quick and easy, to modify it so that it does. Once it works, you can try and improve it, in small increments. If the "improvement", actually makes it worse or makes it stop working. You can simply, "roll back", to the last fully working design.
Also if you run out of time or resources, you will always have the latest, fully working prototype. In theory at least. It also looks extremely cheap, quick and easy to start with.

EDIT: The transistor datasheet is here:
http://www.elite-ent.com.hk/php/pdf/To-220/D880(TO-220).pdf

[dannyf]

With a 555 and some light sensors, you can generate a pwm pulse train whose duty cycle reflects the relative strength of the light sensed by the sensor.

Much simpler than what you have.

[rstofer]

I understand the next circuit but not completely (This is the main reason why we decided to do it analogue because we have so much to learn and to know a few components doesn't mean that we are ready to try a digital solution, thanks for making us understand that!).

http://playwithrobots.com/images/old/lfr-without%20mcu%20complete.jpg

We can say it has 3 Modules:

Module 1: Sensor - In this module I can't seem to figure out how is it going to be supply with a voltage, obviousely it will use the battery to do that but it will use the (i.e 9 volt battery) 9 volts or will use the 5V that the 7805 is going to supply? And how does this module connects to the Module 2?

J1 plugs into J2 and picks up +5V on pin 2 along with Gnd on pin 1.

Module 2: Control - In this module why do we need a D880? Could the same effect be achieve without a transistor? Or, reformulating the question, why do we need a transistor there?

Whatever type of logic you use, it won't have the capability of driving a motor.  It simply can't handle the current.  And this circuit doesn't even have any logic.  The sensors provide the base voltage and they can only produce a small current.

Module 3: Power Supply - This module connects to the Module 2 using the third pin of the 4-pin connector, but then there is no connection between this ping and the actual circuit, right?

I'll post an image showing these question:

http://prntscr.com/ccd8of

Again, thank you SO MUCH for being so helpful, kind and patience. You are awesome 

Right, the motor driver circuit does not use the 5V supply but since J1 plugs into J2, +5 needs to be there.  Notice the potentiometer at the base of each transistor.  This allows for a bit of speed control depending on how much current the sensor can provide.

If we assume J1 plugs into J2, where does J1 get the +5V and Gnd?  Well, that's not exactly shown but it comes from the voltage regulator shown at the bottom of the schematic.

ADD:
The transistor has a gain of 70 or less at 1A and even the smallest DC motor takes 1A at startup.  So, that means the LDR has to be able to produce a base current of 15 mA for even the smallest motor.  Well, maybe not, maybe we just don't give the motor all it wants at startup...  I don't have a datasheet for the LDRs so I really can't comment on how well it will provide the base current.

ADD SOME MORE:
The potentiometers actually allow you to balance the 'bot for straight forward motion.  They help account for differences in sensor output and transistor gain.  Clever!

[MK14]

ADD:
The transistor has a gain of 70 or less at 1A and even the smallest DC motor takes 1A at startup.  So, that means the LDR has to be able to produce a base current of 15 mA for even the smallest motor.  Well, maybe not, maybe we just don't give the motor all it wants at startup...  I don't have a datasheet for the LDRs so I really can't comment on how well it will provide the base current.

ADD SOME MORE:
The potentiometers actually allow you to balance the 'bot for straight forward motion.  They help account for differences in sensor output and transistor gain.  Clever!

Making clever robots (and stuff), with extremely simple circuitry, actually can be a major engineering feat. Potentially involving many failed experimental ways of doing it, but it performs badly.

The author when describing the same (or a different, but similar motor), seems to say the current will be around 250 milliamps. But it depends on what motor is used. The motors on small robots like this, can be deceptively small.

http://playwithrobots.com/dc-motor-driver-circuits/

Note :

Check the rating of the transistor you are using. It must be greater than the maximum current drawn by your motor. A normal DC motor as shown below draws 250mA current. D880 transistor has a max collector current rating of 3A.

EDIT:
Motors can use a lot more current when you start them up. But my description in the earlier post, was referring to running current, NOT start up current.

[rstofer]

EDIT:
Motors can use a lot more current when you start them up. But my description in the earlier post, was referring to running current, NOT start up current.

Exactly right!  I have burned up some small H-Bridges due to startup current.  You have to supply the startup current to get the motor turning.  If you don't, the motor stalls and draws maximum current until the magic smoke pours out of the driver.

[MK14]

EDIT:
Motors can use a lot more current when you start them up. But my description in the earlier post, was referring to running current, NOT start up current.

Exactly right!  I have burned up some small H-Bridges due to startup current.  You have to supply the startup current to get the motor turning.  If you don't, the motor stalls and draws maximum current until the magic smoke pours out of the driver.

I was wondering about exactly the same thing.

My guess is that it is because he has got the gearbox (ratio apparently not stated, but I would guess it is something like 50 to 1), which can probably allow, less current, to gradually build up the motor speed.

BUT with little or no gearbox ratio, I agree the motor would potentially just sit there and stay stalled.

Even with a high ratio gearbox, it could still stall.

Anyway, I attempted to find the motor datasheet, earlier. The closest, very cheap/small motor, I could find (he does not seem to state the exact motor), only needs, 70mA's or so, under no load. I think the maximum draw was 1070mA (from memory), when 100% stalled.

Hopefully, with a high ratio gearbox, a few hundred milliamps (the transistors/LDR might supply more than this anyway, battery permitting), will be enough to get the motors spinning.

But anyway, I agree with you. Care must be taken, to ensure that it can start up successfully.

EDIT:
To explain it a different way, to make sure I am clear enough.
Let's say the motor needs exactly 1 amp, when stalled.
If it (while stalled), only gets 500mA's (if the transistors Hfe is too low and/or LDR's too weak, current wise), it will/should still generate some torque. As long as the load can accept the reduced torque (which with a suitable gearbox, it can), the motor can build up speed (RPM), and no longer be stalled.
So the $64,000,000 question, is, is the start up (initial) load, less than the torque generated by the motor, when it receives whatever amount of current the transistors and LDR, decide to give it, initially.
Given it works on the you tube videos, I presume that it does.

[rstofer]

One neat thing is that the transistors are in a TO-220 package so they can take some abuse.  A heatsink could be added.  In any event, the transistors won't be as likely to fail from high current as an H-Bridge.

[MK14]

One neat thing is that the transistors are in a TO-220 package so they can take some abuse.  A heatsink could be added.  In any event, the transistors won't be as likely to fail from high current as an H-Bridge.

H-Bridges are sensitive to shoot-through, which might occur when the MCU (if you are using one) comes out of reset (potentially output pins are floating), or it might be during switching transitions, when the top and bottom transistors, briefly conduct at the same time (shoot-through), but that could be enough to cause disastrous problems.
The back-emf of the motor might also be problematic, in some cases.

Better designs that I've seen, have both anti-shoot-though circuitry, even if both top and bottom, are (incorrectly) requested at the same time, and any back-emf protection, as necessary.

I'm throwing the following circuit, to give an idea, of what I am talking about. High power ones (which that is), makes it that much harder, anyway.

[Ian.M]

It may be worth trying to PWM the motors.  An astable multivibrator, with the photosensors as the base pullup resistors could generate the PWM, and that can be emitter coupled to the power transistors to drive the motors.   Something like this:

The transistors will run cooler, the battery will last longer, and the motors should respond more smoothly at low speeds.

[Nexo]

I have question, why must a layout have corner markers? I've watched a few videos and I think those are use to produce a sound which I don't see more use, although I'm sure I'm making a mistake by assuming that. Hope you can clarify that for me.

I'm NOT 100% sure about the cornering markers, full explanation and reasoning. But have some idea, which I have put, below. Some people are real experts in this field (which is NOT me).

Very broadly speaking, there are three levels of technological, competition techniques, people use to make their robots. Take my descriptions very loosely, because competition rules may vary, over time and by country/organization. This is just to give you some idea.

(1)..Beginner
The robot (line-follower), makes steady (but somewhat slow) progress, following the lines, the fact that it finishes the track, is in itself, a great achievement. It just does the bare minimum (technically), to follow the line, and does little or nothing, to attempt to speed up the progress. But they can be fairly fast, so don't despair too much. Animal kingdom analogy: Tortoise or Rabbit.

(2)..Advanced
It uses extra track information if available (such as the corning markers you mentioned), by using extra sensors as necessary, it makes quite fast progress, and is rather advanced, technically speaking. It gets quite good speed responses, but not necessarily enough to win the competition. Animal kingdom analogy: Horse

(3)..Mega Advanced
Very advanced robots, (I can't remember if mapping the full track, is theoretical or has been done yet) actually map the entire track (if I understand things correctly, I'm not 100% sure how many use that specific technique, if NOT, they still use complicated things, to make it go as fast as possible), into their MCU memories, after the first pass (assuming competition rules are compatible with this). Allowing them to go at maximum speed, because it knows where it needs to slow down and speed up. Having very advanced control/sensing mechanisms, so that turns, can be taken at sensible, highest possible speeds, without losing control. Even in the first pass, the extra sensors and capabilities, may still help speed up its times, significantly.  Animal kingdom analogy: A very fast, animal lookalike, robot from Star Wars!

Both types (2) and (3), can potentially measure the individual wheel speeds, have accelerometers and/or gyroscope sensors, and have powerful enough microcontrollers (MCU), to make quick progress through the track(s). Using things like PID control loops, and other more advanced techniques.

(I'm making educated guesses, for this paragraph) The sounds you are describing, if made when the corner markers are detected, is probably to help the robot builder confirm that his robot is successfully/reliably detecting those markers. This in itself, can be a significant undertaking. Since a sensor(s) could easily mis-interpret a false sensor signal (e.g. sunlight) as one and/or a real corner marker could be missed.
If you try and detect them in practice, you may well find it is much harder to do in real life, reliably, every time, than you might initially imagine.


I'm very impressed with your analysis of this thread, and the decisions you have made as a result. You seem to be thinking this out logically, and making sensible decisions, as to how to move things forward (please ignore the pun).

A purely analogue design, means that you can have many overall adjustments, so that you can get the sensing just right, the basic speed slow enough to not lose control, and yet quick enough, to progress, reasonably well.

Again, Thank you so much for your time and I apologize for not replying earlier, I'm really busy with other subjects as well but now I'm back and I have a lot to show you. This is exciting

PD: Thanks for your last comment!

I understand the next circuit but not completely (This is the main reason why we decided to do it analogue because we have so much to learn and to know a few components doesn't mean that we are ready to try a digital solution, thanks for making us understand that!).

http://playwithrobots.com/images/old/lfr-without%20mcu%20complete.jpg

We can say it has 3 Modules:

Module 1: Sensor - In this module I can't seem to figure out how is it going to be supply with a voltage, obviousely it will use the battery to do that but it will use the (i.e 9 volt battery) 9 volts or will use the 5V that the 7805 is going to supply? And how does this module connects to the Module 2?

Module 2: Control - In this module why do we need a D880? Could the same effect be achieve without a transistor? Or, reformulating the question, why do we need a transistor there?

Module 3: Power Supply - This module connects to the Module 2 using the third pin of the 4-pin connector, but then there is no connection between this ping and the actual circuit, right?

I'll post an image showing these question:

http://prntscr.com/ccd8of

Again, thank you SO MUCH for being so helpful, kind and patience. You are awesome 

The LDRs, light dependent resistors. Can only make a very small current, probably a few milliamps (without checking the datasheet). Since they are somewhat high resistanced sensors.
But motors need lots of current. Again without checking the datasheet, I would expect it to be a few hundred milliamps, or maybe even more. So the transistors are acting as current amplifiers, taking (probably) milliamps from the light sensors, and turning it into hundreds of milliamps (maybe more), to power the motors.
Without looking up the transistors datasheet or analyzing the circuit, a very approximate rule of thumb is that the current gain (Hfe or beta) would be about x100. (Somewhere in the x50 to x200 or so, I guess)

I think that it says that connectors, J1 and J2 are connected together, via a 4 wire jumper cable. Which is how the two circuits, interconnect. But I have only had a somewhat quick look at it, so could be mistaken.

I have to agree with you, it would make a very good starting point (that hopefully works). If not, it looks rather quick and easy, to modify it so that it does. Once it works, you can try and improve it, in small increments. If the "improvement", actually makes it worse or makes it stop working. You can simply, "roll back", to the last fully working design.
Also if you run out of time or resources, you will always have the latest, fully working prototype. In theory at least. It also looks extremely cheap, quick and easy to start with.

EDIT: The transistor datasheet is here:
http://www.elite-ent.com.hk/php/pdf/To-220/D880(TO-220).pdf

I got it! Thanks

With a 555 and some light sensors, you can generate a pwm pulse train whose duty cycle reflects the relative strength of the light sensed by the sensor.

Much simpler than what you have.

Thanks for your comment! in fact we are thinking about using a 555 in order to control the motors velocity because we are having a problem with that, check a video below, please.

I understand the next circuit but not completely (This is the main reason why we decided to do it analogue because we have so much to learn and to know a few components doesn't mean that we are ready to try a digital solution, thanks for making us understand that!).

http://playwithrobots.com/images/old/lfr-without%20mcu%20complete.jpg

We can say it has 3 Modules:

Module 1: Sensor - In this module I can't seem to figure out how is it going to be supply with a voltage, obviousely it will use the battery to do that but it will use the (i.e 9 volt battery) 9 volts or will use the 5V that the 7805 is going to supply? And how does this module connects to the Module 2?

J1 plugs into J2 and picks up +5V on pin 2 along with Gnd on pin 1.

Module 2: Control - In this module why do we need a D880? Could the same effect be achieve without a transistor? Or, reformulating the question, why do we need a transistor there?

Whatever type of logic you use, it won't have the capability of driving a motor.  It simply can't handle the current.  And this circuit doesn't even have any logic.  The sensors provide the base voltage and they can only produce a small current.

Module 3: Power Supply - This module connects to the Module 2 using the third pin of the 4-pin connector, but then there is no connection between this ping and the actual circuit, right?

I'll post an image showing these question:

http://prntscr.com/ccd8of

Again, thank you SO MUCH for being so helpful, kind and patience. You are awesome 

Right, the motor driver circuit does not use the 5V supply but since J1 plugs into J2, +5 needs to be there.  Notice the potentiometer at the base of each transistor.  This allows for a bit of speed control depending on how much current the sensor can provide.

If we assume J1 plugs into J2, where does J1 get the +5V and Gnd?  Well, that's not exactly shown but it comes from the voltage regulator shown at the bottom of the schematic.

ADD:
The transistor has a gain of 70 or less at 1A and even the smallest DC motor takes 1A at startup.  So, that means the LDR has to be able to produce a base current of 15 mA for even the smallest motor.  Well, maybe not, maybe we just don't give the motor all it wants at startup...  I don't have a datasheet for the LDRs so I really can't comment on how well it will provide the base current.

ADD SOME MORE:
The potentiometers actually allow you to balance the 'bot for straight forward motion.  They help account for differences in sensor output and transistor gain.  Clever!

I'm learning a lot, thanks for your reply!

EDIT:
Motors can use a lot more current when you start them up. But my description in the earlier post, was referring to running current, NOT start up current.

Exactly right!  I have burned up some small H-Bridges due to startup current.  You have to supply the startup current to get the motor turning.  If you don't, the motor stalls and draws maximum current until the magic smoke pours out of the driver.

We'll have that in mind. Thanks!

EDIT:
Motors can use a lot more current when you start them up. But my description in the earlier post, was referring to running current, NOT start up current.

Exactly right!  I have burned up some small H-Bridges due to startup current.  You have to supply the startup current to get the motor turning.  If you don't, the motor stalls and draws maximum current until the magic smoke pours out of the driver.

I was wondering about exactly the same thing.

My guess is that it is because he has got the gearbox (ratio apparently not stated, but I would guess it is something like 50 to 1), which can probably allow, less current, to gradually build up the motor speed.

BUT with little or no gearbox ratio, I agree the motor would potentially just sit there and stay stalled.

Even with a high ratio gearbox, it could still stall.

Anyway, I attempted to find the motor datasheet, earlier. The closest, very cheap/small motor, I could find (he does not seem to state the exact motor), only needs, 70mA's or so, under no load. I think the maximum draw was 1070mA (from memory), when 100% stalled.

Hopefully, with a high ratio gearbox, a few hundred milliamps (the transistors/LDR might supply more than this anyway, battery permitting), will be enough to get the motors spinning.

But anyway, I agree with you. Care must be taken, to ensure that it can start up successfully.

EDIT:
To explain it a different way, to make sure I am clear enough.
Let's say the motor needs exactly 1 amp, when stalled.
If it (while stalled), only gets 500mA's (if the transistors Hfe is too low and/or LDR's too weak, current wise), it will/should still generate some torque. As long as the load can accept the reduced torque (which with a suitable gearbox, it can), the motor can build up speed (RPM), and no longer be stalled.
So the $64,000,000 question, is, is the start up (initial) load, less than the torque generated by the motor, when it receives whatever amount of current the transistors and LDR, decide to give it, initially.
Given it works on the you tube videos, I presume that it does.

Thanks for your comment!

One neat thing is that the transistors are in a TO-220 package so they can take some abuse.  A heatsink could be added.  In any event, the transistors won't be as likely to fail from high current as an H-Bridge.

H-Bridges are sensitive to shoot-through, which might occur when the MCU (if you are using one) comes out of reset (potentially output pins are floating), or it might be during switching transitions, when the top and bottom transistors, briefly conduct at the same time (shoot-through), but that could be enough to cause disastrous problems.
The back-emf of the motor might also be problematic, in some cases.

Better designs that I've seen, have both anti-shoot-though circuitry, even if both top and bottom, are (incorrectly) requested at the same time, and any back-emf protection, as necessary.

I'm throwing the following circuit, to give an idea, of what I am talking about. High power ones (which that is), makes it that much harder, anyway.

I'm already lost  . I'll have to study this. Thanks.

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

Well, now I would like to share with you what we've been able to accomplish.

1. We decided to build an analogue LF and we made a mistake. In the schematic provide by MK14, a LDR was used but at that time we already have bought a built-in sensor (sadly, I can't remember the name). Have a look:

This is the main schematic: http://prntscr.com/chqdx5

And this is the schematic with the changes we had to make in order to make it work (the changes were made by a team-member who has almost 12 years of empiric experience and he decided to go to college and learn the theory) but I don't quite understand what he has done because he is not that good at explaining  : http://prntscr.com/chqekx

He added some npn transistors in order to accomplish something I don't understand, hope some of you could explain it better.

This is what we got: http://prntscr.com/chqezw

And this is a LF: http://prntscr.com/chqf44

But we encounter a problem, again... The motors turn way too fast and we weren't able to fix that so we also decided to build the digital one, after all, the circuit was ready, already  :

And, magic, it works better than the analogue one and we decided to focus on this one because there is only one problem to fix, while in the analogue one, there are more than a few. Watch this video:

https://youtu.be/_c8a9pQ_xJk

Now, the questions we have are, how can we control the motors velocity? As you can see, they have a really high velocity and in some parts of the line, it makes the LF to get off the track.

The other question we have is the next one: We tried to calculate the current needed to use the motor base on Ohm's law with a 12 voltage and a resistance of 8.8 Ohms (this resistance was measured with a multimeter) so, theoretically we must use 1.36 Amps but when we use a power supply in order to check this result we got the following result:

http://prntscr.com/chqhqs

As you can see, it only needs 190 miliamps... Is it because of the initial force needed to overcome the motor's inertia?

I'm really looking forward to your replies.

Again, thank you for being patient and helpful.

Have a great day!

[rstofer]

It's because the motor generates a back EMF as it rotates and this counteracts the applied voltage thus reducing the current.  If the motor is stalled, the current will be based on the resistance you measured.

https://en.wikipedia.org/wiki/Counter-electromotive_force