CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Choosing Microcontrollers
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Oct 16, 2022 8:35 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Oct 16, 2022 9:18 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Oct 16, 2022 10:08 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Oct 16, 2022 10:12 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Mon Oct 17, 2022 5:48 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Mon Oct 17, 2022 12:09 pm     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Oct 17, 2022 3:49 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Oct 18, 2022 8:15 pm     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Wed Oct 19, 2022 1:03 am     Reply with quote

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: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Oct 19, 2022 4:49 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:33 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:36 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 4:22 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Sat Oct 22, 2022 10:07 pm     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Oct 23, 2022 6:25 pm     Reply with quote

It is in the Code library.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group