BrownGenius
commented
1 year ago The thing about comments for what commands do is that they are at the top of the file, and I have to bounce between the lines of code that do stuff and the comment. I think javadocs are great if intent is to document APIs or code to be used by other people/things. But for commenting pieces of code inside a project, I don't think it works well. This is just my 2 cents, and based on how I work with and read code.
Hi @loafdog, I agree. I'll try to move the comments from above the class to the method/constructor so that hovering over the method/constructor in the SequentalCommand group will actually show relevant information. I need to see if there's a way to copy javadoc for overloaded constructors. E.g. I'd hate to have to copy/paste 95% of the same text for each constructor just to describe what the additional parameter does.
The comments do not say where the robot is expected to be positioned when starting. Imagine being a brand new person(or someone who missed a few meetings :) ) looking at this and trying to figure out how to test/use these auto routines. I would not know where to place the robot to start. What direction should the robot be facing? What piece, if any should be in the claw? What position should the arm and claw be in to start? I'm being picky here but this is the kind of info needed in comments to make them useful imho.
PR looks good. hopefully testing goes well.
I agree. I will clearly document the expected starting conditions for each autonomous routine. Unfortunately, testing today was (again) limited due to mechanical/electrical issues. Dock & Engage is just too unstable for the competition bot. We may need to switch to just Dock and skip the engage portion.
Hi Team,
After Monday's autonomous practice, I dug further in the code and made a few tweaks. These all need to be tested on the actual bot before pulling into the main branch.
The main issue we noticed is that the competition robot tends to oscillate when trying to balance. I don't think the oscillation is PID related, though, because the practice robot balances fine. What I think is happening is that since the competition bot is top-heavy, when the charge station tilts in the other direction, the front/back of the robot ends up tilting slightly off the charge station. When it lands back, sometimes, the robot is no longer square with the charge station, which seems to make it much harder to find a balance point.
This branch tries to maintain a fixed angle/yaw while performing the entire dock/engage sequence. The way it works is:
Please take a look at the changes to see if there are any glaring bugs. We will test this tonight.