Noob question, but would love some advice

[onenerdyguy]

So, we're 90% done with our code, and a team member had a question that I honestly didn't have a good answer for.

Why do we have things broken out in commands/subsystems/etc files instead of just making one giant robot.py file?

My initial answer is to make it easier to split up the coding as well as making sure that one failure in a system won't bring the bot down, but as we've coded more we find that if you screw up in a subsystem or a command, it'll bring down when that code iniatializes anyways.

Help me out?

[RyanN]

It's much easier to manage and organize. If you have a robot.py file that is 10k lines long, how much time is it going to take to find where you initialized the joysticks?

If you have it under /robot/joysticks/joystick_left.py, you know exactly where it is, and is likely 20 or 30 lines long in total.

Also, imagine you have more than one programmer, you can give each programmer a subsystem to work with. The changes they make are isolated to their subsystem and don't affect the code of other people's code / subsystems.

Code management is a primary reason.

[virtuald]

Everything that RyanN said.

Honestly, command based programming in RobotPy is not very pythonic, and I find that it takes a lot of boilerplate to get even simple things done. There are definitely ways to address some of it -- in particular, we probably should have better support for not crashing the whole bot if one of your commands is broken. However, I don't use Commands et al, so I haven't messed with its internals that much.

This season, I've introduced an experimental framework called MagicBot that is simpler to use than command based programming and has builtin stuff to ensure that a wayward component doesn't bring the entire bot down in a competition -- but it's not quite as full featured yet (in particular, no support yet for sequential state machines like CommandGroups -- but maybe I'll do that this weekend).

The documentation explains some of my philosophy for structuring robot code, you may find it useful. http://robotpy-wpilib-utilities.read.../magicbot.html

[Jon Stratis]

While the small programs we use on these robots may not really require it (back in the day on IFI's old system, pretty much everything we did was in one file!), it is a really, really good industry practice to teach your students. It's called separation of concerns, where you literally separate the different areas. It helps with debugging - if your problem is with your climbing mechanism, you can ignore the files related to shooting or driving, for example. It helps with code understanding - someone new can come in and grasp the general structure and fhedive into details much quicker than they can with a single big file. It helps with collaboration- if you use a repository (like git) to store your code and sync it across multiple people, you have less collisions checking things in, because people are working on different files. This is especially important in the "real world" where you may have a team of 20-50 people working on a single program that's literally hundreds of thousands of line long (or more!), When totaled.

[onenerdyguy]

Alright, cool, these are exactly the answers I was after.

I agree with everything said here. The figured there was no technical limitation, as all the test files we've put on the bot are single file monsters, but this confirms it.

Thanks!

[onenerdyguy]

Originally Posted by virtuald

Everything that RyanN said.

Honestly, command based programming in RobotPy is not very pythonic, and I find that it takes a lot of boilerplate to get even simple things done. There are definitely ways to address some of it -- in particular, we probably should have better support for not crashing the whole bot if one of your commands is broken. However, I don't use Commands et al, so I haven't messed with its internals that much.

This season, I've introduced an experimental framework called MagicBot that is simpler to use than command based programming and has builtin stuff to ensure that a wayward component doesn't bring the entire bot down in a competition -- but it's not quite as full featured yet (in particular, no support yet for sequential state machines like CommandGroups -- but maybe I'll do that this weekend).

The documentation explains some of my philosophy for structuring robot code, you may find it useful. http://robotpy-wpilib-utilities.read.../magicbot.html

I'm really liking the look of that magicbot setup. It seems to be more of a middle ground and more of a python way of doing things, which is exactly where we are struggling. The kids found the way we had them coding commands/subsystems/etc to be extremely intensive due to the amount of repetitive boilerplate and frankly, led to tons of silly little errors.

I'm going to have to give this a shot on our practice bot, to see if it's worth looking at for off season training. Honestly, if it was week 3 instead of now and it tested stable, we might look at rolling it out to competition.