| View previous topic :: View next topic |
| Author |
Message |
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
 Posted: Sun Oct 16, 2022 8:35 am |
 |
|
re: | Quote: | | do you know why they usually use a row of 5/7 TCRT5000 to do the line tracking task? |
Makes a simple 35 pixel camera ! Very fast to read (5 bytes of data..)
one possible reason is that when all 35 sensors are read, you get a rough 'picture' of the line.
Say ONLY the center column of 7 are on... the line is straight.....
Now, depending on which sensors are on in the 5 by 7 matrix, you can create an 'algorithm' to control the rate of change to turn the vehicle to 'follow the line' as well as actual ground speed. |
|
 |
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Sun Oct 16, 2022 9:18 am |
|
|
| Quote: |
makes a simple 35 pixel camera ! Very fast to read (5 bytes of data..)
one possible reason is that when all 35 sensors are read, you get a rough 'picture' of the line.
|
I checked those sensors. It is not an array of them, just 5 or 7 in a line. Every one of them has a digital output. Didn't check if the logic is positive or negative, but it doesn't matter. What matters is that the line apparently needs to be either black on white or white on black, at least those few project I saw used that setup.
Interfacing should be super easy. Read the sensors in I don't know, 100ms intervals, check if the outer sensors read differently than the middle ones, correct course if not. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sun Oct 16, 2022 10:08 am |
|
|
getting old sux..I misread the post..
ok, so a single row of 5 sensors.....
read each sensor, compare to calibration data, brightest reading should indicate relative 'left----center---right' of the vehicle.
7 sensors if space same as 5, would give better resolution. |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Sun Oct 16, 2022 10:12 am |
|
|
| Correction. Outputs seem to be analog. But I'm a bit confused. Some sites say digital, some analog. So I ordered myself a pair of those to see who is right :-) |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Mon Oct 17, 2022 5:48 am |
|
|
I don't consider a line sensor, to be a 'camera'. To me a camera implies
some form of image, so needs either repeated use of a line sensor against
time, or multiple lines. The definition of 'camera' is a 'device for recording
images'.
On the output, these are simple photo-transistors, so 'analog'. However
if setup with the correct illumination levels and loads, they can be used
as a 'switch' output, when a light surface is seen.
A line sensor like this is a much simpler device to use than a 'camera', except
when smart devices that have already been mentioned are involved. |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Mon Oct 17, 2022 12:09 pm |
|
|
| Those that I order show only the top side of the board. But on the other picture there is a schematics with a 74HC14 (Schmitt trigger input inverter) connected to collectors of those transistors and routed to outputs. Let's see what the postman brings. For me, it would be better analog, because that way threshold for each sensor could be set in software to compensate for the differences among sensors and also for different contrasts between "line" and "not line". |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 17, 2022 3:49 pm |
|
|
I had a quick look and found some 8 bit line sensors that have BOTH analog and digital outputs. Using the analog would allow for smoother line tracking, digital could light LEDs to show 'rough' position of the vehicle.
The basic problem with using a multi-megapixel camera as a line sensor is it needs a tremendous amount of hardware and software to get the vehicle to follow the white line while the simple 5 pixel 'line sensor' can do it for a couple bucks and less than 100 lines of code. |
|
|
ThanhDan
Joined: 07 Jun 2022
Posts: 19
|
|
| Posted: Tue Oct 18, 2022 8:15 pm |
|
|
| Ttelmah wrote: | Think about it. Even a tiny picture will be perhaps 192*128 pixels. Even
in B&W, one byte per pixel. Needs then 24576 bytes to hold just a single
frame. The 877 has 192 bytes.....
Even if you have no different grey scales, just a single pixel on/off, a frame
still needs 3072 bytes. Sixteen times what the chip has. |
I see... well the 877 has 368 bytes for its RAM/program memory but still too little for the picture at hand. What surprises me even more is how much more memory a small ATmega328 with 28 pins have than the 40 pins PIC. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Wed Oct 19, 2022 1:03 am |
|
|
This is a key to understand about the different 'nature' of microcontrollers.
The PIC stands for 'Peripheral Interface Controller'. It is _not_ a general
microcontroller. It was built to be a simple chip for handling the basic
tasks needed to interface 'peripherals'. Doing I/O tasks very efficiently,
but not general 'computing' tasks. As such only handling a small amount
of data at a time.
So the PIC is ideal for perhaps interfacing a printer, or controlling peripherals,
but is not good for things like image capture or computing tasks.
The phrase 'horses for courses' applies here.
Now the range has 'grown', so you have chips like the DsPIC's, which still
have 'PIC' in their name, but have megabytes of computing space, hardware
multiply (and in some cases divide), DMA, and operate at speeds that the
early PIC's could never consider, which 'blur' the distinction between the
basic IO controller target of the early PIC's, and general microcontrollers,
but when you are looking at basic chips like the 877 you are looking at
standard PIC's not these later units. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Wed Oct 19, 2022 4:49 pm |
|
|
kinda curious..... does that pixycamera have a set of commands ( like Hayes modems ) that you can use or do YOU have to make the entire 'driver' for it ??
If the 'command set' is built in, then a much smaller PIC should be able to be used as the 'grunt work' IS being done in the camera module. |
|
|
ThanhDan
Joined: 07 Jun 2022
Posts: 19
|
|
| Posted: Thu Oct 20, 2022 12:33 am |
|
|
| Ttelmah wrote: | This is a key to understand about the different 'nature' of microcontrollers.
The PIC stands for 'Peripheral Interface Controller'. It is _not_ a general
microcontroller. It was built to be a simple chip for handling the basic
tasks needed to interface 'peripherals'. Doing I/O tasks very efficiently,
but not general 'computing' tasks. As such only handling a small amount
of data at a time.
So the PIC is ideal for perhaps interfacing a printer, or controlling peripherals,
but is not good for things like image capture or computing tasks.
The phrase 'horses for courses' applies here.
Now the range has 'grown', so you have chips like the DsPIC's, which still
have 'PIC' in their name, but have megabytes of computing space, hardware
multiply (and in some cases divide), DMA, and operate at speeds that the
early PIC's could never consider, which 'blur' the distinction between the
basic IO controller target of the early PIC's, and general microcontrollers,
but when you are looking at basic chips like the 877 you are looking at
standard PIC's not these later units. |
Thanks, I got it, it has been an eye - opener. |
|
|
ThanhDan
Joined: 07 Jun 2022
Posts: 19
|
|
| Posted: Thu Oct 20, 2022 12:36 am |
|
|
| temtronic wrote: | kinda curious..... does that pixycamera have a set of commands ( like Hayes modems ) that you can use or do YOU have to make the entire 'driver' for it ??
If the 'command set' is built in, then a much smaller PIC should be able to be used as the 'grunt work' IS being done in the camera module. |
Well I don't work directly with the camera, my teammate does, but I believe that the image processing is done within the camera module with a predefined set of commands. Regardless, from our discussion, I think an ATmega328 or something with RAM to spare is the way to go... |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Thu Oct 20, 2022 4:22 am |
|
|
| Quote: |
ATmega328 or something with RAM to spare
|
2kB of RAM is not much, far from it when it comes to pictures. Pixy2 uses NXP LPC4330, an ARM Cortex-M4 based chip. It has up to 264kB of RAM, 204MHz clock, etc. In other words, a beast. They put it there because obviously such power and speed are needed to work with such a data intensive peripheral. My opinion is that it is far easier to connect to such a smart device and simply query it for information than it is to try and handle image yourself.
As far as I saw, Pixy2 doesn't exactly have a set of commands like AT, but it does have "values" that have to be sent to it for a certain task and description of expected answers. Like this:
sendPacket / requests sent to Pixy2
Byte Description Value(s)
0 - 1 16-bit sync 174, 193 (0xc1ae)
2 Type of packet (varies)
3 Length of payload in bytes (len) (varies)
4 - len Variable length payload (varies) |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Sat Oct 22, 2022 10:07 pm |
|
|
| One of those grudge projects. I actually have a directory under "PIC_Projects" named this way. In there there are some things I did only from a reason that I hated Arduino guys (and kudos to them) for being able to interface with everything from a much lesser IDE. To the point. I had a very long conversation with my Pixy2 today. After all the initial errors I made and corrected, it responded to the specification. On UART, While it was sending a picture via USB at 60 fps. A line follower program is due in like two days. |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 480
Location: Montenegro
|
|
| Posted: Sun Oct 23, 2022 6:25 pm |
|
|
| It is in the Code library. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
