|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
Hi all,
Today we mounted our shooter/pickup mechanism onto our robot. The way we have it set up, it starts in a starting position, and in autonomous rotates to shooting position. Throughout the match, we will be rotating between shooting and pickup positions. We found that that the robot is cumbersome to move in any position but the starting position, and since we will almost certainly not be finishing the match in that position, our drivers would like a way to move the robot back to starting position before attempting to move the robot off the field. It would be difficult for us to put a mechanical release on our tilt mechanism, so we were brainstorming different ways to accomplish this. The best idea we came up with was a "control board" of sorts on the physical robot that could manipulate our tilt motors through disabled-mode code. We would obviously design and implement it in a way that it has minimal (we're talking probably a key switch to activate the board) chance of accidentally activating. We browsed the rules and Q&A, and there are no rules specifically prohibiting this, or any robot movement during "disabled" mode, autonomous or human-controlled. We do see disabled defined in the glossary as "a state in which a ROBOT has been commanded by the Driver Station to deactivate all outputs," but this does not lay the problem to rest for some members of our team (they argue that we aren't prohibited to sudo the robot into listening to our movement instructions for our intended purpose.) Has anyone had any experience with questioning this definition in years past? We could not find a similar question in this year's Q&A, but we have a question pending. We just wanted to see if any of you guys could be any faster since it's so close to bag&tag. Thanks! ![]() Last edited by dc74089 : 15-02-2014 at 16:44. |
|
#2
|
|||||
|
|||||
|
Re: On-Robot Controls
What exactly is keeping you from backdriving the motors that control the tilt? It's really simple to do that, generally speaking, thus, no control needed. If you've got a pneumatic cylinder as a locking mechanism, those are pretty trivial to manually activate via their solenoids.
|
|
#3
|
||||
|
||||
|
Re: On-Robot Controls
Eric,
The roadblock on that path is that we're using a window motor driving a lead screw, which is almost impossible to turn by hand. That was something we considered, but decided we couldn't do without changing our design. Thank you for the alternative though! |
|
#4
|
|||||
|
|||||
|
Re: On-Robot Controls
You will find it impossible to cause the cRIO to activate any motors when the robot is not enabled. That's a safety feature that cannot be bypassed by any code you can write.
My suggestion is that you provide a way to disconnect the motor from its speed controller and then connect it to a separate battery through a manual switch. |
|
#5
|
|||
|
|||
|
Re: On-Robot Controls
Quote:
Honestly I don't understand why it is a problem to have manual control that is inaccessible unless purposefully controlled for safe travel from the field. I don't know why there can't be a blue box allowance of some sort to R54 to allow for safe transport. I think an inspector could judge whether a manual switch would pose a hazard or not. Think of a goalie robot with a ten foot arm extended going through a door to get to the pits... To the OP, I think it is against the rules since you are controlling an actuator rather than the robot computer per R54. |
|
#6
|
|||||
|
|||||
|
Re: On-Robot Controls
Quote:
Quote:
Once the robot is off the field and on its cart, and somewhat out of the way, there should be no issue with tethering up quickly, enabling the robot, and bringing the problematic part, whatever it is, in for transport to the pits with power off (or on, if you so choose). |
|
#7
|
|||||
|
|||||
|
Re: On-Robot Controls
Maybe you can remove the locking pins on the window motor to allow easier back drive on the screw?
In the past I have secured a bolt head on the end of my lead screws to drive it with a socket wrench/drill before removing the robot from the field. |
|
#8
|
|||
|
|||
|
Re: On-Robot Controls
I get all that, but I would like to see R53 apply to just playing the game not overall. I know you will disagree with that and say it is against the rules, and I am totally aware that it is. Hopefully next time you can use a little less attitude... I said in my own post that manual controls were against the rules (per R54 and as you pointed out R53) I just don't agree with the rules.
I would like to point out that I have never been to an event where you aren't quickly shuffled off the field and out the door to the pits. Our rookie year we had an arm that had to be tethered to pass though a door that we were not allowed to retract at both of our district events. We ended up having to tip the robot on the cart to keep the event staff happy. To get around a very unsafe forced method, a limit switch by the relay made the arm retract. Nobody said a thing, but I now know it was illegal. In response to the separate battery and switch idea, check R31. |
|
#9
|
||||
|
||||
|
Re: On-Robot Controls
I dont know if this is even legal or would work, but what if you had a small laptop on your robot that had the ds program on it and a game-pad attached, and connected directly to the router to move parts of the robot while your on the field? This is just an idea, I have no idea on the legality or workability of this.
You could set your testing code to only move the robot into the stowed position so you wouldn't have to worry about the full code being run, just select test on the ds. Last edited by Kevin Selavko : 15-02-2014 at 22:17. |
|
#10
|
|||
|
|||
|
Re: On-Robot Controls
I think R30 blue box would make that a issue... But the wrench and lead screw idea could work, as long as it doesn't damage anything in the plastic gearboxes.
|
|
#11
|
|||||
|
|||||
|
Re: On-Robot Controls
Quote:
It's workable, sure, but it's not legal under T15. As soon as you're off the field and on the cart, though, you're fine. But we're not talking about that right now. If I was to make a suggestion... Build or buy some long handles that hook into the frame of the robot safely. Ideally, those would allow you to pick up the robot and get it off of the field without having to deal with the shooter being tilted back, then you can tether up as soon as you're off to deal with the shooter. |
|
#12
|
|||||
|
|||||
|
Re: On-Robot Controls
4.7.2 R30
The integral mechanical and electrical system of any motor may not be modified. Motors, servos, and electric solenoids used on the ROBOT shall not be modified in any way, except as follows: A. The mounting brackets and/or output shaft/interface may be modified to facilitate the physical connection of the motor to the ROBOT and actuated part. B. The electrical input leads may be trimmed to length as necessary. C. The locking pins on the window motors (P/N: 262100-3030 and 262100-3040) may be removed. |
|
#13
|
|||
|
|||
|
Re: On-Robot Controls
Quote:
|
|
#14
|
|||
|
|||
|
Re: On-Robot Controls
I would suggest a connector inline to the motor that you could disconnect and plug into a battery. The circuit would be unmodified while playing, also if you might want a slower speed you could plug in a lower voltage batter to move the mechanism at a more reasonable speed.
|
|
#15
|
|||
|
|||
|
Re: On-Robot Controls
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|