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

[MK14]

Congratulations on getting as far as you have, so far!

The motor current draw, is NOT like a fixed resistor value.

It will usually use, the least current when it is just freely spinning (unloaded), such as the 120 mA's approx, that you have shown in your picture. If you disconnected the gearbox, it would probably use even less current.

If you put lots of load on the motor, such as when it is driving on the track, the current will probably go up a lot. To something like 500mA's (guess).

If you stopped the motor from spinning. E.g. By locking it in a vice (N.B. Best to NOT try this, as it can overheat the motor and damage it), it will tend to use the most current, and may use an amp, or even a few amps, depending on the winding resistance of the motor.
This is usually called the motor stall current.

The light sensors, appear to be phototransistors. These are VERY commonly used in line followers, and many other applications.

I'm pleased that you have got reasonable results with the digital solution. But as I tried to warn you about earlier, the problem you may get, is that in order to improve it and/or get it to work properly, you don't get the adjustability/flexibility that an analogue or microcontroller based digital solution gives you.
But we should still be able to sort it out, hopefully.

Giving the motor less voltage (e.g. < 5V), should slow it down. But too low, will stop it from turning, completely. As it probably needs about 1V to 3V minimum, before it starts to turn.

Or add additional resistance to the path between the motor and the output driver.

Or reduce the current(s) going into the driving transistors bases, by making the 1K resistors bigger and/or adding an adjustable potentiometer, in series with the 1K resistors.

There may be other ways of slowing it down, such as using a higher gear ratio, in the gearbox (too late if you have already bought them, I guess. But some are adjustable within limits, by exchanging gears and stuff. This only applies to some rare gearboxes, and probably not the ones you are using. I.e. They are called adjustable ratio gearboxes and already include the right gears selection, so you can change it. Non-changeable may still be adjustable, but you would have to go out and buy/find the alternative gears and stuff, yourself, and they may not fit).

If you had used an MCU (probably a bad idea, until you are much more familiar with stuff like that), you could have used PWM (which you still can, by using hardware to create the PWM, which would allow you to slow the motors down, that way, by reducing the PWM duty cycle).

tl;dr
There are many ways of slowing the motors down. Probably using resistors, is going to be the quickest/easiest solution for you currently. Either in series with the motor (make sure they can handle the power dissipation) or in series with the base of the driving transistor (which has much less current in it, so adjustable potentiometers, are easier to put in place there, but maybe less accurate control).

[Ian.M]

A PWM solution would be good.  I think the light sensor section should be kept analog even if you want to use digital for the control algorithm.  That way you can have an OPAMP differential amplifier followed by a precision rectifier to get a voltage that is proportional to how well balanced the sensors are.  Use it for a control voltage for the PWM and it will speed up both motors when its tracking the line, but slow right down if it goes significantly off center.  The hunting oscillation you have at the moment is indicative of too much loop gain if its using analog tracking or of 'bang-bang' digital tracking.  You probably need to dither the inputs to get something approximating to a proportional response.

N.B. If you want better advice from us, you'll need to provide a full schematic (please not at whatever crappy image hosting site you've found - reduce it to a 16 colour GIF or PNG and attach it directly to your post here), accurate dimensioned chassis layout, measured width of line, and specs for the sensors and motors e.g part numbers, and for the motors nominal operating voltage., wheel diameter and no-load speed.   

[Nexo]

Thanks to both of you !

I'll start gathering all the info but it may take a few days because the LF is not with me and we have exams this week.
Now I would like to share with you a video of a new version, the last one was not working to well because the guy who was in charge of doing it, put a NAND IC instead of an AND circuit - no idea how it was working 

https://youtu.be/LNWKUFlRp8k

[MK14]

I'm surprised you (and your team mates), have been able to make it work like that, by using logic gates. I would have thought it was too harsh in its control movements, and would have lost control.

Some people do come up with amazingly simplistic systems, for controlling their robots, which I find fascinating when I hear about it. Such as using just a bent paper clip, and a micro switch or two, to achieve similar results to what you just demonstrated. But it used a different type of course, where there were more physical elements which the microswitch/paper clip could track, such as a narrow wall.

I can't remember the exact details, so could be wrong. There are probably websites, with information about such things.

The disadvantage to your system, is that if you want to refine and/or improve it. E.g. to be smoother, more reliable and/or faster. You would have little capability to do that. But if it had been implemented in a microcontroller. You could improve/expand/tweak your program, to make it better and better.

But for your purposes, of achieving marks in your academic practical test(s), it has/is achieving its purpose, and does not necessarily need a microcontroller or high speed, etc etc.

[Nexo]

Thanks!

Well, the secret was to add some kind of a breaks near the wheel because we made some calculations:

The radius of the wheel is: 33 mm so in one turn it would travel 20 cm and the motor has 100 RPM so no wonder why it was "yawing" that much, it still is but we've been able to figure it out and at least it has improved quite a bit.

So we pretty much have two options here, we are hoping to implement both, though:

1. Find a smaller-radius wheel, for example half the one we currently have (hoping it fits on our LF) that way, with each turn, it would travel just 10 cm, thus, it wouldn't yaw to much.

2. Use 2 Timers 555 in order to be able to control the motors.

Now, I team mate stated the following: "we should use an electrolytic capacitor -in the power module (motors) so when the motor stops it would reverse its polarity thus making it turn in the opposite direction for a few milisecs.

What do you guys think about this idea?

Again, thank you for being so helpful!

[MK14]

Tweaking it in ways similar to what you suggest, may be able to improve it. The backlash in the gearbox, may prevent/minimize brief reversal of the motor, from giving you better results.
Also motors tend to be somewhat slow to respond to very quick signals. Ironically, your original idea of the stepper motors, may have responded faster (I'm not 100% sure about that though).

But messing about with extra 555 timers, could allow quick/simple modifications, which would either improve it or not. So you could quickly experiment, and keep improvements, and leave off if it makes it worse.

H bridge motor control, would have allowed easy motor reversal, by the 555 timer (or an MCU).

Lowering the voltage to the motors and/or limiting the current to the motors, will also provide a quick way of slowing it down, or better still (but more complicated), is to PWM the motors. Very slow motor speed, probably needs PWM, otherwise the motors will tend to just stop/stall, because of a lack of minimum voltage requirements.
So PWM is probably the best way of achieving slow, controllable speeds, and yet keeping the torque up.

[Nexo]

Tweaking it in ways similar to what you suggest, may be able to improve it. The backlash in the gearbox, may prevent/minimize brief reversal of the motor, from giving you better results.
Also motors tend to be somewhat slow to respond to very quick signals. Ironically, your original idea of the stepper motors, may have responded faster (I'm not 100% sure about that though).

But messing about with extra 555 timers, could allow quick/simple modifications, which would either improve it or not. So you could quickly experiment, and keep improvements, and leave off if it makes it worse.

H bridge motor control, would have allowed easy motor reversal, by the 555 timer (or an MCU).

Lowering the voltage to the motors and/or limiting the current to the motors, will also provide a quick way of slowing it down, or better still (but more complicated), is to PWM the motors. Very slow motor speed, probably needs PWM, otherwise the motors will tend to just stop/stall, because of a lack of minimum voltage requirements.
So PWM is probably the best way of achieving slow, controllable speeds, and yet keeping the torque up.

My exact same thoughts (at least the PWM part  )

The problem with lowering the voltage is that it doesn't reduce the motor speed. We supplied 12V, then 10V, then 7 V and the speed was pretty much the same but it we supply less than 6V, it will stop rolling and we are also using a LM7805 in order to supply 5V to the sensors.

Now, would it be a good idea to reduce the current supplied to the motors? I guess it would but I don't know how to achieve it. Maybe placing the motors in parallel so the voltage would be the same and the current would be half the current value when moving.

I would love to know your opinion on this idea.

Thanks!

[MK14]

My exact same thoughts (at least the PWM part  )

The problem with lowering the voltage is that it doesn't reduce the motor speed. We supplied 12V, then 10V, then 7 V and the speed was pretty much the same but it we supply less than 6V, it will stop rolling and we are also using a LM7805 in order to supply 5V to the sensors.

Now, would it be a good idea to reduce the current supplied to the motors? I guess it would but I don't know how to achieve it. Maybe placing the motors in parallel so the voltage would be the same and the current would be half the current value when moving.

I would love to know your opinion on this idea.

Thanks!

Motors can become very complicated.

The voltage you supply to the motor. E.g. 12 volts, will allow it to build up speed to a certain RPM (the RPM is NOT fixed, it depends on load and other factors). But motors take time to build up the RPM (and hence speed etc). So although you are giving it 12 volts, its RPM may be a lot lower at this exact point in time, as it will take time to accelerate up the RPM which it can potentially reach with that voltage (and current drive capability).

I.e. The motor is not at its final RPM for that voltage/load, until the robot has reached the max velocity for that motor power/voltage/current value. This takes time, and may not even happen, if the load/gear-ratios don't allow it. I.e. the RPM may be held back because the motor has not got enough "push" to accelerate any more. Anyway motors get rather complicated, when you get into the finer details.

This is why I keep on rattling on and on about using Microcontrollers (N.B. I fully agree that it is probably WAY, WAY too soon for you to use MCU's yet. As it needs lots of knowledge and experience etc, to use them well, and they are rather complicated until you know about them).

But the MCU would be able to use quadrature decoders (or other methods), and hence know/read the exact wheel/robot speed. N.B. The wheel rotation speed can be different between the left and right hand sides, and it can even be different from what the robots velocity is (e.g. Wheel spin/slip etc).

Once you know the wheel speeds, robot velocity (estimation) and can PWM the motors inside an MCU, using a PWM'ed H bridge motor drivers, plus position sensors (line sensors), and maybe even accelerometers and gyroscopes etc etc.

You can create/use algorithms to make sensible choices about how you will react.

What you are trying to do, is tweak the robot (line followers) performance, using rather simple/crude means, which are mostly ignoring the wheel speeds, robot velocity/direction, etc etc. Hence in many cases your attempted tweaks will not work well.

You can limit the current, but it can reduce the torque too much, and potentially stop/stall the motor and/or give it too little torque. My understanding is that PWM gives better results, because during the "ON" parts of the PWM duty cycle, it effectively gives the motor (potentially) the FULL current, and hence tends to maintain reasonable torque WITHOUT stalling the motor, too badly.

This is why (if I understand/remember things correctly), drill speed controllers, are also best done using PWM techniques or similar. Otherwise the drill bit becomes too weak (too little torque), to successfully drill into the materials that you want to make holes in.

tl;dr
You may have to accept the fact that without using a microcontroller, and extra sensors and better ways of controlling the motor. You are going to be rather limited in ways that you can improve its performance.

But don't let me put you off too much. There are going to be improvements to be had, I would imagine.

Going the microcontroller route becomes EXTREMELY involved, complicated and time consuming, going well beyond the kind of technical resources and time, I expect your team intend to put into this project. People who do work like that, are usually already Electronics and/or software experts, to at least some extent. But even beginners sometimes have a go at stuff like that. There are also kits available (probably not suitable for your studies as it would probably be considered cheating).

EDIT:
Please DON'T be too put off by my mentioning MCUs. There are many, many ways of doing Line followers, which people use which DON'T involve mcu's, and their performance can be quite good, maybe even very good. In principle line followers, is simple enough to do, without MCU's.
I'm just way too biased in favour of MCU's, and this bias seems to be leaking out too much in my answers.
Sorry!

[danadak]

For future consideration.

You mentioned you are doing this discretely to learn rather than use a UP approach. That
logic then would have you do this all at the transistor level. All of us have to jump into tech-
nology at a further point down the timeline of discovery, relying on past development and
knowledge. I will stop pontificating 

Cypress PSOC has ARM core, A/D (SAR and DelSig), DSP, logic fabric that can be used at
a GUI level or programmed in Verilog (much more important in future career), DMA, OpAmps,
PWM, COM, onboard Vref......see attached "component" list. In PSOC a component is a piece
of onboard HW. PSOC has LUTs and basic gates, counters, shift regs....you can either config
with GUI tool or program in Verilog. Tons of training videos, tool has many example project
solutions you can draw from. All components come with APIs you use in code to operate the
various components.

You can even design your own components, as well as program DSP engine in ASM to create
high performance custom DSP designs. DSP is a separate core inside PSOC.

Component list attached, as well as an example using DSP to filter a signal. Note this only used
a small %age of the resources, eg. one could have added a lot more functionality to the project.

Keep in mind you route the signals internally and to pins, with the GUI tool. its its own
breadboard, FPGA like.

SW tool free, low cost boards, $ 10 - $ 25.

Regards, Dana.