Programmers: I Have A Challenge For You

[davidthefat]

Well I delivered this message in the team meeting today, went pretty well, but I think Im the only one still that wants full sutonomous

[davidthefat]

Originally Posted by theprgramerdude

In terms of processing power, I was already thinking about how to overcome the (ironic) limits of the Crio. Back in '07, a team was planning on attacing a full computer to their robot to do calculations. I was thinking like-wise for this project.

My current idea is as follows. It would involve a DC-DC converter connected to the PD board, which could then plug straight into the ATX connector on a motherboard. Example:http://www.mini-box.com/M4-ATX?sc=8&category=981
A proccesor would then handle several inputs from various sensors that the Crio can't handle. A CUDA-based GPGPU would be able to handle most calculations from the cameras such as pattern recognition and positioning.

What do you think?

Back to the 10,000 Lakes Regional as my team needs the current Auton code done.

Edit: and IMHO, I believe Java would be a horrible language to create a fully autonomous robot, as it's slowness and inefficiences would handicap even the best system. It's why I chose to use C++ this year again.

What I was thinking, a microprocessor takes care of the individual stuff, like multi threading, but with robots hardware

[Greg McKaskle]

The underlying vision for Java, C++, and LV are all thin wrappers calling into the same binary. While the languages have different capabilities and different runtime features, as long as you are using NI-IMAQ via the WPI libraries, the vision performance isn't due to a language choice.

Greg McKaskle

[Dancin103]

I must say, if I ever saw this I would be amazed. It would be awesome. BTW this is my 340th post. Go GRR.

[theprgramerdude]

Originally Posted by Alan Anderson

What break are you referring to?

An FRC-members schedule:
January-February: Nonstop work on robot
March-April: Competitions and Nationals
May-December: Intermittent workload until next season. <-8 month break

[davidthefat]

Is there any rules on limiting the number of extra microprocessors the robot may have? Was thinking of uing like 2 or 3 extra microcontrollers to help the cRio

[The Lucas]

Originally Posted by davidthefat

Is there any rules on limiting the number of extra microprocessors the robot may have? Was thinking of uing like 2 or 3 extra microcontrollers to help the cRio

Many rules limiting how they are used. Particularly <R03> regarding custom circuits and all cost accounting rules. Also additional non KOP motors rules and power sources rules if you are thinking of using a laptop. Of course if you want to see how deep the rabbit-hole goes

[gvarndell]

Originally Posted by theprgramerdude

My current idea is as follows. It would involve a DC-DC converter connected to the PD board, which could then plug straight into the ATX connector on a motherboard. Example:http://www.mini-box.com/M4-ATX?sc=8&category=981
A proccesor would then handle several inputs from various sensors that the Crio can't handle. A CUDA-based GPGPU would be able to handle most calculations from the cameras such as pattern recognition and positioning.

What do you think?

As my 5 year old son often says -- and then what?

Figuring out how to power a PC motherboard on a robot gets you nothing but added weight and battery drain.
You're gonna have to take this idea to a higher plane if you want anyone to get excited about it.

My point is not to squelch your obvious enthusiasm, but engineers generally don't design solutions and then look for a problem that it solves.

Pretend that you've just read a product announcement:

Late summer 2010, BeastlyRoboVision Inc. will be offering a self-contained robot vision module. The module will cost around $900.00. It will be capable of tracking up to 16 (relatively large) objects out to a distance of 100 feet, with a 360 degree field of view. The module interfaces to any robot control system via 10 Gbit wired network interface, providing a low latency, high bandwidth, TCP/IP connection. FIRST has already approved this module for use in the 2011 FRC robots and NI has promised a 10 Gbit ethernet module for the cRio to be available by late summer.

Now, some of you set out to design and build that vision module, and some of you set out to design a robot that can make good use of it.

[gblake]

As long as your definition of a "fully autonomous" robot consists of something on the order of simply finding a game piece and kicking it in the direction of a goal you at least have a chance to be successful. Many of this year's and previous year's robots already do that in autonomous, no big deal to run it for an additional 2 minutes.

How about if they define success as Inspiring and Recognizing Science and Technology excellence? I'm going to bet many folks will want to line up behind that goal!

However, don't expect your robot to do very well in competition. A game designed for completely autonomous robots like FIRST TECH CHALLENGE or FIRST LEGO LEAGUE is much simpler than the games FIRST designs for their top level of competition.

How about if they use this as a tool in competing to earn FIRST's top level of competition's top award? - The Chairman's award.

Remember that you are part of an alliance. Your inability to co-operate with your teammates to maximize each robot's potential would be the equivalent of a football player running whatever play he feels like without co-operating with the rest of the team. Don't expect it to work very well.

I think many FIRST FRC teams invest their time and resources across many fronts, and thast building a "best" robot is only one of them. Almost certainly this reduces their robots' abilities to play the game well (but generally makes them better FIRST teams). Are you saying that investing in any goal that distracts significantly from building and improving the robot should be discouraged?

Using this year's game for an example, how do you in intend to determine whether your robot should be going after a ball or blocking an opposing robot? How do you decide when to come over the bump into the front zone and assist in scoring? How do you decide when to come over the bump into the front zone and block the opposing alliance's blocker bot so your striker can score? How do you know if your alliance partner has moved to the middle and you need to move to the far zone to clear balls from it? If you do decide to block an opposing robot, how do you know it's not dead and you're wasting your time on it? How do you know that your alliance's striker bot is broken down and you need to move forward and score? How do you know both your alliance mates are on their back and you need to flip one back upright to have a chance to get past their blocker bot and score (this happened to us in the semi-finals, we won the game 2-1: http://www.thebluealliance.net/tbatv...2010la_sf2m2)?

A fully autonomous robot-system can have an interface between itself and the rest of the game participants. For example a human sensor in the driver's station can listen to instructions given by allies and can transfer them to the cRIO part of the system. To keep the project's intent intact these instructions should probably be distilled into a relatively small set of pre-defined messages.

These are just some of the decisions I've made as field coach on our team this year. They're all pretty straight forward and simple, but impossible to make without an overview of the game situation. I'd be interested to hear how you intend to implement any kind of awareness of the tactical situation into your robot. You can pre-program a game plan into it, but without an overall awareness of the game, you'll discover the truth of an old saying that's proved itself through the years: "No plan survives contact with the enemy".

See previous paragraph, and notice that the folks haven't decided to try to create a fully autonomous alliance (yet). They are discussing creating a fully autonomous robot.

I think it's great to inspire people to work towards fully autonomous robots, just don't lose sight of reality. Many of your teammates will probably want to do at least reasonably well at their competions. In the real world, your robot will be a liability to it's alliance.

Perhaps. Or perhaps it will be a huge asset to the program, and all teams in it, because it becomes tangible evidence that FIRST is highly successful; and the resulting robot(s) consequently become an excellent inspirational tool.

Blake
PS: I haven't forgotten that this would/will be a very hard job. Nor have I changed my mind about spending more than one season helping a dedicated group of students eat this elephant one bite a time.

[tsa256]

I agree, the processing is a very debilitating bottleneck. We've debated some solutions such as other processors and ran into the same problems discussed above. I think the way to combat would be to find the best combination of processing and plausibility of it actually working. As stated above you could strap a computer on the robot but not only does a CUDA processor pull massive power, upwards of 400 watts if I remember correctly; and as for getting useful information out of the mother bored would be a challenge. Also probability of a mother bored not cracking is slim to none. Although I'm unfamiliar with this new camera module I think that may be the way to do it. I'm planning on researching it in depth as soon as I can.

And as discussed above, the amount of field combinations is practically infinite. Maybe the way to go at this problem would be to be to use the AI to execute a small task within the game. Just like the ability to activate camera tracking in teleop this year, I agree we should aim for the best possible AI, but as stated that's a massive task. As a software developer and with experience from working with my drive team I believe this would be a valuable asset. It would take a lot of processing off the cRIO, and allow the coach to process the entire field, then rely to the drivers to press a button to execute the proper function.

[Alan Anderson]

Originally Posted by theprgramerdude

An FRC-members schedule:
January-February: Nonstop work on robot
March-April: Competitions and Nationals
May-December: Intermittent workload until next season. <-8 month break

You don't go to offseason competitions or hold training sessions?

[45Auto]

How about if they define success as Inspiring and Recognizing Science and Technology excellence? I'm going to bet many folks will want to line up behind that goal!

Sounds good to me! I thought that was the definition of FIRST anyway, no matter what degree of technical challenge a team attempted.

How about if they use this as a tool in competing to earn FIRST's top level of competition's top award? - The Chairman's award.

Nothing wrong with that. It'll definitely teach them science, engineering, and technology skills!

I think many FIRST FRC teams invest their time and resources across many fronts, and thast building a "best" robot is only one of them. Almost certainly this reduces their robots' abilities to play the game well (but generally makes them better FIRST teams). Are you saying that investing in any goal that distracts significantly from building and improving the robot should be discouraged?

Don't think I said that. You wouldn't consider full-autonomous as part of building and improving the robot? I would.

A fully autonomous robot-system can have an interface between itself and the rest of the game participants. For example a human sensor in the driver's station can listen to instructions given by allies and can transfer them to the cRIO part of the system. To keep the project's intent intact these instructions should probably be distilled into a relatively small set of pre-defined messages.

It appears that we have a big disconnect on what "fully-autonomous" means. My definition is more in line with the online dictionaries and Wikipedia:

A fully autonomous robot has the ability to

- Gain information about the environment.
- Work for an extended period without human intervention.
- Move either all or part of itself throughout its operating environment without human assistance.
- Avoid situations that are harmful to people, property, or itself unless those are part of its design specifications.

Not sure what your "human sensors" are (voice recognition or real people pressing buttons in the loop?) but in either case, it's still human intervention.

See previous paragraph, and notice that the folks haven't decided to try to create a fully autonomous alliance (yet). They are discussing creating a fully autonomous robot.

Which is exactly what I was pointing out. Their fully autonomous robot won't have any interaction with their team mates. Maybe that's the new definition of "co-opertition"! No problem if that's what they want, just think about all the ramifications.

Or perhaps it will be a huge asset to the program, and all teams in it, because it becomes tangible evidence that FIRST is highly successful; and the resulting robot(s) consequently become an excellent inspirational tool.

Does "highly succesful" mean "uses the highest technology"? I always considered "highly succesful" to mean inspiring young people to be science and technology leaders, by engaging them in exciting mentor-based programs that build science, engineering and technology skills, that inspire innovation, and that foster well-rounded life capabilities including self-confidence, communication, and leadership.

It is a fact of life that not all kids are interested in the programming side of FIRST. Nothing wrong with that, and nothing wrong with the programmers doing everything they can. Some kids are more interested in the mechanical aspects, some are more interested in the robotic competition aspects. Doesn't FRC still stand for FIRST ROBOTICS COMPETITION ? Nothing wrong with a team sacrificing their competitiveness to demonstrate their programming skills, just make sure that's what the team wants. My personal viewpoint is that sacrificing everything else about FIRST to emphasive a team's programming skills may not be in the best interests of FIRST or the rest of the team.

[gvarndell]

Originally Posted by 45Auto

A fully autonomous robot has the ability to

- Gain information about the environment.
- Work for an extended period without human intervention.
- Move either all or part of itself throughout its operating environment without human assistance.
- Avoid situations that are harmful to people, property, or itself unless those are part of its design specifications.

When the operating environment is sufficiently constrained, and the time period is limited to 2 minutes, and the actions a robot can initiate are adequately limited, this is a much less daunting problem.
It's still big, no doubt.
But please consider that, for some of these kids, the typical team's 'make the robot so I can drive it' programming is about as challenging as putting Legos together or 'paint by numbers'.
Personally, I only hope this initiative isn't a flash in the pan.

[ideasrule]

For people who are interested in this, take a look at the autonomous programs on Spirit, Opportunity, and MSL. They have 20, 20, and 200 MHz processors respectively, running vxWorks, the same operating system that's on the cRIO. They also operate in a much simpler environment than FRC. These robots give a good idea of what vision processing is capable of.

[davidthefat]

Wish me luck, Im gonna order the ATmega640 and get all the parts from radio shack and put it all together during spring break... Hope I don't fry anything