FRC Blogged - The 2015 Control System Request for Proposa

[Tom Bottiglieri]

They are also looking for 60ish laptops to support the Kinect station.

Did we already know this?

[BigJ]

Originally Posted by Tom Bottiglieri

They are also looking for 60ish laptops to support the Kinect station.

Did we already know this?

It was said (by Bill?) that we should practice our Kinect over the summer because it would be "more important" next season.

(Kinect doesn't even play video games well )

[Dkt01]

Originally Posted by BigJ

(Kinect doesn't even play video games well )

Maybe this research could be beneficial. I haven't tested it, but preliminary results are fascinating.

[DonRotolo]

Originally Posted by Jon Stratis

Does this mean it would be integrated into the robot controller?

No, I didn't read it like that. "Support" does not equal "integrated".

Originally Posted by Jon Stratis

In other words, we could end up with a control system that doesn't support current languages.

Yes, in theory, but what other languages are there? A company promoting their product using some obscure language (FORTRAN 77?) isn't going to see a lot of business. Reality is, you will know at least one of the languages. (And if not, you learn. Like real life)

Originally Posted by Jon Stratis

How would an integrated solution work? For example, can you imagine the design challenge if the radio was integrated into the cRio?

No, I am having a difficult time imagining that. Seems trivial to me, but that may be just me...

Originally Posted by IndySam

Things like this must be done with a limited committee of dedicated individuals.

Absolutely, and I truly hope they don't get all transparent on us in this case.

[rsisk]

Originally Posted by DonRotolo

... A company promoting their product using some obscure language (FORTRAN 77?) isn't going to see a lot of business.

And what is wrong with FORTRAN? My first programming language was FORTRAN IV

[ebarker]

Before there was National Instruments, with their fancy cRIO system for test and automation ..... There was the HP1000, a real time test and automation system that ran ... yes, you guessed it... FORTRAN

HP1000

Yes indeed, FORTRAN on the 1000 predated NI and the cRIO.

[skimoose]

Originally Posted by ebarker

Before there was National Instruments, with their fancy cRIO system for test and automation ..... There was the HP1000, a real time test and automation system that ran ... yes, you guessed it... FORTRAN

HP1000

Yes indeed, FORTRAN on the 1000 predated NI and the cRIO.

Oh, come on if we're going to go to tried and true systems, I vote for my first imbedded experience. An 8080 with numeric keypad programmed in hex and managing a 2K memory stack. Or my first closed loop feedback system on an analog computer programmed with jumpers.

[IndySam]

This thread has officially jumped the shark!

the old guy shark

[techhelpbb]

Originally Posted by IndySam

This thread has officially jumped the shark!

the old guy shark

Hey I'd love to see new features that go beyond that RFQ that people want.

Let's see who can think out side of that box (hopefully within the galaxy).

BTW: I'm only 36 but I've been told I'm going on 80.

[Andy Baker]

Originally Posted by techhelpbb

Hey I'd love to see new features that go beyond that RFQ that people want.

I'd love to see a simple, robust system that connects quickly and dependably.

Andy

[techhelpbb]

Originally Posted by Andy Baker

I'd love to see a simple, robust system that connects quickly and dependably.

Andy

Let's frame that:

Simple as in all in one piece with no room for wiring error or simple as in connect these wires here...here...and there?

In the current system the connect time is determined more by the D-Link robot AP and field than the cRIO. Point being: where is the line between the control system and accessories that FIRST provides?

To elaborate if someone makes a system that can boot, connect, and be ready to run in < 15 seconds. Then a user comes along with say a laptop and that takes 1.25 minutes to boot added to it is that an issue for the control system developer, FIRST or the user?

What about the amount of time to upload software into the control system?

Just curious.

[Billfred]

Originally Posted by techhelpbb

Let's frame that:

Simple as in all in one piece with no room for wiring error or simple as in connect these wires here...here...and there?

In the current system the connect time is determined more by the D-Link robot AP and field than the cRIO. Point being: where is the line between the control system and accessories that FIRST provides?

To elaborate if someone makes a system that can boot, connect, and be ready to run in < 15 seconds. Then a user comes along with say a laptop and that takes 1.25 minutes to boot added to it is that an issue for the control system developer, FIRST or the user?

What about the amount of time to upload software into the control system?

Just curious.

I can't speak for Andy, but to me, the benchmark of "a simple, robust system that connects quickly and dependably" remains the 2008 control system (with the 2005-2006 breaker panel). The cRIO era has had some pluses, but you can't beat opening the package, wiring the robot, turning it on at the breaker and being able to drive three seconds later. (You'll notice I didn't say anything about imaging, setting IP addresses, or even downloading some user code.)

I'm not married to the IFI system, but it is my point of reference on things related to (re-)connection speed and simplicity.

[BigJ]

Originally Posted by Dkt01

Maybe this research could be beneficial. I haven't tested it, but preliminary results are fascinating.

Sorry, let me rephrase. Most game developers at this point are not using Kinect very well. I am not sure if this is a limit of their time and budget or of the Kinect technology. However I have a hard time believing that a lot of FRC teams can do better with Kinect than the developers of a AAA video game (Steel Battalion).

http://www.theverge.com/gaming/2012/...y-armor-review (Might have strong language, I didn't re-read it too closely)

Although Steel Battalion has a bunch of problems aside from the Kinect control, the Kinect controls it is using are relatively simple and apparently fail to work well enough for that stuff.

Not to say that some developers aren't using Kinect well (see Double Fine's Happy Action Theater/Sequel): http://www.giantbomb.com/quick-look-...equel/17-6467/ (This one most likely does have strong language but I did not re-watch it)

Notice that the Happy Action Sequel mostly just uses detection to paint things on the scene and record the players.

Again, it's one of those things that is possible, but unless the bonus is VERY high, most teams will use that time to improve their in-robot autonomous, or spend more time in driver practice. If the bonus is very high, then you have the high disparity between teams who could get it to work and have enough experience, and those that couldn't.

Rereading your post, I think you probably weren't trying to refute me or anything, but after compiling the post I figure this is good information for everyone to see anyway.

[Hjelstrom]

Probably the main problem is that the Kinect has enough latency to make it not very suitable for direct control of a robot (e.g. using your arms as the joysticks). Games have the same problem. The games that seem to work best are the ones where you are mimicing an action rather than directly controlling something. Kinect will probably be utilized nicely in a game design like 2008 where you can choose between specific goals or tasks.

I'm excited to see USB support being considered for the robot controller (lets get kinects on the robots!) and I still think there is value to doing vision on the robot.

Originally Posted by BigJ

Sorry, let me rephrase. Most game developers at this point are not using Kinect very well. I am not sure if this is a limit of their time and budget or of the Kinect technology. However I have a hard time believing that a lot of FRC teams can do better with Kinect than the developers of a AAA video game (Steel Battalion).

http://www.theverge.com/gaming/2012/...y-armor-review (Might have strong language, I didn't re-read it too closely)

Although Steel Battalion has a bunch of problems aside from the Kinect control, the Kinect controls it is using are relatively simple and apparently fail to work well enough for that stuff.

Not to say that some developers aren't using Kinect well (see Double Fine's Happy Action Theater/Sequel): http://www.giantbomb.com/quick-look-...equel/17-6467/ (This one most likely does have strong language but I did not re-watch it)

Notice that the Happy Action Sequel mostly just uses detection to paint things on the scene and record the players.

Again, it's one of those things that is possible, but unless the bonus is VERY high, most teams will use that time to improve their in-robot autonomous, or spend more time in driver practice. If the bonus is very high, then you have the high disparity between teams who could get it to work and have enough experience, and those that couldn't.

Rereading your post, I think you probably weren't trying to refute me or anything, but after compiling the post I figure this is good information for everyone to see anyway.

[techhelpbb]

Originally Posted by Hjelstrom

I'm excited to see USB support being considered for the robot controller (lets get kinects on the robots!) and I still think there is value to doing vision on the robot.

Under the COTS rules you can put a laptop with it's own battery on the robot. That laptop could connect to a Kinect right now. You don't even have to run Windows there is work underway for Linux. It really doesn't differ in any way from the way the existing fields connect to the Kinect.

The issue with adding Kinect to just any USB Host, even if it has the hardware, is that you need the software for it. If you have say OpenEmbedded running you can get drivers. However, then you're back to robbing CPU time from the rest of the control system to process video. Also there are usually compromises made to reduce the resources of Linux to make it fit into a smaller package. For example uCLinux which doesn't need a memory controller. You still get something that is basically Linux but what do you compromise on in the process?

I guess it comes down to how bad do you want a PC on your robot before it just makes more sense to put a PC on your robot?