Programming dumbed down even more.

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?

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!

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.

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.

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!

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?

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.

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.

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.

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.

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.

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!

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

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.





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?

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
Quals 61 - Newton Division 2011 - The Blue Alliance (watch 233, the pink team)
was legal.

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

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.

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…

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.