Programming dumbed down even more.

[aryker]

Originally Posted by Hypnotoad

Creativity does not come into play here.

Incorrect. Creativity is what sets a great bot apart from a good bot. Just because the autonomous seems straightforward, that doesn't mean that you can't find another area where a more complex solution could improve your product.

Another point: you've had at least 3 mentors and various other students give good, sound arguments against your complaint as well as good suggestions for solutions to your issue. You've responded rather heatedly to each one. How much more do you need before you realize that maybe you've got it wrong?

[Woolly]

Originally Posted by jgcoded

I'd be careful with the wording on that rule you quoted.


Notice that the word their refers to TEAM and not ALLIANCE. Therefore, if a team has placed their robot in the white zone, and if they choose to preload a ball, that ball can only touch that team's robot. No other robot.

That rule is in the pre-match section, once autonomous starts there are no restrictions saying that another team on your alliance can't touch that ball.

It's similar to the wording of the 2011 rule:

Each ROBOT must be in contact with one UBERTUBE
. No more than one ROBOT may be
contacting an UBERTUBE.

Which was also in the pre-match section, yet
http://www.thebluealliance.com/match/2011new_qm61 (watch 233, the pink team)
was legal.

http://www.youtube.com/watch?v=YTs3b2w_GSw (better view, and showing capability for 3 tubes.

[MecaNaught]

Autonomous from last year was the easiest I've seen, because teams could place their robots in relatively the same position every time, so all the robot had to do was shoot, reload, shoot.

This year in autonomous, it's a requirement to have light tracking, and to adjust the robots position for shooting the ball to get goal points. There is also the driving forward part, which can be easy or complicated depending upon the method. Teleop this year is most likely going to be much more complex than last year as well, because of the amount of movement to the parts necessary to pick up balls, shoot them, and adjust both for the various goals.

In my opinion, FRC is streamlining programming, but not making it 'easier' than the past couple of years or for the years ahead.

[Mr. Lim]

I really don't think you're a very good programmer then.

Good programmers always find a better way to do something, especially when it's not obvious where those improvements can be found.

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.

In 2013, or programmers spent crazy hours optimizing the speed recovery algorithm of our shooter and speed control in general. We could shoot all four discs in well under a second, with all disc exit speeds within 1% of our target RPMs. Again, not a glamorous achievement but really hard, and beneficial.

In 2014, the ability to drive back and score a second ball in autonomous will be nice. I expect your team will be able to do that 100% of the time, since it's such a trivial challenge for you . But an even bigger challenge will be to figure out how to make your robot release a ball of if/when you lose comm, power or encounter any other countless failure. A good programmer will take ownership of this problem, and instruct the rest of the team on how best to do this, since programmers have the best understanding of how things behave when those types of problems occur. Bad programmers walk away and exclaim it's someone else's problem.

Of course you probably already have that problem figured out....

Or have you?

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...

[mechanical_robot]

Originally Posted by Hypnotoad

Creativity does not come into play here. We make the most efficient solutions for the game. This game, the most efficient solution is the most basic one, thus it is the solution that will be implemented. I put creativity into projects when they aren't constrained by winning and such boring things.

Creativity certainly does come into play. To help you, a couple of synonyms for creativity is innovation and inventiveness. The astronaughts on board Apollo 13 the engineers on earth had to be creative to keep the astronaughts alive from carbon dioxide poisoning, their situation was far greater than ours was and they only had hours or less to find a solution. There are many more examples creativity does come into play. That's what Dean Kamen and Woodie probably want you to be...creative they want you to be creative with your robots and ideas. Creativity/inginuity is what drives economies my friend. That's how people get rich and how economies grow. The American military would not be anywhere as powerful as it is today if there was no ingenuity to the technology. That's what helps makes us a superpower. Invention of the nuclear bomb prevented us from having world war 2 lasting a couple more years. And I'm pretty sure there was creativity going on at NASA and their contractors during the space race. Hope you read this.

[mechanical_robot]

Originally Posted by Mr. Lim

I really don't think you're a very good programmer then.

Good programmers always find a better way to do something, especially when it's not obvious where those improvements can be found.

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.

In 2013, or programmers spent crazy hours optimizing the speed recovery algorithm of our shooter and speed control in general. We could shoot all four discs in well under a second, with all disc exit speeds within 1% of our target RPMs. Again, not a glamorous achievement but really hard, and beneficial.

In 2014, the ability to drive back and score a second ball in autonomous will be nice. I expect your team will be able to do that 100% of the time, since it's such a trivial challenge for you . But an even bigger challenge will be to figure out how to make your robot release a ball of if/when you lose comm, power or encounter any other countless failure. A good programmer will take ownership of this problem, and instruct the rest of the team on how best to do this, since programmers have the best understanding of how things behave when those types of problems occur. Bad programmers walk away and exclaim it's someone else's problem.

Of course you probably already have that problem figured out....

Or have you?

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...

Well said, sorry but someone had to say it to him. Glad you said it though.

[Grim Tuesday]

If you're out of things to program on the robot, why not try making some non-robot projects? When we got too many rookies who wanted to be programmers last year (I mean honestly, we didn't need 15 people to program a Ultimate Ascent robot), we tasked them with designing a scouting database and system, picklist app, and a better algorithm than OPR for choosing our partners. Not all of it worked in the end but it sure provided them with a fun challenge!

[mechanical_robot]

Originally Posted by aryker

Incorrect. Creativity is what sets a great bot apart from a good bot. Just because the autonomous seems straightforward, that doesn't mean that you can't find another area where a more complex solution could improve your product.

Another point: you've had at least 3 mentors and various other students give good, sound arguments against your complaint as well as good suggestions for solutions to your issue. You've responded rather heatedly to each one. How much more do you need before you realize that maybe you've got it wrong?

I have voted a bad reputation already for him. Creativity is what drives a economy. I mean we the USA would have never win the space race against the USSR without creativity. And we were in a very intense competition with the USSR at the time. And we might in the next 20-30 years be in a intense competition similar to the cold war with China. This country need creativity or we are going not going to be the worlds superpower anymore.

[mechanical_robot]

Originally Posted by Grim Tuesday

If you're out of things to program on the robot, why not try making some non-robot projects? When we got too many rookies who wanted to be programmers last year (I mean honestly, we didn't need 15 people to program a Ultimate Ascent robot), we tasked them with designing a scouting database and system, picklist app, and a better algorithm than OPR for choosing our partners. Not all of it worked in the end but it sure provided them with a fun challenge!

Again this is all creativity right here. (He was saying FIRST competition has nothing to do with creativity) sure not all of it worked but I bet the rookies learned alot. Right.

[Hypnotoad]

Originally Posted by Mr. Lim

I really don't think you're a very good programmer then.

Good programmers always find a better way to do something, especially when it's not obvious where those improvements can be found.

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.

In 2013, or programmers spent crazy hours optimizing the speed recovery algorithm of our shooter and speed control in general. We could shoot all four discs in well under a second, with all disc exit speeds within 1% of our target RPMs. Again, not a glamorous achievement but really hard, and beneficial.

In 2014, the ability to drive back and score a second ball in autonomous will be nice. I expect your team will be able to do that 100% of the time, since it's such a trivial challenge for you . But an even bigger challenge will be to figure out how to make your robot release a ball of if/when you lose comm, power or encounter any other countless failure. A good programmer will take ownership of this problem, and instruct the rest of the team on how best to do this, since programmers have the best understanding of how things behave when those types of problems occur. Bad programmers walk away and exclaim it's someone else's problem.

Of course you probably already have that problem figured out....

Or have you?

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...

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)

[mechanical_robot]

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)

That absolutely made no sense really are you not listening to yourself? Sure the person was lazy and made the car but they spent alot of effort making the car or whatever. Read a little history. Pretty sure Google worked really hard and had lots of creativity when setting up their search engine and making their products. Same goes to every sucesful company.

[Hypnotoad]

Originally Posted by antimatter_john

That absolutely made no sense really are you not listening to yourself? Sure the person was lazy and made the car but they spent alot of effort making the car or whatever. Read a little history. Pretty sure Google worked really hard and had lots of creativity when setting up their search engine and making their products. Same goes to every sucesful company.

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.

[mechanical_robot]

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.

Again protype. And again PROTOTYPE.

[Dr Theta]

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)

A good programmer or engineer solves a problem so it requires the least effort possible for the user. That solution could very well involve a large amount of work and dedication from said programmer/engineer. It also involves looking at every aspect of your design that can be improved and constantly iterating. That is very different from "the lazy approach".

[Hypnotoad]

Originally Posted by antimatter_john

Again protype. And again PROTOTYPE.

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.