|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||||
|
|||||
|
Command Based Java Topics
This past fall our team presented a Basic Command Based Java course at the VA FRC Workshops that VirginiaFIRST organizes every year. This summer I'd like to put together an intermediate to advanced presentation and would like some input on what are some things people would be interested in learning about if they were to attend a course on something like this.
The basic course covered: The basic srtucture Subsystems Commands Writing a basic drivetrain and autonomous. Some more advanced topics I was thinking about are: Creating reusable commands CommandGroups PIDSubsystems and PIDCommands Case based CommandGroups What other topics do you think would be useful? I'd also like to use this as a research opportunity for our team for things that we have not figured out the best practice for yet, and we can post our results here as we find them, even if it doesn't make it into the final presentation. |
|
#2
|
||||
|
||||
|
Re: Command Based Java Topics
I for one have been converted into a huge proponent of robot builder.
Sooo... Creating a Project in RobotBuilder Maintaining a Project in RobotBuilder Using Git to manage a RobotBuilder based project. Interrupted vs Finished Commands Planning for Edge Cases (i.e. no hot goal) Extendable Commands (may be more advanced than intermediate) Analog Buttons (many teams don't utilize the xbox triggers because they're analog) Command - Subsystem Dependencies and Interrupts. Last edited by mwtidd : 15-04-2014 at 11:30. |
|
#3
|
|||||
|
|||||
|
Re: Command Based Java Topics
Quote:
Quote:
Quote:
Last edited by notmattlythgoe : 15-04-2014 at 11:34. |
|
#4
|
|||
|
|||
|
Re: Command Based Java Topics
Quote:
We should teach proper version control system usage BEFORE we teach people how to program. (and oh yeah, save yourself some headache and just use git.) |
|
#5
|
|||||
|
|||||
|
Re: Command Based Java Topics
Quote:
|
|
#6
|
|||
|
|||
|
Re: Command Based Java Topics
Quote:
If a student is working on a feature that is easy to break off, I will have them make a branch that we can pull in later. An example of this is something like a tiny HTTP server or your vision code. Define the interface then let them hack on the implementation in a branch. The main rule is don't commit code that breaks the build! |
|
#7
|
|||||
|
|||||
|
Re: Command Based Java Topics
Quote:
The pain in the butt thing we ran into this year was our practice bot is using 2 solenoid cards instead of 1 like our competition bot is using because of a lack of correctly voltaged solenoids, so making sure we don't merge in our address changes can get annoying. We currently have 2 working branches open, one for competition and one for practice so we're not constantly having to make sure we have the right addresses in. Keeping both branches and the trunk in sync is a bit annoying. Last edited by notmattlythgoe : 15-04-2014 at 12:11. |
|
#8
|
||||
|
||||
|
Re: Command Based Java Topics
Quote:
Typically I find that the drive train and the mechanisms are separate enough that, as a general rule, work on them (and they're commands) can be split into separate branches. I personally prefer a mechanism based package structure for this reason. Something like this: Code:
edu.pmhs
- drive
-subsystems
-commands
- arm
-subsystems
-commands
- robot
-commands (multi mechanism commands)
Obviously there are still modifications that have to be made to core class (i.e. OI) but these are typically simple enough that they shouldn't require a branch. I also encourage a "test before you commit" even for the local repo. This ensures that the students verify their work before submitting it. I also wait to do a "code review" until they are ready to publish their work. We don't have the luxury of a multi student programming team, but I would love a model where you have a student who is responsible for each mechanism, and one responsible for the "robot". https://www.atlassian.com/git/workfl...feature-branch Last edited by mwtidd : 15-04-2014 at 12:15. |
|
#9
|
|||||
|
|||||
|
Re: Command Based Java Topics
Quote:
Code:
blah.blah.blah.blah.drivetrain.commands |
|
#10
|
||||
|
||||
|
Re: Command Based Java Topics
We also found things easier using a mechanism based package structure.
Also, we have a naming system Code:
SS_ : Subsystem C_ : Command CG_ : Command Group This way, we know what is what. And we can have similar named Commands and Command Groups, if we need that Code:
C_Pickup CG_Pickup. For example, I've been making a custom Library (Much Like atalibj that I found earlier this week), and the main point of it, is the Custom main robot class. It runs smoother, and faster than the WPILib version, and adds in some more automation to the robots. https://github.com/WestwoodRobotics/RoboLibJ Also, If you are using an IDE, Making custom templates is a really good idea. I have A custom template for the Subsystem Class that automatically fill in the super() constructor, writes singleton code, writes a static{} block, adds in an ITable and ITableListener for custom values, creates some extra methods for the ITable. |
|
#11
|
|||
|
|||
|
Re: Command Based Java Topics
Quote:
Everything else is done in branches. Every feature is branched and pull requested. The programming mentors review the branches, and either make comments, or merge it into master once the code was tested. Now sometimes during a competition, we will work in master, but we will push to github into a new branch. And then follow the same process. I have all of my students setup using eclipse and egit (what i personally use on my Ubuntu FRC laptop), although some students on our team use gitGui on Windows for managing their comits. We rarely ever tag, but we should. Note: The above is the ideal scenario on our team, I hope I get to see the day that it actually works like that. LOL. As for maintaing multiple versions of the code. The Poofs wrote a pretty neat library called a ConstantsFile I belive. It is an object that you can use to declare variables in RobotMap and then overwrite them using a textfile that lives on the CRio. If the textfile doesn't exist, it just defaults to the hardwritten value in code. I am sure someone on 254 can explain it better. Essentially, you can maintain one code base for your comp bot and practice bot, if you wrote your variables such that they can be updated on RobotStartup via a text file, and have that text file live on the practice bot cRio. This would allow you to keep the same single source and the text file on the practice bot does the heavy lifting for you. You can accomplish this using the Poofs method, or implement your own. As for advanced topics for command base: 1. Commands are loaded during their instantation on RobotInit. How to pass a value to a command in realtime during robot run. 2. Default commands, and how/when to use them 3. CommandBase programming philosophy. When to make something a method/function within a subsystem, when to make it a command, when to make it a command group. 4. And of course, no programming class is complete with a proper "how to comment code" discussion. Hope this helps, Kevin Last edited by NotInControl : 21-04-2014 at 16:56. |
|
#12
|
|||||
|
|||||
|
Re: Command Based Java Topics
All great ideas guys. Keep them coming.
Quote:
Last edited by notmattlythgoe : 21-04-2014 at 17:33. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|