Team 254 Presents: CheesyVision

[Kevin Sheridan]

Originally Posted by Michael Hill

We actually just put on a banner sensor at the last competition, but made it slightly rotatable so we just moved the sensor. Our drive team was able to consistently find the target in about 10 seconds. Maybe it was your placement/mount of the sensor that made you guys take a while?

It takes a while because we have to position 3 robots and 2 sensors

[Brandon Zalinsky]

I absolutely love the simplicity and out-of-the-box thinking in this hot goal tracking system. I was thinking about it, though, and wondered to myself how it's legal. I checked the rules, and according to G16, it's legal:

During AUTO, TEAM members in the ALLIANCE STATION must remain behind the STARTING LINE and may not contact the OPERATOR CONSOLE.

But I then looked at the definition of AUTO and was a little more confused.

AUTO (aka Autonomous): the first ten (10) seconds of the MATCH in which ROBOTS operate without direct DRIVER control.

It's pretty clear that the LRI's have ruled it legal, as 254 has gotten inspected, kicked butt, and won many times with it. I figured that CheesyVision was pretty much direct control, so how is it legal?

Again, good job, 254 does it again.

[BigJ]

I think the rules themselves do not disallow it, but Q431 and Q446 further clarify the use of non-contact communication in the driver station during autonomous mode.

[AustinH]

Completely missed out on the chance to call it "Hot or Not". Just saying

[JamesTerm]

Originally Posted by billbo911

It uses FAR LESS BW than a camera on the robot sending video TO the DS.
It only sends 1 byte every 25ms. The flow if FROM the DS to the cRio.

If the processing was done on the cRio, then the FTA would have a point, but it is not. All processing is done on the DS and only one byte is sent. How the cRio uses that byte is up to the team.

The idea of sending one byte every 25ms by itself cannot be assumed to be low bandwidth unless it is sent with favorable options in the socket setup.

I was surprised to find how much bandwidth can acrue using UDP and the DO_NOT_WAIT option with a similar test of sending two doubles every 33ms. In short I took out the DO_NOT_WAIT and the bandwidth went down significantly.

[Jared Russell]

Originally Posted by seg9585

Wouldn't it be easier just to hold up a light or large board of a specific color to discern between the two?
Basically we are just concerned about answering a boolean question here. As in: "Is the left goal hot?" If no, don't hold up the board/light and assume the right goal is hot. If yes, hold up your indicator.

In our case, there are three states we are interested in:

Neither goal hot
Left goal hot
Right goal hot

The "neither" state is useful because you can watch for the transition from neither to one of the other states to indicate that the goal has flipped. This requires 2 bits of information to discern, hence separate left and right boxes. Other use-cases may not need the third state and could only use one detection area.

[Tottanka]

Originally Posted by Brandon Zalinsky

I absolutely love the simplicity and out-of-the-box thinking in this hot goal tracking system. I was thinking about it, though, and wondered to myself how it's legal. I checked the rules, and according to G16, it's legal:



But I then looked at the definition of AUTO and was a little more confused.



It's pretty clear that the LRI's have ruled it legal, as 254 has gotten inspected, kicked butt, and won many times with it. I figured that CheesyVision was pretty much direct control, so how is it legal?

Again, good job, 254 does it again.

Your second quote doesnt refer to a direct rule, but to a more general statement - which is not a rule.
There are also a few Q&A making it legal.

[JamesTerm]

Originally Posted by billbo911

I LOVE IT!!
This year 2073 used a USB webcam on our bot to track the balls. It was implemented to assist the driver with alignment to balls when they were obstructed from his view or just too far away to easily line up.

Originally Posted by seg9585

Cool -- we actually did the same thing, and fed back to the driver station which balls were detected in the field of view, and also their distance + offset angle from our collector.

Did it work something like this?

[JamesTerm]

Originally Posted by Jared Russell

Like many teams this season, Team 254 was surprised when we got to our first competition and found out that the Hot Goal vision targets

Wow! this thread has so many interesting posts in it... now on team 254 using python... wow I'll want to chat up with you on the language choice at some point... and wow what a clever out of the box idea... kudos to you guys, and to quote one of our engineers... "That is a great idea and they are real champs for sharing".

And the final wow goes to all the rules breakdown of what we *can* do... just think of the possibilities... heak why not voice commands (tell alliances mates to be quite hehe).

[billbo911]

Originally Posted by JamesTerm

Did it work something like this?

I would prefer not to hijack this thread, but here is a short description of what we did. If you would like to discuss this further, please PM me or maybe I can create a new thread.

Yes and no. We never feed video back to the driver. We just used the value of "x center" of the ball to steer the robot whenever the driver needed assistance. One button on the steering wheel overrode the wheel position and replaced it with the "((image x center - ball x center value) * k)". "k" was a gain value used to bring the error value to a useful level to steer the robot.

All image acquisition and processing were done on a PCDuino on-board the robot. None of the network traffic for this crossed the WiFi network, it all stayed local to the robot.

[mototom]

Team 329 used a barcode scanner to decode a barcode which populated a field on the Smart Dashboard which indicated that we would shoot immediately (the goal you are looking at was now hot) or delayed for 5 seconds if no barcode was scanned.

No additional bandwidth, no camera, no additional processing, simple and effective.

[JamesTerm]

Originally Posted by billbo911

please PM me or maybe I can create a new thread.

I think this would be a great thread. It would be cool to know if any other teams tried it and are willing to share how they did it.

[DjParaNoize-]

#pewpew

[brennonbrimhall]

Thanks for sharing!

#veryvision #muchGP #wow

[s1900ahon]

Originally Posted by electrian21

2468 team appreciate used a system like this at Bayou last week. This never occurred to us - it's so simple and elegant.

Our version was developed by our students with contributions from Greg McKaskle. Written in LabVIEW using the vision libraries. Instead of recognizing hand position, it uses a sign our drivers carry with them. The sign is initially held at an angle (neutral position) and turned to a horizontal position to shoot.