VEX Camera...

So I’m wondering whether or not VEX is going to release a camera…

I know that any electronics are legal for college teams, but it seems like some high-school teams are hitting a wall with programming, and I was wondering if VEX would possibly consider making the camera legal?

Possibly create a partnership with some company, and make something to allow the advanced programmers an additional tool to use? (camera recognition is a really cool idea!!)

Here’s some links for cameras that could be possibly used? Maybe just legalize the wire connection and power set JUST for a certain camera?

http://www.vexrobotics.com/276-2211.html
http://www.cmucam.org/wiki/WikiStart
[http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=78

Thanks in advance!](http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=78)

I saw STMicroelectronics at World working on a camera for VEX… I can’t remember if it was just “compatible” or if it was going to be a legal part. I’m pretty sure it was going to be legal. Also, the timeline was ~1-2 years.
Andrew

There’s plenty for advanced programmers to do in VRC. As far as I can tell, there are no autonomous modes in VRC which react to defense. Even the best code in VRC becomes apparently worthless when you ram it. I think programmers should start working on that.

Unless you avoid the ram with a second autonomous mode. This is what Josh/Titan/1103 did, and two of our teams did this as well. Usually our robot was fast enough to nab the goal before a ramming robot could get to us, but sometimes it was not so if we saw a faster-looking robot we could always back away first and go somewhere else.

Also this year it doesn’t seem like ramming will be a big thing. First of all Isolations robots and second the goals are spread around – not really causing teams to go to the same one most of the time, either. One place I see problems is where the two 20" Goals in the Isolations Zones meet. Teams will be reaching over and entanglement may happen. If one robot tries to back away from that it could possibly flip over or something else bad may happen.

~Jordan

In FRC in 2008, I saw a wonderful autonomous mode that self-corrected for being pushed off course. That might be a good place to start.

Going further, maybe you could write a program that attempts to drive around an unexpected obstacle, using the gyro.

You could even detect this object coming towards you using Ultrasonic Sensors. :wink: As long as your robot is holonomic (or perhaps just fast enough) you could almost avoid it completely.

~Jordan

While I do appreciate all of the ideas y’all are coming up with, most, if not all of that has been done…

For college, it’s easy. We can have all the sensors we want, and I’ve been working on code and logic for just about everything y’all talked about…

I was hoping VEX might have something for some of the really advanced programmers/teams… (using advanced codes, that will take advantage of the power the Cortex offers…)

Our team had 12 different autonomous modes (not including mirrors for different colours) at worlds to try and counter a variety of different strategies, but we still couldn’t avoid being rammed. However, a relevant Gateway rule is the one that says that if your robot enters their starting tile then you lose your doubler and negation barrels. Most ramming in autonomous occurs where one team pretty much points their robot at their opponents and drives forward at full speed - doing this without entering their starting tile will be harder and teams may not want to risk losing their special barrels.

Our team is also looking at implementing a camera some how for colour detection, but in the mean time you can use a normal Vex light sensor and some lighting gels (or other transparent colored material) to detect the difference between red and blue. I know that joe and other experienced guys will already know that, just saying it in case there are people who haven’t seen it implemented yet.

Perhaps you could make a unified list of all the ideas, and whether they have been done or not yet done, by others, and then by you (with a link to share your code). If your point of mentioning “has been done” is to look only for things that are new, then this list will help you keep from duplicating “done”; (Not that you wouldn’t learn a lot by duplicating or improving on tasks known to be possible.)
Here is my list of things observed to be undone (or unposted) on the forum, feel free to correct me:

  • a gyro routine that actually works to report current heading
  • an accelerometer integration routine that reports the current X,Y position and velocity vector.
  • a “zero drivers” fully autonomous routine for driver-controlled portion
  • a PID drivebase control routine that adjusts the motor power to get the wheel encoder speed to match the joystick position (rather than just the usual scaling of joystick position into motor power)

Whenever I hear “easy, you can do anything you want”, I have learned it means the same as “I haven’t put any thought or effort into it, so I don’t have any idea what might work”

It would be great if you can share your code and current progress. That way novices can get an idea of what can be done, and your peers can ask questions, and point out easier/more advanced/alternate ways to do the same thing, and future employers can evaluate your potential.

Reading between the lines back up in the thread, it appears that “something” refers to an advanced sensor legal for Highschool, that requires a lot of CPU power from the Cortex. The usual problem is that the Vex Cortex has no high-bandwidth IO ports. The CMU-cam, for example, does all its own processing of image data, and only needs IO for control and direction of blob results.
I’m not sure what the “using advanced codes” is in reference to, can you explain? Jordan has posted some of the most advanced RobotC code here, and he seems to think he has room for improvement (and has a good tutor available in the family, apparently).