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!

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

Originally Posted by 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!

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!

[Bryan Herbst]

Originally Posted by Hypnotoad

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]

Originally Posted by Tanis

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!

[Hypnotoad]

Originally Posted by 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!

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.

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

[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

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.

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

Originally Posted by Tanis

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.

[bvisness]

Originally Posted by JohnGilb

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