Re: 2363 prototype pickup arm
 

This looks awesome. I can't wait to see the system integration

Re: 2363 prototype pickup arm
 

I gathered that. I was curious how the discs then exited the hopper, but I think I figured it out. The cylinder mounted on top of the wood board seems to be attached to a piece that will rotate and push out the discs.

It looks like the shooter platform can articulate to two angles based on the cylinders of the front of the robot. Can the hopper unload into the shooter at both angles? Or is one configuration simply for starting conditions?

Re: 2363 prototype pickup arm
 

The hopper can load at any angle, we are actually looking to add a 3rd angle to our arsenal.

Re: 2363 prototype pickup arm
 

I assume this robot is going to play heavily on the strategy of picking up missed frisbees around the pyramid and scoring them, which was the other major design philosophy that was discussed on 422.
Are we going to be seeing any vision targeting on the robot this year?

Re: 2363 prototype pickup arm
 

Great idea, but it doesn't look that sturdy. Does it buckle or bend if someone is pushing on the far corners? (imitating a defensive robot)

Re: 2363 prototype pickup arm
 

I believe the piston is attached to a cam.

Re: 2363 prototype pickup arm
 

Well, there is often a difference between what is planned and what actually works. I try not to discuss plans outside the team (much). With the CD community, I'd rather share actual demonstrated results.

Re: 2363 prototype pickup arm
 

Is the pickup arm as robust as we would like? Never. But if you don't expect something to be damaged, you shouldn't stick it out past your bumpers.

So, we plan for easy repair or replacement for when (not if) it gets damaged. That means making things light so we can bring lots of spares within the parts allowance, and designing for quick changeout of replacement parts.

For example, the pickup roller is the most vulnerable part of the arm. The shaft is going to get bent. So, the first line of repair is bending it back. The second is replacing it. We'll have a replacement assembly "on deck", which can be swapped out in about 30 seconds by removing two socket head cap screws. Then the bent shaft can be serviced (or replaced) at our leisure.

Of course, part of the equation is training the drivers not to drive around with the arm down when it's not necessary.

It's very similar to logomotion, in 2011. Then, we had a complete replacement gripper ready and waiting. Our drivers were good at protecting the arm, and we never suffered arm damage until the off season, when rookie drivers left the arm down and drove it into a wall.

Re: 2363 prototype pickup arm
 

Fair enough, I was just trying to casually reference the adventure that was vision targeting in VA last year with the scoreboards.

Re: 2363 prototype pickup arm
 

No kidding! The Jumbotrons of death.

At the beginning of the season, we relied far too much on our vision system for targeting. When we threw out that code and just let the drivers aim, we started doing much, much better. I hope that's a lesson that sticks.

Though I'm mechanical, not software, I've started paying attention to how the top teams use vision processing. The answer seems to be: they don't. My own conclusion is that vision processing in FIRST requires an extreme amount of resources better spent on other things. Then, even if you think you have it right, slight changes in lighting at the venues can flush all that hard work down the drain.

Re: 2363 prototype pickup arm
 

I'm curious if the vision code failed because the code was too simple and made too many assumptions or were the jumbotrons truly misleading? Do you have any images?

Greg McKaskle

Re: 2363 prototype pickup arm
 

Greg,
I think it was both.

The jumbotrons were positioned so they showed up in the camera field of view when the robots were on the key in the normal shooting location. Once we realized what was going on, we could see the turret obviously tracking the jumbotrons rather than the top goal. They were of an aspect ratio and apparent size that mimicked the expected shape and size of the top goal retroreflective tape box. Many teams at the Virginia regional had similar problems. At least one other team requested that the jumbotrons be turned off, but that request was denied. We started taking shots from way off to the side, so the screens were out of the FOV, and our shooting percentage went way up.

That said, I do think that more sophisticated software could have dealt with the problem. Ours tracked only a single square. I heard of others that tracked the three goals as a triangle and disregarded "out of place" boxes as extraneous. That level of sophistication might have helped a lot. Being a mechanical guy, it's just as easy for me to say, "Just make the software better," as it is for the software folks to say, "Just make a shooter that is always consistent." Easier said than done.

My lesson last year was that unless vision systems are developed and tested in something approaching the actual lighting conditions, they will likely be unreliable. Adaptive vision systems, while possible (as demonstrated by the numerous examples of autonomous cars), aren't a task that is easily doable by high school level software programmers in six weeks.

Re: 2363 prototype pickup arm
 

Thanks. I saw a number of teams who decided not to require the rectangle to be hollow and others who decided HSL was not needed, and did much looser color thresholding. While a bit faster, you are trading that for redundancy. I'd like to see how the example code dealt with the jumbotron of doom/death/annoyance.

All of these systems are making heavy assumptions in order to be more approachable by the intended audience, be it the flat carpet covered floor, or the precise dimensions of various elements on the field. Vision is typically not a game-changer, but I do think it can be a student-changer. If you see something that would make it more effective at that goal, please let me know.

Greg McKaskle

Re: 2363 prototype pickup arm
 

Greg,
I just asked our software mentor to stick his head in. Let's see if he has some more authoritative input.

Re: 2363 prototype pickup arm
 

What we did last year was use the JavaCV library to pull out the green channel and then anded that with the inverse of the red and blue channels. After that we did a ratio check on the height and width and did a polygon check to make sure the target was rectangular. We were then able to accurately calculate distances to targets back in the shop. But, unfortunately when we got to the competition the it didn't work as well as we had hoped. We actually had a problem with our software wanting to track the screens on the side of the field also, which actually caused us to burn out a motor at one point early on. On top of the two sets of screens causing us problems, the lighting conditions also changed between practice day and qualifications which caused us problems after having calibrated our camera on practice day. All in all, what we have learned from our experiences is that vision processing is great, when used to assist the driver in aiming and not doing it itself. We just ran into too many outside variables which caused us too many problems.