Pixy2 line following issue

skye · December 13, 2018, 9:33pm

I am using the pixy2 for line following. I call the getAllfeatures routine and get the structure filled out with all the data. I use the coordinate for vector[0] as the error for my PID loop. This all works fine for a simple track.

Now my code calls the setNextTurn routine when it sees an intersection. If a bar code is present at the same time the barcode is visible, I use +90 degrees as the argument, else I set it to 0. From what I have read, this should cause the “Vector” Pixy picks to either be the turn or the go straight line segment after the intersection.

But what I find is that as soon as I call the setNextTurn routine, all the data in the pixy.line structure seems to be all set to zero. When that happens, suddenly my PID loop thinks it is far to the right of the line and makes a hard left turn. It turns hard enough to not see the intersection but still see the main line and then it corrects by making a hard right turn.

Can anyone verify that pixy.line.vectors structure gets clears on calls to setNextTurn? And perhaps the developers have a solution for this behavior or at least an explanation? I am presenting this sensor to a robot group meeting on Sunday and would love to provide some explanation!

edge · December 14, 2018, 10:03pm

Hello Skye,
Why are you using getAllFeatures instead of getMainFeatures? getAllFeatures doesn’t do tracking of the main vector, but just returns all lines, which your program needs to determine which is the main vector.

Unless you have a special need (it doesn’t sound like it), use getMainFeatures instead.

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:line_api

The line_zumo_demo is a good reference:

github.com

charmedlabs/pixy2/blob/master/src/host/arduino/libraries/Pixy2/examples/line_zumo_demo/line_zumo_demo.ino

//
// begin license header
//
// This file is part of Pixy CMUcam5 or "Pixy" for short
//
// All Pixy source code is provided under the terms of the
// GNU General Public License v2 (http://www.gnu.org/licenses/gpl-2.0.html).
// Those wishing to use Pixy source code, software and/or
// technologies under different licensing terms should contact us at
// [email protected]. Such licensing terms are available for
// all portions of the Pixy codebase presented here.
//
// end license header
//

#include <Pixy2.h>
#include <PIDLoop.h>
#include <ZumoMotors.h>
#include <ZumoBuzzer.h>

This file has been truncated. show original

Edward

skye · December 15, 2018, 6:19pm

Interesting. I was using the GetAllFeatures because I tend to like to see as much information as possible. Once I figure out what I need, then I might reduce the amount I ask for.

I am very confused. I have been running my Arduino code while watching what it is doing via the USB PixyMon application. When usge the GetAllFeatures, I see Pixy selecting the new vector at intersections base on the default or what I asked for a turnAngle. I am surprised to hear that getAllFeatures does not provide line tracking. That is not my experience.

I have looked at the Zuma sample code and patterned my code of of it. The zuma code follow the far end of the vector. This has the effect of the robot cutting corners rather than following the line tightly. For a track with tight curves this can cause chaos as when taking corners it can start to see other parts of the track and get very confused. Poor thing.

The downside of following the close end of the vector comes when you come to an intersection with branches at 90 degrees. Pixy seems to (mostly) pick the right branch based of the angle requested. But the ‘near’ end of the new vector is still centered in the image. The robot drives straight till the branch at 90 degrees goes of the image and Pixy is force to pick the straight through line as it is the only one visible. I am now trying a hybrid. Pick the close end of the line if intersections are not visible and the far end if they are. We will see.

I have found that on numerous occasions, I have had the PixyMon display indicate me a picture with two lines. the “vector” in red mostly centered on the screen and a small line going off to the right at the bottom of the image in a different color. When dumping the contents of the pixy.line.vectors array the [0] item is for the small line. Somehow what is getting reported to the cabel to the Arduino is not the same as being displayed on PixyMon. This seems perhaps to happen mostly after intersections.

So using GetAllFeatures I still see:

The pixy.line.vector array getting nuked.
At times the [0] vector in the array over the cable does not match the video annotations on PixyMon.

Still need to figure out a better algorithm for following the near end of the line but not missing intersections. And somehow we think we are going to let cars drive us around on pedestrian filled roads, in bad weather?

skye · December 15, 2018, 7:10pm

Here is an example of what I am talking about when PixyMon and the vector data seem to be out of sync.
The image:

The data for each vector and intersection
Vec-0,51,51,49,30,0x00
Vec-1,49,30,00,29,0x00
Vec-2,78,31,49,30,0x00
Vec-3,49,30,46,00,0x00
Int-0,49,30,04

My code assumes the “Primary Vector” is the [0] element of the array. Here the [0] element is the line segment from the bottom of the screen to the intersection. This appears to be the old “primary vector”. But the PixyMon image shows that it has already determined the new vector to be the one from the intersection to the right edge of the screen.
Since my robot is following the [0] element, it will continue to drive straight (the line is in the center of the scree) till the right branch drops off the image.

The comment earlier that getMainFeatures does not do line tracking I think to be in error. From all the experiments I have run it seems to very much do line tracking. If I could figure out the issue with Picy not reporting the correct vector, I think I would be set.

edge · December 17, 2018, 5:28pm

Hello Skye,
I’m a little confused as well I must admit.

getAllFeatures will return all detected lines. The first line (vector) it returns is not special; it is just one of the lines that’s detected. You can refer to a vector’s index number if you wish to determine correspondence between frames. You may be doing this already.

If Pixy2 detects an intersection and then changes its Main Vector (the one indicated by the red arrow in PixyMon), the list of vectors getAllFeatures returns will not necessarily change. You will still get a list of vectors, in no particular order.

The Main Vector isn’t given any special treatment through getAllFeatures, which is why getAllFeatures is considered an advanced API function. It leaves your program to determine which vector it wants to choose as the Main Vector (the one you wish to use for navigation, etc.)

So, getMainFeatures is preferred because is greatly simplifies things – you just get the Main Vector. And when a turn is made, the Main Vector changes. Why do you need to use getAllFeatures?

Edward

david14 · December 27, 2018, 1:05pm

Hello,
I want to use Pixy2 for line following. The Pixy2 works fine, but I am new to Arduino and have some trouble knowing how to make the Pixy 2 interact with the Dc motors.
The project is a robot that is supposed to follow the black lines.
I would be so gratefull if someone could help me.

edge · December 28, 2018, 3:05am

Hello David,
Have you considered using a Zumo base?

https://docs.pixycam.com/wiki/doku.php?id=wiki:v2:pixy_zumo_howto

Edward

david14 · December 28, 2018, 12:17pm

Hello Edward,
And first of all thanks for your advice.
But the problem, is that I have already assembled a kit, that does not use a zumo motor base.
I am using a Elegoo robot car v.3.0. So, if you got any clue on how to make Pixy2 interact with the DC motors, I would really much aprecciate it.

edge · December 28, 2018, 3:57pm

Hello David,
I don’t have any experience with the Elegoo robot car, sorry.

david14 · December 30, 2018, 12:20am

Okay thank you anyway, I will experiment with something new.