Closed ericsims closed 10 years ago
I suggest adding another Boolean parameter to IntakeSystem.setRingIntent(Boolean) to signify whether releasing should be done immediately or if it should respect the 2 second time thing (basically the only thing to change besides the method signature is line 65 && (intakeTimer.get() > 2 || doImmediately)
or something))
I actually don't think we should have overrides at all. If there's an issue with the robot, forcing it to work during the game by bypassing safety interlocks isn't the way to go..
@gluxon: this doesn't force LittleFinger to work during the game, it just allows the drivers to release the O Ring when needed without firing the Shooter (which is useful when the ball is bumped out of the robot or something). The only problem we have here is that it achieves the above goal but in a super unsafe way (directly setting the servo's speed without considering Intent, which could cause serious bugs if IntakeSystem.setServoIntent(false)
isn't called immediately after) so that's why we're considering adding the parameter above
As per "serious bugs": if IntakeSystem.setServoIntent(false)
isn't called immediately after the speed is directly set, IntakeSystem.setServoIntent(true)
won't work until it's been called with false
... kind of a big deal cause the O Ring won't be locked if that happens...
isn't the timer in miliseconds?
@PandaBlackAndWhitr nope The Timer specification is non-specific and doesn't mention anything about seconds. Regardless, it's in seconds. (Why, FIRST? :frowning: )
I added implemented the doImmediatly idea (calling the boolean immediateServo). It now runs everything through the LittleFinger system, and it has no delay on the override. Committing now. Is this thread closed?
You guys are talking on GitHub. Do you know how amazing that is?
@danwack In your commit, add (fixed #3) and it'll automatically reference this issue and close it.
how? like in the commit message?
Yep. Take this commit for example.
https://github.com/team178/oculus.js/commit/a875876ac3c8da98bdbe27ceca4ca35719648a9e
that was me btw
Create your own account on the driver station and setup git from there. Otherwise it says it was authored by RandomTeam178Member.
Or, who cares? Git blame is super broken, let's just not worry about it :)
Rob, it's important that we keep track of who makes what changes so we can consult them and ask about their code decisions. Otherwise we'll have this:
@gluxon then how are you #1 contributor? https://github.com/team178/CaptainFalcon/graphs/contributors Git blame is super duper mega broken and making separate accounts on each computer is too painful for now IMO
It has nothing to do with Git blame.
Also... I'm really not sure how those commits went through my account... Regardless, that actually helps to prove that members should use their own account. "Too painful" isn't really a reason not to do something.
@gluxon If you can come up with a solution for making it convenient for everyone to develop, I'm sure everyone would love to see it. :) But I'd prefer people focus their efforts on issue #2 as running the robot without implementing it means that we have to disable the safety interlocks for shooting during competitions.
Everyone clone and pull from their own computer or account logins? Isn't that logical and easy enough? There's time for issue #2 to be done. Having everything come in under your name is going to cause problems in the future.
@gluxon I (as an example) would prefer not to take the time to make an account on each and every computer because the only purpose it would serve is to put my (as an example) name on code. We wouldn't even have local temporary storage of changes that user accounts guarantee because maybe I (as an example) would like to switch computers while developing (or are pushed off by someone needing the computer for something else). Also, weren't you opposed to "ownership of code" a while back? @Programming Heads: maybe you guys should weigh in on this, it's not my choice after all. @PandaBlackAndWhitr :heart:
Also as for the issue this thread was made for (#3) I'd prefer we not have a field publicly exposed... of course, you guys can leave it as is, I don't mind too much
Dan: lel i dont care who commits I usually trust you not to be goons and delete everything Travis: I don't mind signing out and signing in. I think we should do it, but I don't feel its a big deal if we don't; I don't think it'll be that hard to track someone down who did someone wrong.
makeagif.com/wTqCyt
k bye we haz cror meeting
@ThatTreeOverThere Stash them on a different branch and commit as a WIP? There's multiple solutions for that issue. Doing that takes 1 minute at most. These aren't problems that haven't been solved before. In fact, they are problems Git is created to solve.
And there's a different between there being the one and only programmer that understands the code (which is almost all of our team history) and attaching your name with the code you write.
@danwack I created RandomTeam178Member for times of urgency and code needs to be pushed immediately. Otherwise, I don't think there's any reason why we shouldn't do this. @PandaBlackAndWhitr I'm really trying to get everyone to work like a real-world programming team would. I'm personally applying a lot of the things I've learned from working with Mozilla and Ethan Turkeltaub (old AV friend) here. It's valuable experience for working on programming in the future.
I really don't think this is that much of a burden to implement this. You kind of just have to learn you way around Git for 20 minutes and everything's set after that.
@gluxon As long as you make my accounts for me, I'm a-ok with this.
should not bypass intent system directly