QTR-8A not read correctly

If you are toggling the emitter pin to save power, you should be sure to turn it on any time you are reading the sensors (including while you are calibrating). The pin number used is defined in your code and called in the constructor, so you can change it if you want. In the code you posted above, it is defined and used in the following lines:

#define EMITTER_PIN 18 //QTR_NO_EMITTER_PIN     // emitter is controlled by digital pin 2
QTRSensorsAnalog qtra((unsigned char[]) {A0, A1, A2, A3, A4, A5, A6, A7},

Alternatively, if you do not need to save power and you are ok with always leaving the emitter on, you could leave the emitter pin disconnected and use the QTR_NO_EMITTER_PIN argument when calling the constructor (in place of the EMITTER_PIN argument).


1 Like

I seem some examples code they have led on, does it meant extra external led help to calibration or just turn on emitter pin of QTR?

I am not sure which particular examples you are referring to, but none of our examples use an additional external LED for calibration, and I would not expect to need anything like that. I suspect the code is referring to the emitter on the sensor, but it could also be using the LED built onto the microcontroller just to indicate to the user when it is calibrating.


Hi if I want to use 3v Vcc , what do I need to do to the qtr sensors?

You would just need to short the 3.3V bypass pins together and power it from a 3.3V source, as mentioned on the QTR-8A product page. The 3.3V bypass pins are indicated in the silkscreen on the back of the board.


So can I change back to 5v since I am using 3.3v?

In general, you probably want to use the sensor at 3.3V if you are using a 3.3V microcontroller. If your microcontroller uses 5V signals, then you should probably just use it at 5V.

If that does not answer your question, can you give me more information about what you are trying to do?


How is qtr dealing dashed line course. Since I put a special condition such as position ==0 or each sensor value comparison for meet white space then go forward but it doesn’t work properly with PID. It will drive straight out in the black line follow and lost line in dashed line.

You will probably want to break away from your normal PID control while you are not on the line. So the logic would be something like:

Detect that the line has disappeared.
Break away from your PID control
Drive straight while checking the sensors for the line.
Go back to PID control when the line has been found.

A condition of position==0 is probably not the most reliable way to detect that the line has disappeared, since the readLine() function remembers where it last saw the line (e.g. if sensor 4 is your rightmost sensor and you end up completely off the line to the left, this function will continue to return 4000). Instead, you could check the calibrated values in the array you passing the readLine() function to check each sensor and see if they are all seeing white. More suggestions can be found in my posts in this thread.


I am using QTR8A. I want to determine 90 and 45 degrees sharp turn and run my specific turn function but it will affect to normal sharp round routine. Is it just using previous position to help in the conditions checking?

And the other question is the setpoint is 3500 but when it run with pid the robot not run smoothly. It is keep doing setpoint Left right correction. However I have set between 3000to4000 is error 0, does this make sense?

If you want separate sharp turn functions for 90°, 45°, and rounded turns, you will need some way to decipher which turn you are encountering. You might be able to use the previous position like you mentioned or look at the individual sensor values or some combination of both.

It sounds like you are forcing the error value to be 0 when the readLine() function is between 3000 and 4000 (e.g. the line is between the 4th and 5th sensors). I would expect this to result in a lot of sharp movements and not run very smoothly. Is there a reason you are forcing such a large deadband like that? I expect it would be much smoother to let the error simply be the position minus the set point if you tune the PID coefficients appropriately.


Because the black line width is under sensor 4 and 5, if I set 3500setpoint there is errors count between 3250~3850 with Pd 35,35 so my robot motor is keep Left right tuning.It does not drive steady , it makes the robot never drive smooth. Is there any way to fix it if I using 3500 setpoint because I have small and hard course must the robot drive smooth.

Below is videos with my setpoint set 3000-4000

It isn’t clear to me what you are trying to describe with the error and the setpoint, but I do not have any more advice about it than I gave in my previous posts. Also, it is not clear to me what behavior you are trying to point out in those videos as problematic. In general, it looks like you are using a very advanced line following course with many different obstacles (e.g. dashed lines, sharp turns, crossing lines) that you will need to figure out how to handle yourself. You might even consider starting with an easier course and introducing those more advanced obstacles one at a time.