paper: Team 341 Vision System Code

[Ziv]

This is really cool! I'm looking forward to taking a close look at this at a non-12AM time, but a quick skim left me hungry for more.

We used a much more primitive system to find targets. After even very lenient RGB thresholding, we found that ignoring small particles and filtering the remaining ones for high normalized moment of inertia was sufficient. However, we didn't use any measurements other than the x coordinate of the center of the targets. Your code will no doubt be studied by a great many people, hopefully including all of 125's trainee programmers .

[hodgepodge]

It's great to see how others approached the vision processing. I wrote the vision code for team 118 this year and from a quick glance, your algorithm is quite similar.

Our code ran onboard on a BeagleBone running Linux and straight OpenCV, written in C++. libCurl was used to capture images and a UDP socket spewed angle and distance data to the cRio.

[BradAMiller]

Jared -

Thanks so much for posting your code. It was good meeting you at the regional and amazing watching your teams robot do it's stuff. This will go a long way to helping teams learn about computer vision processing and raise the bar for future competitions. Expect to see better documentation and improvements for next season.

And thanks to Joe Grinstead and Greg Granito for helping develop the code over last summer at WPI. They did a great job with the camera code and network tables extensions to WPILib.

Brad

[sebflippers]

Thanks for the code. I believe lines 322-334:

private double boundAngle0to360Degrees(double angle)
    {
        // Naive algorithm
        while(angle >= 360.0)
        {
            angle -= 360.0;
        }
        while(angle < 0.0)
        {
            angle += 360.0;
        }
        return angle;
    }

could be replaced with

private double boundAngle0to360Degrees(double angle)
    {
        return(abs(angle)%360.0);
    }

[Ziv]

Originally Posted by sebflippers

Thanks for the code. I believe lines 322-334 [snipped] could be replaced with

private double boundAngle0to360Degrees(double angle)
    {
        return(abs(angle)%360.0);
    }

Consider the angle -90. Daisy's code returns 270, but yours returns 90. I think you're looking for something more like this:

private double boundAngle0to360Degrees(double angle)
    {
        double ret = abs(angle)%360.0;
        if(angle < 0.0)
        {
            ret = -ret;
        }
        return(ret);
    }

[sebflippers]

Originally Posted by Ziv

Consider the angle -90. Daisy's code returns 270, but yours returns 90. I think you're looking for something more like this:

private double boundAngle0to360Degrees(double angle)
    {
        double ret = abs(angle)%360.0;
        if(angle < 0.0)
        {
            ret = -ret;
        }
        return(ret);
    }

right.

[sebflippers]

done. This one kind of defeats the purpose of making your code simpler, though.

	public static double boundAngle0to360Degrees(double angle)
    {
        return(angle > 0.0? angle % 360.0 : 360.0*(1 + (Math.abs((int)angle)/360))+angle);
    }

[Gray Adams]

Originally Posted by sebflippers

done. This one kind of defeats the purpose of making your code simpler, though.

	public static double boundAngle0to360Degrees(double angle)
    {
        return(angle > 0.0? angle % 360.0 : 360.0*(1 + (Math.abs((int)angle)/360))+angle);
    }

Why not just...

 public static double boundAngle0to360Degrees(double angle)
    {
        return((angle+360)%360);
    }

[Jared Russell]

Originally Posted by Gray Adams

Why not just...

 public static double boundAngle0to360Degrees(double angle)
    {
        return((angle+360)%360);
    }

What if angle is equal to -361?

It's awesome that you guys are analyzing the code and you have already taught me something new (that Java's "%" operator works on floating point values...as a primarily C++ guy, I have it burned into my brain that thou shalt use "fmod" for floating point modulus). But if this is the part of the code that engenders the most discussion, then I'm a bit disappointed

[Gray Adams]

Originally Posted by Jared341

What if angle is equal to -361?

It's awesome that you guys are analyzing the code and you have already taught me something new (that Java's "%" operator works on floating point values...as a primarily C++ guy, I have it burned into my brain that thou shalt use "fmod" for floating point modulus). But if this is the part of the code that engenders the most discussion, then I'm a bit disappointed

Ok, fine.

return(((angle%360)+360)%360);

[AlexD744]

I feel like at this point the original code was easier to understand from an outside perspective.

On another note, this is AWESOME! It's nice to see another team using Java to program, especially when it's done so well. Our camera tracking system is currently only used in auton to track after grabbing the third ball off the co-op bridge. It's very rudimentary code so that it can be run on the cRio (we had issues with a bad camera that made it impossible to test any sort of laptop based vision code). This is very interesting, and I'm excited to go over it in more detail later.

[Tom Bottiglieri]

Thanks for posting this, Jared. I took a look at your dashboard on the field at Champs and was very impressed. It seems incredibly useful to have the vision system draw its idea of target state on top of the real image.

I suspect if vision is a part of upcoming games, we will probably use a solution very similar to this. This year we wrote all of our vision code on top of WPILib/NIVision to run on the cRIO. In the end we got this to work pretty well, but development and debugging was a bit of a pain compared to your system.

[JamesTerm]

Originally Posted by Jared341

What if angle is equal to -361?

It's awesome that you guys are analyzing the code and you have already taught me something new (that Java's "%" operator works on floating point values...as a primarily C++ guy, I have it burned into my brain that thou shalt use "fmod" for floating point modulus). But if this is the part of the code that engenders the most discussion, then I'm a bit disappointed

Doh! I missed this before I responded as it was on the 2nd tab...

While I'm here though... if you are a c++ guy why use Java? Is it because it was the only way to interface with the dashboard? I gave up when trying to figure out how to do that in wind river.

[Jared Russell]

Originally Posted by JamesTerm

Doh! I missed this before I responded as it was on the 2nd tab...

While I'm here though... if you are a c++ guy why use Java? Is it because it was the only way to interface with the dashboard? I gave up when trying to figure out how to do that in wind river.

Easy, it's because I am not the only person who writes software for our team! Java is what is taught to our AP CS students, and is a lot friendlier to our students (in that it is a lot harder to accidentally shoot yourself in the foot). I also have a lot of training in Java (and still use it on a nearly daily basis), even if C++ is my bread and butter.

[JamesTerm]

Originally Posted by Jared341

Easy, it's because I am not the only person who writes software for our team! Java is what is taught to our AP CS students, and is a lot friendlier to our students (in that it is a lot harder to accidentally shoot yourself in the foot).

Ah ok.

Originally Posted by Jared341

But if this is the part of the code that engenders the most discussion, then I'm a bit disappointed

Don't be disappointed... this discussion has taught/reminded us something that we rarely use in c++, and this discussion indirectly helped my co-worker fix a bug today. I do know how you feel though as there is a *lot* of effort that goes into this! I had most-all my vision code written as well, and unfortunately it is all going straight into the bit bucket, as we could not get the deliverables to make it work in time. I do want to look your code over in more detail and post what I did as well, and hopefully at that time the discussion will have more meat in it as I do want some closure in the work that I have done thus far.

I will reveal one piece now with this video:
http://www.termstech.com/files/RR_LockingDemo2.mp4

When I first saw the original video, it screamed high saturation levels of red and blue on the alliance colors, and this turns out to be true. The advantage is that there is a larger line to track at a higher point as I could use particle detection alone. The goal then was to interpret the line to perspective and use that to determine my location on the field. From the location I had everything I needed as I then go to an array table error correction grid with linear interpolation from one point to the next. (The grid among other tweaks are written in LUA more on that later too).

more to come...

There is one question that I would like to throw out there now though... Does anyone at all work with UYVY color space (a.k.a YPbPr). We work with this natively at NewTek, and it would be nice to see who else does.