NI Week Athena Announcement and Q&A Panel

[Racer26]

Also, so far? the GDC has given us one game EVER that actually needed machine vision for an optimal Auto mode: 2007.

And even then, lots of teams had successful deadreckoned keeper autos.

Any time the target doesn't move after you've placed your bot, AND you can start your robot where you want, dead reckoning will work. If no interaction between red/blue robots is allowed, dead reckoning can't be defended.

2003 was the start of auto. You needed to be first to the top of that ramp.
2004 the target didn't move, but auto could be defended by cross field ramming.
2005 i didn't compete, and my memory is fuzzy, but was the first year we had the CMUcams. it was awful, as the targets were passive, and the arena lighting varied wildly.
2006, they switched to the green cold cathode boxes, which were much more reliable to detect, but the target didnt move, so no need to use them
2007, the rack moved after robots were placed, but typically didn't move a whole lot.
2008, the IR remote could be used to tell your robot where the balls were. most teams just dead reckoned.
2009, trying to dump in auto usually meant you got your own trailer beat up on by an HP
2010-2013 no game pieces, robots, or targets are moved before auto, AND red/blue interaction during auto is against the rules.

[magnets]

Originally Posted by Racer26

Also, so far? the GDC has given us one game EVER that actually needed machine vision for an optimal Auto mode: 2007.

And even then, lots of teams had successful deadreckoned keeper autos.

Any time the target doesn't move after you've placed your bot, AND you can start your robot where you want, dead reckoning will work. If no interaction between red/blue robots is allowed, dead reckoning can't be defended.

2003 was the start of auto. You needed to be first to the top of that ramp.
2004 the target didn't move, but auto could be defended by cross field ramming.
2005 i didn't compete, and my memory is fuzzy, but was the first year we had the CMUcams. it was awful, as the targets were passive, and the arena lighting varied wildly.
2006, they switched to the green cold cathode boxes, which were much more reliable to detect, but the target didnt move, so no need to use them
2007, the rack moved after robots were placed, but typically didn't move a whole lot.
2008, the IR remote could be used to tell your robot where the balls were. most teams just dead reckoned.
2009, trying to dump in auto usually meant you got your own trailer beat up on by an HP
2010-2013 no game pieces, robots, or targets are moved before auto, AND red/blue interaction during auto is against the rules.

This is a little inaccurate. You weren't always allowed to position your robot exactly where you wanted it so you couldn't be sure that your robot started in the same spot each time. In 2012, we needed vision in auto. Our strategy was to get to the center bridge and get the balls first, so we would be traveling very quickly when we hit the bridge, causing our robot to get misaligned. When we drove forward to the key again, we usually would be 2 to 3 feet away from where we started, and we needed the camera to line up with the target.

Also, many other teams have used vision as part of their main strategy. In 2006, wildstang had a nifty turret thing that was always pointed at the goal whenever it was in range so that they could get the balls in at any time. Also, 118 used a camera very well in 2012 with their shooter because it would let them shoot from anywhere near the key without having to line up.

The point is, for some games and some teams, vision is a huge part of the game.

I know teams used vision to line up for a full court shot this year, and teams also used vision to line up with the legs of the pyramid.

[Pault]

Originally Posted by Racer26

Also, so far? the GDC has given us one game EVER that actually needed machine vision for an optimal Auto mode: 2007.

And even then, lots of teams had successful deadreckoned keeper autos.

Any time the target doesn't move after you've placed your bot, AND you can start your robot where you want, dead reckoning will work. If no interaction between red/blue robots is allowed, dead reckoning can't be defended.

2003 was the start of auto. You needed to be first to the top of that ramp.
2004 the target didn't move, but auto could be defended by cross field ramming.
2005 i didn't compete, and my memory is fuzzy, but was the first year we had the CMUcams. it was awful, as the targets were passive, and the arena lighting varied wildly.
2006, they switched to the green cold cathode boxes, which were much more reliable to detect, but the target didnt move, so no need to use them
2007, the rack moved after robots were placed, but typically didn't move a whole lot.
2008, the IR remote could be used to tell your robot where the balls were. most teams just dead reckoned.
2009, trying to dump in auto usually meant you got your own trailer beat up on by an HP
2010-2013 no game pieces, robots, or targets are moved before auto, AND red/blue interaction during auto is against the rules.

Yes, but your looking at the past. And a lot of things can (and will) change by the year 2019. I dream of the day that FRC advances to the point where the GDC can make a game which nearly requires vision tracking for some high scoring oppurtunity. In 6 years, I highly doubt that we will get to the point where vision tracking is necessary to be competitive, but I would not be suprised if it becomes a near requirement for powerhouse teams. Heck, even in 2012 most of the top tier key shooters used vision tracking (341 and 1114 come to mind). And if FRC is going to lock into a control system for that long, they better be sure that it is going to be able to handle our growth and not hold us back.

My 2 cents.

[techhelpbb]

Originally Posted by Racer26

Also, so far? the GDC has given us one game EVER that actually needed machine vision for an optimal Auto mode: 2007.

I have to say I agree that trying to build machine vision into the control system of an FRC robot is asking quite a bit when so few people will fully dig into it. There is a difference between merely using it and really grabbing hold of it. It is not really the most effective reason to demand an upgrade every few years to an FRC system when the older robots and that investment then become that much harder to maintain.

Personally I think that a better way to handle video recognition is on the robot not at the driver's station with the current FRC environment and for this purpose I feel that an auxilary device to process that is the more sensible. It hardly makes sense to try to find something faster than a general purpose COTS PC for the price. The market for that general purpose PC is huge compared to FIRST so of course it will be the greater performance for the price and without question each year that price will buy even more performance as long as it is allowed. Plus if you break an old laptop I doubt you'll spend more for the older model. The other way is to integrate the camera with the video recognition system in the same package. I really look at the Raspberry Pi and other COTS systems (besides a general purpose PC) as something a little more like an attempt to integrate the camera and the video recognition system (rough I admit). (Not against the Raspberry Pi or anything like that as has been demonstrated elsewhere on the forum.)

In any case I think video recognition is one of those fantastic things that inspires people to think that the robot can adapt to it's environment based on sight. Most people start thinking of the way they see and imprint that on the robot. In so many ways the way humans use sight and the way a machine does are very different things. It is an ever evolving piece of technology. On the plus side that evolution drives jobs and innovation which I'm sure students would love to have. On the other hand video recognition is no PWM. There is a point at which you can implement PWM and there's no sense to try any harder. Video recognition has so many compromises there is always something to try and always a good opportunity to look at the robot as the vehicle and the camera / video recognition as a subsystem with ample opportunity for tinkering.

I am not sure it makes sense to sell the Apple product of FRC robot control systems. That model works great when people can afford to upgrade. Making those upgrades the entire control system seems a touch more expensive than necessary.

[magnets]

Originally Posted by AllenGregoryIV

I'm actually really surprised I haven't seen anyone push for a dual radio idea before. That just makes sense.

Dashboard and anything else noncritical can all be over wifi. It also allows us to continue to be able wirelessly program the robot as well, which is a big advantage over having to tether a serial cable like the old controllers.

All the control data for the robot could be sent over the IFI style radio, and they even make Axis Cameras with built in wi-fi.

On a separate note, the compile/download times are where I'm hoping to see some serious improvement. This year, we used our 2012 robot code (in LV) on the 2012 robot using 2013 LV libraries for testing. The time to deploy in debug mode was about 1 minute, and the time to compile and download was about 3 minutes.

The problem was when the cRIO got into its "unhappy" mode, where it would have trouble downloading code. One day when our programmer wasn't there, the cRIO got into "unhappy" mode, and the people their weren't familiar with the imaging tool. It took them over 2 hours to download one program to the robot. They tried everything, turning it on and off, copying/pasting into a new project, using a different laptop, but whenever they tried downloading, it would download very slowly. Eventually, they decided to try just letting it download for as long as it took, and it took them 27 minutes to download our code!

Compare this to Java, where FTP is used to transfer the compiled code. The compiling takes 10 seconds, the actual sending takes about 5 seconds, and the rest is just a cRIO reboot, most of which is the network stuff loading and the FPGA being set up. There's no reason why we can't see this performance with LV on the new system, maybe even better since the whole OS shouldn't need to be restarted when a new program is loaded. Linux is good a that sort of thing, you can do any os update/software/driver install without ever needing to restart the computer!


Although this bug has gone without a fix since 2009, I'm really hoping that they can fix this issue for the roboRIO.

[Greg McKaskle]

The long deploy times experienced last season have not been present since 2009. The were introduced when newer compiler and caching system were put into place. I've elaborated on the bugs in other posts and given known workarounds. There is no need to wait for a RoboRIO for bugs in the compile and deploy system to be fixed.

Greg McKaskle

[magnets]

Originally Posted by Greg McKaskle

The long deploy times experienced last season have not been present since 2009. The were introduced when newer compiler and caching system were put into place. I've elaborated on the bugs in other posts and given known workarounds. There is no need to wait for a RoboRIO for bugs in the compile and deploy system to be fixed.

Greg McKaskle

I'm sorry if my earlier post came off as being rude, I didn't mean it that way. See my opinion about roboRIO here.

I agree, there have always been ways to fix the deploying issues in LV, but they aren't always accessible to teams who aren't experienced programmers, or who aren't on CD. My only real negative experience with the current control system was in 09, when we couldn't LV to recognize our cRIO to download the code. We called over an FTA who was as puzzled as we were, and who told us to reimage the controller. He was right, it fixed the problem, but it took too long, resulting in us missing (and losing) our elim match. (looking back, we probably should have borrowed another cRIO!) Luckily, we won the next two and made it to the finals.

Since then, I've seen strange deployment issues every year on other team's robots, so I figured that when something like this happened to us, it was the same thing.

[Greg McKaskle]

There is no need to apologize. I didn't take your post as rude, but I felt that it was useful to separate roboRIO discussion from bugs that were unfortunately present in the LV development environment last year. I think it is easy for people to become confused when reading threads as scattered as this one has now become.

Greg McKaskle

[Tom Line]

Greg, is there any chance that NI is going to release the Thursday morning keynote video intro in high resolution?

That video was really neat, especially since the entire thing personafied FIRST.

I have a recording from my phone that is shakey and a Really Big Guy (tm) sitting in front of me blocked a portion of the screen.

http://www.youtube.com/watch?v=AOlHDrCNkuM

[Joe Ross]

Originally Posted by Tom Line

Greg, is there any chance that NI is going to release the Thursday morning keynote video intro in high resolution?

That video was really neat, especially since the entire thing personafied FIRST.

I have a recording from my phone that is shakey and a Really Big Guy (tm) sitting in front of me blocked a portion of the screen.

[urlOl]http://www.youtube.com/watch?v=AHDrCNkuM[/url]

Higher resolution then this? http://www.youtube.com/watch?v=tTdPZ4rKwLA

[Tom Line]

Originally Posted by Joe Ross

Higher resolution then this? http://www.youtube.com/watch?v=tTdPZ4rKwLA

Your link isn't working.

Before the keynote was a video sequence with music - that's what I'm looking for. Clicking on the link in my post works for me. That's strange. Here's a link to another video the intro sequence video:

http://www.youtube.com/watch?v=X9JmTvBtIew

You can also do a youtube search for "niweek intro video" on youtube and it will be the first result.

[Chris_Ely]

This might be what you are looking for.
http://www.youtube.com/watch?v=v74Hm_Y4cBc

[jhersh]

Originally Posted by Joe Ross

One thing that was nice on the DSC was there was enough space around the RSL pins to plug in a 3 pin PWM cable. Since teams have many PWM cables, it was easier then making a 2 pin cable. It's hard to tell from the pictures if there is space, but it would be nice if there was room for a 3 pin cable for the RSL.

Mechanical has taken this feedback and is incorporating it into Rev B.

[RyanCahoon]

Originally Posted by Tom Line

is there any chance that NI is going to release the Thursday morning keynote video intro in high resolution?

Originally Posted by luckof13

This might be what you are looking for.
http://www.youtube.com/watch?v=v74Hm_Y4cBc

Here's the one with the education theme: http://www.youtube.com/watch?v=d7g90QwbF3o. I suspect the graphics were rendered for their unique display screen form factor; they'd probably have to be redone for a standard rectangular video, if that's what you're looking for.

[Tom Line]

Originally Posted by RyanCahoon

Here's the one with the education theme: http://www.youtube.com/watch?v=d7g90QwbF3o. I suspect the graphics were rendered for their unique display screen form factor; they'd probably have to be redone for a standard rectangular video, if that's what you're looking for.

Thanks - that was it.