<< return to Pixycam.com

UART connected -> many errors: cs error, reorder

Pixy Software
#1

I need help to error messages and the reasons over it.

My first test connected Pixy over SPI header to Arduino MEGA - my test program runs perfect without errors.
But I need an UART communication with the MEGA board Serial #1 with 19200 baud an I use the last (Juni 6.) UART Library.

My test program with 1 sec.delay get blocks forever.
Between correct blocks I get many “cs error” and “reorder” errors - example:

Objekt=rechts - Hoehe okay
Objekt=Mitte - Hoehe ??
Objekt=Mitte - Hoehe ??
cs error
cs error
reorder
reorder
reorder
reorder
reorder
Objekt=Mitte - Hoehe ??
Objekt=Mitte - Hoehe ??

Please who can help for this problem?
Rainer

#2

I wonder if this problem is arising due to the long 1 second delay. Try removing the delay and see if you continue to get errors.

Scott

#3

Thanks Scott,

yes the delay has influence of the counts of errors - no delay, no errors occurs.
Why? - I think the call >pixy.getBlocks()< is “static” and waits for the next pixy block.

Here my simple Arduino loop (isn’t complete):


PixyUART pixy_info;

void loop()
{ 
      blocks = pixy_info.getBlocks();

      if (blocks) {
          objectSize = pixy_info.blocks[0].width * pixy_info.blocks[0].height;
          if(objectSize > 500) {
             pixy_info.blocks[0].print(); //infos about the object
         }else{ 
           Serial.println(" Obj to small");
         }
         delay(1000);
       }else{ ..... }      // obj lost 
   
}//loop end

My robot program has an timer/scheduler and calls the pixy (get blocks) each 1000 msec for driving course correction.

I can change the loop timer from 1000 to 100 msec - I get errors.
Only the loop timer = 0 no errors are generated.
But this is not possible by my program.
It is very pity that I can not use PIXY

Rainer

#4

I was having the same problem. I fixed it by editing TPixy.h. I commented the following lines:
126
141
206
207

After commenting these lines, I get consistently good results regardless of the delay length.

#5

I was having the same problem. I fixed it by editing TPixy.h. I commented the following lines:
126
141
206
207

After commenting these lines, I get consistently good results regardless of the delay length.

#6

Thanks Bit Head

for your information.

Please confirm the line numbers in my TPixy.h for same content.

#126 = return false;
#141 = link.getByte(); //resync
#206 = Serial.println(“cs error”);
#207 = empty line … commenting is not necessary

Thanks for short replay - is correct?

Rainer

#7

Sorry, @Rainer, I may have made some other edits that shifted the row numbers. I should have been more specific:

#126 = return false;
#141 = Serial.println(“reorder”);
#206 = else
#207 = Serial.println(“cs error”);

#8

Okay - makes sense now …

but

  • commenting (delete) the error massages is not the actual problem.
  • delete #126 (return false) must have a look for importance.

Yet many thanks for your helps to this problem.

Rainer

#9

Quick update: I discovered that commenting row #126 as suggested above causes the code to wait when no blocks are found. This caused my whole app to halt and wait for a block to appear before proceeding which is not what I wanted. After some additional testing, I now have this code in its place:

  iCount++;
  if (iCount >= 100)
 return false;

This allows me to filter out almost all of the false failed reads without blocking the code. I had to fine tune the if statement to match the platform. An Uno is a less powerful processor and can use a lower value, while the Due is a more powerful processor and needs the ‘100’ value I have above.

#10

Thanks for the info.

My problem with the errors which I first described, occurs even though I have a stable color object (50x50 cm) in about 2 meter distance from pixy5.
Camera and object are static and not moved. The delay time (eg 100-1000msec) between the getBlock Calls assesses the number of error messages.

Your change no longer shows me this errors. But the errors are still produced. I have counted this errors (internal) and they are no less.

Here is something fundamentally not okay.
Because the getBlock calls for a static camera object situation must always found this blocks - without error messages.

Or there is also a problem of UART Syncronisation. I check my UART connections and test with a faster processor.

Rainer