Programming dumbed down even more.

[Hypnotoad]

hardest thing for them was probably where to funnel all the darn money they got from preorders.

[Whippet]

If you're already done with your two-ball auto, ball-tracking catcher, and auto-aiming shooter, then perhaps it would be a good idea to program your robot to prepare and serve lunch in the pits as well. I, personally, am going to have a fun time getting our robot to launch consistently. YMMV.

Seriously, though: Engineers don't try to get things done in the easiest way possible. They get things done in the most effective way possible while complying with constraints. The lunar landings would never have happened if someone had said "This is too easy. Let's just skip the 'return him safely to Earth' part." Sure, they would have gotten a ship to the moon, bu it wouldn't have been effective.

Originally Posted by Hypnotoad

gee, they stuck it in a plastic casing. It must have been soooooo hard and taken sooooo long to invent and design a PLASTIC BOX TO HOLD COMPONENTS IN.

I'll be willing to bet that their first prototypes were not functional enough to warrant a fancy case. They had to iterate many times until they had a production ready device.

*inserts $0.02 into thread*

[bvisness]

Originally Posted by Hypnotoad

http://www.oculusvr.com/

Their first prototype was a phone screen with a lens, strap, and a gyro, accelerometer, and magnetometer strapped to it... All duct taped together.

Oculus is a fantastic example of a creative company. They blew everyone away with their original prototype (duct tape and all!) but they have continued to come up with creative ways to make their VR experience even more immersive. In fact, they're going to show off a new model with even more improvements (better head tracking, less latency, etc.) at CES this week.

And if you're stuck and don't know what to do with your code? Why not try teaching a new team member how your code works? Why not have them try coding an autonomous routine? Raging against the GDC this way isn't particularly effective, especially when you could be coming up with creative ways to help your team.

[mechanical_robot]

Originally Posted by Hypnotoad

gee, they stuck it in a plastic casing. It must have been soooooo hard and taken sooooo long to invent and design a PLASTIC BOX TO HOLD COMPONENTS IN.

You could say that about Apple then or really any company for that matter. What about their product. FIRST want you to expierement. What about that company you are talking about and their actual product they probably had to come up with something new right? The car was made to transport people easier. But there was a lot ingenuity to design the car. What about the highway/interstate system it was designed to transport people from point to point be very quickly. But there was a lot of engineering

If a company had your mindset about innovation especially a robotics or technology or car company then that company would collapse and probably wouldn't be bought out buy a bigger corporation. You're not getting my point.

[PriyankP]

Originally Posted by Hypnotoad

gee, they stuck it in a plastic casing. It must have been soooooo hard and taken sooooo long to invent and design a PLASTIC BOX TO HOLD COMPONENTS IN.

Based on your comments on how easy 2014 programming is, I'm going to be following your team closely to see what kind of amazing and 100% efficient system you design for your team's robot.

Also, can you provide a link to your website where you list all the easy inventions you've made?

[mechanical_robot]

Originally Posted by Whippet

If you're already done with your two-ball auto, ball-tracking catcher, and auto-aiming shooter, then perhaps it would be a good idea to program your robot to prepare and serve lunch in the pits as well. I, personally, am going to have a fun time getting our robot to launch consistently. YMMV.

Seriously, though: Engineers don't try to get things done in the easiest way possible. They get things done in the most effective way possible while complying with constraints. The lunar landings would never have happened if someone had said "This is too easy. Let's just skip the 'return him safely to Earth' part." Sure, they would have gotten a ship to the moon, bu it wouldn't have been effective.



I'll be willing to bet that their first prototypes were not functional enough to warrant a fancy case. They had to iterate many times until they had a production ready device.

*inserts $0.02 into thread*

I always love space race references during debates like these

[gluxon]

Wow, I'm kind of surprised at the amount of backlash here. I agree, the OP has the wrong attitude about creating solutions with programming, but I think the overall message was that the game is getting reliant on vision code specifically. I tend to agree with some points. Vision for Ultimate Ascent did not have to calculate for distance like Rebound Rumble did. And the large targets in Aerial Ascent allow a more talented driver to make up for poorer vision implementations (or so it looks; correct me if I'm wrong, I haven't looked at AA as much yet).

I'm also not worried and don't think this is a purposeful trend on FIRST's part. Just different games with different requirements.

Originally Posted by Mr. Lim

In 2012 we wrote hundreds of lines of code for CAN error recovery. This allowed our robot to run very reliably, and recover from nearly every CAN failure mode possible. I saw this as a far greater achievement than any of our camera vision tracking, which was quite good I might add. The CAN error recovery was way more important however.

I'm interested in this. I thought the point of CAN errors was to not have them electrically? Or am I thinking of the wrong thing?

[bvisness]

Originally Posted by gluxon

I'm also not worried and don't think this is a purposeful trend on FIRST's part. Just different games with different requirements.

I agree, although I think they may purposefully be making it easier so that rookies can get in on the autonomous action. (What else would the mobility bonus be for?)

[Kevin Selavko]

Originally Posted by faust1706

haha. funny how the left ball is an excercise ball. anyways. Yeah, we plan on finding velocity of a ball, and autonomously going to where it will go so we can retrieve it in the least amount of time. (this is will be used in autonomous to find and shoot teammate's balls in case they dont shoot.)

Tracking the hotzones and the targets will be pretty easy. There is plenty of documentation on tracking reflective tape and yellow leds.

Next, we are going to track a friendly robot, calculate their velocity, and then lead them in a pass so they will intercept the ball and they dont have to do anything but keep moving at their velocity.

Lastly, we are hoping for autonomous catching, but that is pushed back on our to do list because of the complexity and because a driver can do it fairly easily.

Thats going to be some good challenges for their programming team

[George Nishimura]

I actually can sympathise with OP. When I was a student, I was on the programming team, but as a mentor, I actually interact very little with the programming team, as they are well capable of handling it themselves and the priorities of the team are elsewhere.

I agree with him/her on these points:

1) The game recycles a lot of the challenges from last year. In addition, from a strategic point of view, many teams might (should) elect to only drive forward in autonomous, due to the rule changes this year. So autonomous (in my opinion the crown jewel of robotics programming) could be very limited.

2) Robotics programming is a subset of programming, and a lot of the challenges are very tied to hardware. That might not be your cup of tea. Or the team might not be able to provide the robot to make those challenges real/interesting.

3) Part of robotics is project and time management. Understanding your priorities is key. The simplest solution that meets your standard is the one that should be implemented, until all higher priority tasks are completed or you have the time to do it. So maybe it's not worth your time to improve your code, or find more innovative solutions. That's a personal/team decision depending on how you value your time/those solutions.

The solutions I can offer to you are:

1) Get involved in other aspects of the robot. A lot of our programmers prototype, build and do electronics, and used to do animation.

2) Get involved in other programming projects. They aren't part of the 'base' requirement for a team, but they can go a long way to making your team better. Scouting database, website, setting up better communication channels/workflow etc.

3) Work hard at making your code clean and well-designed. Considering how much code can be recycled every year, refactor your code to follow the right design principles to make it easy to maintain and build off of for subsequent years.

There are also things I disagree with OP about:

1) Robustness is important, and introducing more code to add robustness does not make your system more vulnerable and more likely to fail. 'Premature optimization is the root of all evil' is a valid warning, but error-handling/robustness are real problems in robotics that need to be solved, and are not 'premature'.

2) Attitude is important. FRC is not about 'winning things', it is a learning experience. There is plenty of code I/we have written that never made it to the robot for one reason or another. But writing that code is still valuable. 'Winning things' is only the motivation to keep people learning.

3) Don't deride the creativity of others.

[mrnoble]

Originally Posted by Hypnotoad

gee, they stuck it in a plastic casing. It must have been soooooo hard and taken sooooo long to invent and design a PLASTIC BOX TO HOLD COMPONENTS IN.

Losing rep points, sir. Are you feeling ok?

[Tom Line]

Originally Posted by Hypnotoad

A good programmer, or rather any engineer everl, solves a problem through the least effort possible. Transportation exists because someone somewhere decided to be lazy. machines, robots, every invention exists because of a lazy inventor. I am taking the lazy approach (which is still too complicated, I'll be thinking about how to make it even simpler tonight)

As an engineer, I take offense at that in a number of ways. To begin, what is the 'right' solution to a problem? Is the least expensive? The most robust? The most cost effective? Is a person designing the next mars lander going to weigh those options the same way a person would if they are designing a plastic spork?

Even our little microcosm of FIRST has different design goals based on the team you belong to. Are you designing just to get on the field, with limited resources and money? Are you designing to get to Einstein?

I've already spent close to 12 hours discussing the balance between automous and teleoperated game play. The mechanical needs of a great auton machine are NOT the mechanical needs of a machine that is great at playing this game in teleoperated. The person who manages to mesh those abilities will be ahead. As a programmer you should have a hand in making those mechanical decisions.

Your over-simplified statement is incorrect. If you believe the laziest answer is the correct one, then I applaud your confidence and will enjoy seeing you push balls into the bottom goal in autonomous.

[Storcky]

Originally Posted by bvisness

(What else would the mobility bonus be for?)

Not directly related to this thread but I think that the mobility bonus is more of a strategy thing than a "let's make this easy for rookies" thing. Yes it is a simple thing to do but you can’t get the bonus if you start in the goalie zone and therefore you must make the decision of whether it's more important to start in the goalie zone to attempt to stop a ball shot by a the other alliance (also a huge programming challenge IMO - tracking incoming balls and getting in front of them to block with only 6" will require a lot of accuracy) or have your alliance partner start there so that you can attempt a 2 ball auto without the risk of them moving the ball from where you're expecting it to be or get those guaranteed points.

[wireties]

Originally Posted by Mr. Lim

I
No offence, but as a programming mentor on my team, if anyone came up to me and exclaimed that there were no worthwhile programming challenges this year, I'd promptly ask them to leave the team, and give my time to someone who's got a different perspective towards what it takes to build a world class robot...

Ditto - this young person's attitude is poison in a team effort. Hopefully a mentor on his/her team will counsel him/her.

[krieck]

I agree that autonomous seems less challenging this year.

If you want a serious programming challenge, try talking your team into an automated goalie strategy. Keeping the bot inside the goalie zone is a challenge. Allowing it to detect approaching bots and get in the way would be very challenging. Playing goalie will be primarily about the programming.

I suspect that few teams will put forward a high performing goalie this year, but a robot that can defend the goal and also perform back-field assists would be a valuable alliance partner.