I'm my team's only active programmer this year and I am completely lost

Technical Programming
,
1

Hello, this is my first year of FRC and I wanted to help out with the programming, but it turned out to be so much more than I anticipated. We have a four programmers and we all know java, but the other three rarely show up and don’t contribute too much. I’m not used to this kind of programming and there is so much that I don’t know, and it took me two weeks just to get a cheesy drive. I can only test the code on weekends because that is when I have access to the robot, but we just disassembled our last year’s robot for parts and now I have no way of testing my code.
We don’t have a programming mentor and I’m starting to panic about if I can get all this done, and I was wondering if anyone here has any advice or links, all of it would be appreciated. Thank you

Also, I am using the java command robot template.

5 Likes
2

The WPILib docs are very helpful. They have steps and example code for a lot of the things you are probably going to do.

3

The 3 resources that I find to be the best for understanding FRC robot programming are FRC Programming Done Right, the WPILib documentation, and the Javadoc for WPILib.

The most difficult part of FRC programming is understanding the control system and getting something moving. Since you already have a simple drive working, I would suggest you continue looking into mapping commands to joystick buttons. Allowing your team’s drivers access to all robot functions is critical.

You can also spend time working on autonomous programming, both for the autonomous period and teleop period. A general rule that I have learned is that while drivers may be able to move a manipulator, with the right programming, the robot can usually do the job 10x better. But this is something to work up to.

As for limited robot time, you might want to look into using the Simulator built into WPILib. I myself haven’t played with it at all, but it looks to me like if you get the simulator working, you can test code without a robot. However, code should always be tuned to the exact hardware that will be running at competition. The simulator is not a complete replacement for the actual robot.

2 Likes
4

If you go into github most teams have their previous years code open you could go look at theirs in order to get some examples.

1 Like
5

Hopefully this will help at least a little:

If you come across any issues feel free to reach out to 1305. We’ll see what we can help with :slight_smile:

1 Like
6

Make sure you start by having this discussion with your mentors and your teammates. It is important for teams to understand where they are low on resources, and how that should impact their robot design decisions. Your team should be focused on not having too many robot functions that rely heavily on a single programmer. They should also be more cognizant of your needing the robot to test code on.

Other than that, continue posting here. People on CD will always be willing to help. I have many friends who will gladly hop on a Skype or Google Hangout with other teams to walk through programming issues.

9 Likes
7

Our programmer has trouble getting the robot for practicing code, so he uses simulator to test code. We also use old robot parts and drive train to make a “Frankenbot” or our test bed for new kids to practice working on, wiring, pneumatics, and programming. Good luck !

1 Like
8

I highly recommend referencing other teams code for examples. I didn’t have any programming mentors or experienced students above me, so I learned to program by pouring through the code of both the greats (254, 1114, 1678, 971, etc.) and teams that are more on-your-level to get a reference of what types of FRC software are out there.

You’re more than welcome to reference our codebase, but there’s plenty of other teams out there to reference from as well.

9

As someone who has been in a similar situation, I would like you to know you might be the only programmer ok your team, but we have loads of great mentors and programmers here on CD who has helped me get through many problems and definitely will help you too.

I would suggest looking into the Timed Robot and the Command Based frameworks. Timed Robot can be ideal if you want to try out a simple button - motor/piston interaction or etc. It is very simple and can even be succesfully used in a competition.

Of course , if you feel comfortable with the Timed Robot framework, you can move over to Command Based which is great for modular applications and more advanced control loops, etc. However, don’t feel like you need to be using Command based, know your resources and act on them :slight_smile: Also, don’t forget to reach out for help when you need it!
P.S: We have even won a regional with our old Timed Robot code and there weren’t many issues with it, so I highly recommend it for beginning to frc programming.

10

Biggest advice I can give: Break the problem down into smaller, manageable bits.

At a super high level, your problem is “Make software work on the 2020 robot”, with all the challenges you mentioned.

The first small step to solving this big problem is planning. What is the software going to do? What do you feel comfortable can be developed under the constrains you have? What do you feel nervous about completing? I would strongly recommend some introspection, and time with your other programmers to discuss this thoroughly, if you haven’t yet.

Then, bring it up with the whole team. Make sure they’re levelset on what sorts of things your programming will be able to support, what it won’t, and what assumptions you’re making in order to get there. If the rest of the team has a vested interest in a working robot, they have a vested interest in listening to you.

Put a box around what you will and will not do - “constrain the scope” as we say. Within that box, use all the links and resources others have been providing to further subdivide the problem. Set deadlines and testing goals. Be realistic about what you can do, and communicate out when you make (or miss) these goals.

Be extremely leery if anyone ever starts a sentence with the phrase “And then software will just…”

TL;DR - Project Planning is your friend.

3 Likes
11

My advice is keep it simple. The wpilib docs will have simple, straightforward example code.

If you look at other teams’ code, you might see very advanced code you don’t understand. Bug free simple stuff that works is a lot better than advanced stuff that never gets finished or that fails during a match.

1 Like
12

Make heavy use of the WPILib example projects to get a good idea of how we recommend the library be used. Don’t copy-paste the code from the examples (it has a lot of empirical constants and other details that are not likely to be correct for your setup), but try to structure your code similarly. For a robot for this year, the FrisbeeBot example project is likely the most-relevant.

3 Likes
13

One thing I advice, in terms of testing, is making a “bench bot”. It doesn’t need to have a lot of stuff on there. My team always had some kind of bench bot which included wheel with motor controller, encoder, potentiometer, and whatever else we were trying to test. Although you won’t be able to test your whole code, you can make a simplified version to prove your concept. This is also very helpful in learning how closed loop behaves because you have control over the sensors and you can watch how the wheel spins based on how you change those values.

1 Like
14

Best advice I can give: use github to store your code. It will help you keep track of changes and make it much easier to get help from other teams. If you need help getting started with github, please DM me and I’ll walk you through it.

2 Likes
15

I’ll go around and keep shilling Zero to Autonomous.

2 Likes
16

Does your team have a second Roborio, PDP, VRM, PCM (optional), main breaker and at least one motor controller of the type being used on your competition bot? If you do, make up a small panel that will fit all these components, install them with Velcro or zip ties. Get an AC to 12 Vdc adapter good for at least 2-3 Amps to power it. This is compact enough you can take it home to work on the programs, if you wish to. A DVM on the motor controller output will tell you what direction (forward or reverse) the output is and give some indication of the throttle position the controller is producing. You may have to swap the motor controller from one function to another to verify those functions. If your team does not have these parts, do they have space in their budget to purchase them? They can serve as spares when you go to competitions.

Please note that this is good practice even for teams with more resources than what yours currently has since it allows programming to proceed in parallel with the robot construction.

1 Like
17

You don’t need a robot to test your code. Robot simulation lets you run your code on the desktop, and provides a GUI for changing inputs and seeing outputs.

2 Likes
18

I’m a programming mentor and I’ve been in your shoes. There is nothing more frustrating than not having access to the robot. Last year, 6933 took so long to build the elevator that the coding team had a grand total of 15 minutes with the robot before it had to go in the bag. I am not exaggerating. We had to scramble to test and refine during competitions in the pits. By the END of the season, the robot was a world-class competitor, which means we only really needed about three days with the robot, which we did not get, to have a much, much better season.

Do what you can with simulators and with tutorials and preparing code ahead of time, but I’d recommend setting some parameters with the team.

Make sure the rest of the team understands that the coding part is 10 times as complicated as the robot building part. You have the most difficult job, period. I’ve been coding for over 30 years and navigating the development tools for an FRC robot and learning to code one is exceptionally difficult, even by professional development standards. As such, they need to make sure that they do not have lofty expectations about what can be accomplished, especially without a robot. And especially the autonomous part.

Plan on extremely simple, direct controls and almost no autonomous other than driving off the line. Precision autonomous driving/manipulation requires learning all about PID tuning, and/or using the new trajectory system with drive system characterization, and the new 2020 system for command sequences, which means a fairly in-depth understanding of object-oriented design principles. It’s a lot. It takes many, many days of just you and the robot, which you are unlikely to get.

Here are things you can accomplish relatively easily:

  • Adding a camera to the dashboard (fortunately) is only a couple lines of code.
  • Directly controlling the power output of motors using control inputs from the driver and operator (you’ve already done this with the drive.) This gets you driving, probably intake and delivery systems, and maybe a color wheel spinner (point the camera so they can see it to eliminate the need for autonomy.) If the team does everything with motors, and is not asking for extreme precision, you’re fine.
  • Moving servos to a specific angle (only a few lines of code)
  • Opening and closing pneumatic valves (only a few lines of code.) Pneumatics are a much bigger problem for the build team than the coding team, in that there’s a lot of fussing with the compressor, tubing, pressure gauges, release valves and other stuff that the code doesn’t mess with.

Here are things that you cannot do without much more experience and time with the robot:

  • Driving a specific distance or turning a specific angle in autonomous. Trust me. Many people assume this is easy, and it emphatically is not.
  • Making a shooter fire with consistency – this requires PID tuning of the shooter flywheel velocity. If you are using smart motor controllers like the TalonSRX, some of this is done for you, but you have to learn to use it, and how to PID tune. Maybe someone else on your team knows how to do that, but if not, and if you attempt to use percentage output control on the motor, it will fire inconsistently based on friction, remaining battery power, etc. Again, inexperienced team members will assume this is easy.
  • Recognizing the color wheel using the color sensor. I’ve written several posts about this recently. Our experienced coding team took over a week to get this working and was working on nothing else.
  • Locking motors. This is a big “gotcha” for beginners. When you stop delivering power to a motor, it just spins freely. That has implications for driving (coasting) the wheel spinner (overshooting) and, more importantly, climbing! If you stop climbing, many robot designs will slowly drift to the floor if you just turn the motor off, and this year, they are requiring you to stay in the air five seconds after the buzzer, which shuts off driver/operator control. Position PID is one way to lock the motor, but check and see if the build team is anticipating this. The “everybot” has a one-way ratcheting winch, so their solution is (helpfully) purely mechanical.
  • Vision processing. This is soooo much fun! Really! Using image processing techniques with lights on the retro-reflective tape and GRIP to build vision profiles. Heck, last year we even used a Raspberry PI with a Python GRIP profile to align the robot to field elements automatically. This is a rabbit hole you don’t have time to go down, though. It takes an enormous amount of effort and time. We had team members doing almost nothing but this part all season while others worked on the control system.

So stick with the easy stuff, let the team know what can be done with it and what can’t. If you’re going to be around next season, you might want to find out about offseason activities. Our team spent a great deal of the summer with last year’s bot experimenting with coding techniques. By next season, you could be the indispensible expert wizard in the ivory tower. But for now, you just need something that works.

12 Likes
19

I just realized that in my effort to be supportive I may have unintentionally diminished the roles of the other team members. In the interest of gracious professionalism, allow me to rephrase:

“Most difficult” is the wrong phrase. I’ll stand by “most complicated” but that’s a different metric. Coding is absurdly complicated. But it’s also my favorite, and I’m glad our team has good mechanical/electrical team members and mentors because that’s not my area of expertise.

And despite the challenges, I love the fact that if we make a mistake, or need to change a design, we can do it with a few keystrokes. Need new components? We can download them! No need to place an order with AndyMark.

Keep us posted on your progress and if you get stuck on something, come ask. There’s always an answer here somewhere.

1 Like
20

A bit of a tangent, but just in case you or someone else is trying to do this, remember that when the robot disables, all motors are turned off, not just your control from the driver station. This includes any PID loops, regardless of if they’re running on the motor controller or the roboRIO. Brake mode is the only way to hold something in software when disabled, but brake mode doesn’t resist motion until the motor starts moving, so it’s incapable of holding something truly still. Your solution for staying up almost certainly has to be purely mechanical, unless you have a very light robot.

4 Likes