Programming dumbed down even more.

[Hypnotoad]

2012: we had a difficult autonomous. The robot had to not only aim at the fairly small target, but also judge distance to properly score. operators would also often need vision processing to aim, considering the small targets, and the not so great perspective that they get.

2013: things get a little simpler. The goal was wider, and frisbees flew straight, so there wasn't too much difficulty aiming. Many robots could do it with simple dead reckoning. Robots also had to pick up frisbees from the ground. Teleop vision processing also most likely slowed you down if it wasn't extremely optimized.

2014: shoot in the massive goal when it's lit up and drive forward.
The rest of the game is entirely up to the drivers.

Anybody see the trend? programming is getting easier and easier.

I don't work on robot programming anymore at meetings. There is no reason to. There is no program to work on since the robot doesn't actually need to be coded anymore. The joysticks have to go to the drive train and the buttons have to go to the other actuators. Maybe the main mechanism can be controlled by a state machine to make my life as operator a bit easier. Other than that there is very little to program. What's with this trend?

[IndySam]

Really?

Find the hot goal
Shoot the ball
Find another ball touching your partners bot
Pick up other ball
Find the hot goal
Aim and shoot the second ball
Move to a good spot to receive a pass or pick up remaining ball.
All in 10 seconds

Get to work!

[mechanical_robot]

2012: we had a difficult autonomous. The robot had to not only aim at the fairly small target, but also judge distance to properly score. operators would also often need vision processing to aim, considering the small targets, and the not so great perspective that they get.

2013: things get a little simpler. The goal was wider, and frisbees flew straight, so there wasn't too much difficulty aiming. Many robots could do it with simple dead reckoning. Robots also had to pick up frisbees from the ground. Teleop vision processing also most likely slowed you down if it wasn't extremely optimized.

2014: shoot in the massive goal when it's lit up and drive forward.
The rest of the game is entirely up to the drivers.

Anybody see the trend? programming is getting easier and easier.

I don't work on robot programming anymore at meetings. There is no reason to. There is no program to work on since the robot doesn't actually need to be coded anymore. The joysticks have to go to the drive train and the buttons have to go to the other actuators. Maybe the main mechanism can be controlled by a state machine to make my life as operator a bit easier. Other than that there is very little to program. What's with this trend?

I don't think you are being innovative enough when it comes to making the robot's computer to do stuff. You can use coding more than just for targeting you just need some creativity. So the trend is you losing creativity when it comes to code.

[TucoSalamanc]

Our programming team has found this also. So, in return, we have upped the challenge for this year for ourselves. As the drive code will take about a week we have set the following tasks for ourselves.

Add photogates to detect the ball in our arms, even when the drives view is blocked.
Use an angled piece of glass and a broken down SMART board to make a HUD for our drivers. With all these rules having indicators that they can see live will be needed
Attempt Kinetic intergration for firing. Track the gamepad being pushed forward for fire, and pulled at the body for the flywheels to power down
Add toggle switches on the robot to allow us to control what we do during auto, as it will change as the other teams do.
Attempt tracking of other robots, with color tracking to determine team. Project to HUD


I doubt they will all get done, or will be feasible. But they are fun challenges for us, and others, to try.

[Hypnotoad]

Really?

Find the hot goal
Shoot the ball
Find another ball touching your partners bot
Pick up other ball
Find the hot goal
Aim and shoot the second ball
Move to a good spot to receive a pass or pick up remaining ball.
All in 10 seconds

Get to work!

False!

Wait for hot goal
shoot
move forward

or if your alliance members can't make auto shots:

shoot
pick up ball
shoot again
move forward


There isn't any point in trying to get both balls in the hot goal since it only shows up on the side you start on for 5 seconds at a time and moving to shoot for the other one is time consuming.

And a system that tries to find the other teams ball is pointless because a smart alliance would position the robots such that the ball ends up in a known location.

No work to get to!

[jgcoded]

Really?

Find the hot goal
Shoot the ball
Find another ball touching your partners bot
Pick up other ball
Find the hot goal
Aim and shoot the second ball
Move to a good spot to receive a pass or pick up remaining ball.
All in 10 seconds

Get to work!

For ROBOTS starting in their GOALIE ZONE the TEAM may decide if the BALL is: staged between the TRUSS and the ZONE LINE and not contacting an ALLIANCE partner, or removed from the FIELD for the MATCH.

Rule <G5>. Did you mean near your partner's bot?

[randantor]

Rule <G5>. Did you mean near your partner's bot?

For ROBOTS starting in the white ZONE, the TEAM may preload one (1) of their ALLIANCE’s BALLS such that the BALL is touching their ROBOT.

Touching your partner's bot.

[bvisness]

It seems like they're trying to make it easier for rookie teams to get some autonomous points this year (which, in previous years, was honestly pretty hard.) If we have time this season (ha) I will probably try to work on a two-ball autonomous that can score a partner's ball as well. I'm sure it would set us apart at regionals, beyond that I'm not so sure.

I think that teams that do attempt a more complex auton will probably face some unique challenges right away - like trying to keep track of both goals at the same time to see which is hot. I'm not sure I trust our vision system enough to act on the absence of a target.

[MrBasse]

Touching your partner's bot.

Don't try to make him seem wrong, he even quoted the proper rule. That is as long as one robot is in the goalie position or absent from the field altogether. Then you can place the ball anywhere you wish in the white zone on your side of the truss.

[Hypnotoad]

I don't think you are being innovative enough when it comes to making the robot's computer to do stuff. You can use coding more than just for targeting you just need some creativity. So the trend is you losing creativity when it comes to code.

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.

[Bryan Herbst]

And a system that tries to find the other teams ball is pointless because a smart alliance would position the robots such that the ball ends up in a known location.


It's easy to go the "dumb" route and rely on precise placement of balls at the start of the match.

However, this isn't very robust. What if the ball rolls a little? What if for whatever reason your alliance can't place the ball where you need it in order for another robot to make its autonomous shot?

A more robust and intelligent system would seek out a ball to pick up.

You complained that there was nothing to do in autonomous, and IndySam suggested ways that you can add more depth to your autonomous mode. If you don't like that idea, maybe focus on adding depth to other parts of your code.

[Hypnotoad]

It's easy to go the "dumb" route and rely on precise placement of balls at the start of the match.

However, this isn't very robust. What if the ball rolls a little? What if for whatever reason your alliance can't place the ball where you need it in order for another robot to make its autonomous shot?

A more robust and intelligent system would seek out a ball to pick up.

You complained that there was nothing to do in autonomous, and IndySam suggested ways that you can add more depth to your autonomous mode. If you don't like that idea, maybe focus on adding depth to other parts of your code.

These what ifs are what kill many good intentioned projects. There's plenty of stuff that can go wrong, but making a more "robust" system *snicker* you simply add more things that can go wrong.

It's when hard but simple things are NECESSARY that programming becomes interesting.

[yash101]

I also think that you just are losing your enlightenment and creativity.
Also, it isn't necessarily getting easier. The ball is much harder to handle this year and an aiming system will be harder to implement because of the greater effect of gravity!

[jgcoded]

Touching your partner's bot.

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

G5:

For ROBOTS starting in the white ZONE, the TEAM may preload one (1) of their ALLIANCE’s BALLS such that the BALL is touching their ROBOT.

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.

The penalty for violating this rule is a technical foul (-50 points).

[Hypnotoad]

I also think that you just are losing your enlightenment and creativity.
Also, it isn't necessarily getting easier. The ball is much harder to handle this year and an aiming system will be harder to implement because of the greater effect of gravity!

This guy in the attachment is one of my side projects. The cameras are streamed into an oculus rift, and the sensors are being sent to the udoo on board, allowing the driver to essentially be where the robot is. No I am not losing creativity and "enlightenment". There just isn't anything to do in this game.

[aryker]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

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]

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]

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]

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]

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.


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]

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]

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]

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]

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]

(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]

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.

[JohnSchneider]

I agree that autonomous seems less challenging this year.


Really?

[criogod]

Nice, before reading this thread I admit I had pretty low expectations for programming difficulty this year. I hope I get to see all these awesome features at competition!

[Bryan Herbst]

I think the core problem here isn't necessarily that autonomous is inherently less challenging than previous years, but that the way FIRST presents autonomous doesn't present an obvious challenge to some teams.

FIRST always provides some low hanging fruit for autonomous mode. The vision targets, extra points for scoring in autonomous, and mobility points are clear examples of things you can do with your robot in autonomous.

However, there are plenty of higher hanging fruit that FIRST doesn't necessarily point out for teams. FIRST expects that teams that can go above an beyond a basic autonomous mode are also capable of defining their own stretch goals to challenge themselves.

What I take issue with in this thread is the complain that FIRST hasn't made anything challenging necessary. My first response is that FIRST doesn't make any programming strictly necessary- you don't need to program a single line of code to make a robot that can be placed on the field.

It is up to the teams to define their own requirements for their code. FIRST does none of this. Your team can (and should) define requirements that are appropriate for your programmer's skill levels.

[bvisness]

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.

Hmm, I hadn't thought about that. That's an interesting tradeoff to keep in mind.

[bvisness]

However, there are plenty of higher hanging fruit that FIRST doesn't necessarily point out for teams. FIRST expects that teams that can go above an beyond a basic autonomous mode are also capable of defining their own stretch goals to challenge themselves.

And teams who can pull off a more complex autonomous are going to be very desirable in alliance selections - last year we were able to consistently score 5 discs in autonomous, and that was enough to get us to Galileo finals despite seeding low.

[JohnGilb]

A lot of the challenge in FRC programming isn't usually in achieving the objective, whatever it may be that year - many teams are capable of doing that.

What _is_ challenging is making a system that is reliable and robust. Being able to handle complications that challenge common assumptions is a significant advantage. You don't want to be this guy:

-Our robot will always start the match where I expect.
-Well, at least facing the goal.
-Or apparently in the goalie zone?
-Well, we'll know far enough in advance where the robot is going to be that we can plan for it - nobody is going to make a last minute change.
-And the ball will be preloaded in the correct manner every time.
-Well, close enough to just start the normal firing sequence, right?
-You're kidding?
-Ok, so after we deal with all this, we'll go grab the ball that our partner put right where we expect it.
-Really? Well, it'll be close enough.
-Or if it isn't, we'll be able to find it using vision. The ball will look the same at every event, and at every match in the event.
-Oh, some of the lighting changed? Well, whatever it is will definitely start in view of our camera, and our opponents in the goalie zone won't be blue or red, so no worries.
...

And that's just related to autonomous. Highly competitive FRC robots need to be robust and have incredible uptime, despite the fact that most of them are one-of-a-kind prototypes being tested in the field.
-Can you rapidly tune robot parameters without having to redeploy code?
-If the cRIO crashes and needs to be flashed right before a match, do you have a copy of all the code & configuration data nearby and ready to download?
-Can you handle sensors breaking down or being ripped from the robot in the middle of a match?
-Can you rapidly change your auto program based on the ever-evolving needs of the drive team during qualifications and eliminations, and be confident that the robot will do exactly what you want?

This list could go on and on. Ever year, I wish there were 15 programmers on our team, so that we would be proud of our answers to questions like these. There's always some way to make your robot better, or to prepare for "complications."

[techhelpbb]

If anyone is bored and wants a challenge build your robot mechanical systems in a strange way and make programming synchronize 2 PID loops to make it work at all.

I bet you'll not be bored much longer once you start :yikes:

or

Write your own vision system from scratch. No shortcuts like OpenCV get down and dirty.

I know FIRST teams can do these things so I am not setting anyone up for something impossible. Just demonstrating that FIRST hardly is short on challenges.

[JohnFogarty]

It's raining negative rep points up in here.

For all intents and purposes of coming into this thread. I too disagree with the OP.

[Akash Rastogi]

Hypnotoad, if you post which team you are from, I'd love to track how successful your 2 and 3 ball autonomous modes are this year. I'd also love to see your Hot goal scoring percentage at the end of the season.

Good luck, happy to hear there are teams who are so confident in themselves.

By the way, autonomous functions don't end after 10 seconds. Feel free to make a fully automated scoring robot.

[Wildcats1378]

I also think that you just are losing your enlightenment and creativity.
Also, it isn't necessarily getting easier. The ball is much harder to handle this year and an aiming system will be harder to implement because of the greater effect of gravity!

well, for autonomous, you just have to put your robot in the same spot every match (isn't hard since there is a line you have to stay behind and the goals are huge), wait until you see the hot goal, and fire. only hard part may be picking up others balls, but other than that it is really pretty easy compared to previous years.

[Laaba 80]

I wish Hypnotoad had left the last paragraph out of his first post. Instead of having a worthwhile discussion whether autonomous is becoming simpler, it turned into everyone teaming up against a high school student. It can be hard for a high school student to realize they are wrong, or when they are arguing instead of debating; I was the same way, and quite possibly still am. Nothing will be gained by telling him he's wrong and has things to work on, nor by him telling everyone else he has nothing to work on. If a team wants to do all kinds of awesome complex programming that's great, and if a team wants to just have basic functionality that's great too.

I hope we can all get back to his intended topic, or create a new thread for a fresh start.

FIRST always provides some low hanging fruit for autonomous mode. The vision targets, extra points for scoring in autonomous, and mobility points are clear examples of things you can do with your robot in autonomous.

However, there are plenty of higher hanging fruit that FIRST doesn't necessarily point out for teams. FIRST expects that teams that can go above an beyond a basic autonomous mode are also capable of defining their own stretch goals to challenge themselves..


This is a great point. In my opinion, FIRST started adding the low hanging fruit in 2010. Since then there has been a simple(ish) task a team can do so they can complete "their autonomous task." Ex: scoring an ubertube, scoring your preloaded balls/frisbees. There has also been a much harder task for more advanced software teams to complete. Ex: 2 ubertubes, picking up and scoring extra balls/frisbees. I think this is a great thing.

From 2006-2009, there really wasn't a viable "robot autonomous task." In 2008 our robot was only able to cross one line and get four points. As the programmer and driver, I often felt like I was letting our alliance down by not having a higher scoring auto, and at times it seemed other teams felt we were letting them down. What they didn't know is that I had written a four line auto that would knock both our balls down(0% chance of working; I was an optimistic sophomore) but never had time to work with the robot due to that being a long build season for us. It really was not a positive experience for anyone on our alliance.

All that to say: I think FIRST has done a phenomenal job of late providing a simple(ish) task so teams can feel they did their jobs and contributed to the alliance, while still allowing more skilled teams to do more for extra points.

[sanddrag]

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

No offense, 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...


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.

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

I wish Hypnotoad had left the last paragraph out of his first post. Instead of having a worthwhile discussion whether autonomous is becoming simpler, it turned into everyone teaming up against a high school student. It can be hard for a high school student to realize they are wrong, or when they are arguing instead of debating; I was the same way, and quite possibly still am. Nothing will be gained by telling him he's wrong and has things to work on, nor by him telling everyone else he has nothing to work on. If a team wants to do all kinds of awesome complex programming that's great, and if a team wants to just have basic functionality that's great too.

I hope we can all get back to his intended topic, or create a new thread for a fresh start.


I completely agree with all of these points and they are very all well stated. I certainly give the OP credit for stirring the pot and starting a nice lively debate here, but I agree that his original post and a few of the subsequent ones are not well articulating his point, and did not carry a tone within the spirit of Gracious Professionalism that his team has worked hard to live by.

If I recall, I found myself in a similar situation on ChiefDelphi several years ago, and several of the senior members of the forum messaged me to let me know the errors of my ways. So, I decided to do the same, and I've been communicating privately with Hypnotoad.

What students need to remember, is that the internet is forever. It never forgets. While it may take years for a team to build its reputation in the FIRST community, it can all fall apart in an instant as a consequence of one team member's words or actions.

I think Hypnotoad now realizes that he has embarassed his team on a public forum, has realized that there is plenty of work to do, and has realized that he needs to really think twice before clicking the "Submit" button when posting. He has removed his team number and name, as to not let his posts reflect poorly upon the team he is involved with.

I'm going to kindly ask a moderator to close this thread, and if we'd like to start another where we discuss the level of challenge presented by this year's autonomous portion (without bashing the OP), then let's do that.

[MooreteP]

The Hypnotoad is a large toad with pulsating, multicolored eyes, which emits a loud, ominous buzzing noise. It has the power to hypnotize almost any living thing at will, even mass numbers of creatures. The Hypnotoad first appeared in "The Day the Earth Stood Stupid", in which it hypnotized a flock of sheep to herd themselves into a pen and close the door behind them, the panel of judges to win the pet show and then the audience of the pet show to force their approval of that victory. ~Wikipedia

Come on everyone, lighten up. You've been hypnotized by an Uber-troll.

It's a great game to use to teach our students about enough levels of programming to make them more competent with the skills needed to solve problems.

Enjoy the season and it's attendant challenges.

[bvisness]

-Can you rapidly change your auto program based on the ever-evolving needs of the drive team during qualifications and eliminations, and be confident that the robot will do exactly what you want?

Tasks like that are what make robot programming interesting for me. Last year all our autonomous routines were laid out in .csv files, which we could FTP to the robot at a moment's notice. It made autonomous testing infinitely easier (especially considering LabVIEW's inexplicable compile times.)