<< return to Pixycam.com

Why do i observe different behavior on different pixy2 using same configuration?

Pixy Software
#1

Hello,

I would like to continue on this discussion, to better explain the underlying story.

This is the procedure we use to prepare a pixy2 camera:

  1. connect in pixyMon. display live stream
  2. File > Restaure defaults parameters => pixy reboots (black screen, then video stream is back after a few secs) => params have been reset
  3. File > Load Pixy Parameters > select “parametres_pixy_prod.prm”

here a link towards the configuration file => https://gist.githubusercontent.com/alexisdal/c2711395d75f4dbf97ef8de09efac57d/raw/5756b749fa45b83a59b124d84711e3d9cc6917c2/parametres_pixy_prod.prm

We used the “save settings” feature precisely to have a very simple pixy2 preparation procedure. So the settings are the same among cameras.

We track the number of times the pixy has “lost the line”. We recently observed that one AGV in particular (more recently built than another one) would have much poorer line_loss statistics and we do not understand why. We first suspected motoring issues (because wheels would produce a funny sound in curves), we swapped them => to no avail. same issues.

Then we tried to swap the pixy2 for an older one we bought about 1year ago (fw 3.0.11 instead of 3.0.13 with a pixy2 we bought a few months ago) => the “funny sound in curves” issue is not entirely gone but the line_loss statistics is MUCH better.

In order to better understand the situation, i tried to make a simple diagnostics procedure

  1. put the AGV on bricks (a few centimers above the ground so that the wheels do not touch the floor)
  2. output the value of linePosition = (int16_t)pixy.line.vectors->m_x1 - (int16_t)X_CENTER (at 62fps more or less, with #define X_CENTER (pixy.frameWidth/2)
  3. slowly manually move the paper line below the camera from left to right back and forth
  4. graph data

image
image.png1617×381 20.3 KB

=> this with the older AGV that works just fine. the line is smooth, the motoring sound too. all ok

image
image.png2922×452 71.6 KB

=> this is the problematic AGV (before swapping the pixy2). there are moments when the line_vector seems to flicker a lot (but while i have the very same paper line in my hands and same lighting conditions => i know it’s not moving crazy this from one frame to the next like the data says). I believe this explains the motor sound issues (rapid changes of velocity targets)

Knowing that both cameras have same configuration (see link above) but different fw version => what can possibly cause this behavior?

#2

Hello,
One of the significant changes between these firmware versions is support for variable framerate, and the ‘min frames per second’ parameter.

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:pixymon_index#camera-tab

Can you try reducing this to 50 and see what happens?

Edward

#3

I will test this soon.

but i think I may have nailed the issue (but i’m no so sure yet)

some background info: my AGV is some sort of a 2WD system where both the wheels and the pixy2 are attached to a rotating head to allow for sharp U turns of the line on the floor. For the moment, I have not implemented a PID for the navigation because i did not need it in the previous hardware revision (where the wheel were attached to the main chassis without any rotating head and without any U turn on the line). I merely measure the distance between the center of the pixy frame and the x1 value of the line vector (the error) => then give motor instructions directly proportional to this error. Therefore you can think of it as a PID without I and D.

This “P-only-PID” results in significant oscillation when the line makes sharp turns => but as long as the AGV follows the line, it’s fine.

Those rapid changes of velocity requests, with the backlash in the mecanichal reduction in the wheels => creates vibrations => which then make the pixy2 vibrates => which makes the images blurry/shaky => which makes the line still going the same direction but much sorter or longer from one frame to the next => which makes x1 change very rapidly

See this video at from 1:40 to 2:00 => https://drive.google.com/file/d/1aJYCWTgGJdwJvryeT_B1xzyTm82g1REE/view
(it’s recorded with VLC at 30fps, not 60fps)
4 consecutive frames in that video make the issue particularly visible (see extracted images below)

in summary, it seems vibrations create vibrations

I’m guessing that the pixy2 has a rolling shutter (and not a global shutter) to save costs, it’s likely to be sensitive to vibrations.

I will later implement a tuned PID controller + filter x1 (make a sliding average of the last 2~3 frames)
=> so that i have less chances to produce vibrations (and resist better too)

However, assuming the pixy2 is used on a potentially vibrating situation:
What pix2 configuration would help get a still functionning line following algorithm despite the vibrations?

image
image.jpg365×1164 103 KB

#4

Hello,
Rolling shutter is probably not the issue. The issue looks like simple motion blur. Motion blur happens with motion (of course), but it gets worse with longer exposure times. So you have some choices to reduce the blur – (1) Move slower and (2) use brighter lighting.

Consider option (2). The brighter lighting reduces the exposure time… Are you using Pixy2’s lamp? If not, you should definitely enable it. If you’re already enabling it, you should consider augmenting Pixy2’s lamp with another LED source to brighten what Pixy2 sees evne more. It will improve the motion blur.

Hope this helps!

Edward

#5

yes i’m already using pixy2 built LED. that makes the AGV runs with lights completely shut off by the way :slight_smile:

i solved this issue by filtering the x1 values (sliding average of the last 4 values) + throttling the acceleration of motors.

I thik adding ruber washes around the pixy2 board mounting holes + measure the Nm while tightening the screws may help as well. I suspect the different level of torque while mounting/unmounting the pixy might have influenced the behavior in the first place anyway

I think I will even improve the behavior by better tweaking my navigation PID logic (right now there’s only an untuned P => it would help to have some D + tune the whole thing)

once it all stabilizes, i will upgrade all pixy2 to the latest fw 3.0.14 and see what happens.

#6

Hello,
Your application sounds really interesting. Do you mind posting a picture? :slight_smile:

Edward

#7

agv_preview_mtb01

i know pixy2 is supposed to be used for toys or for education.

but…

we noticed it just works, so why bother :smiley:

1 Like
#8

Agreed! Pixy should have no problem with this application :slight_smile: You should contact our sales ([email protected]) if you want to order Pixy2 in quantity and get quantity pricing.

Thanks for sharing!

Edward