![]() |
Programmers on the Drive Team
For all you programmers who are also driving this year, what are some things you added codewise to make playing the game easier?
|
Re: Programmers on the Drive Team
While I'm not necessarily on the drive team - we added a very simple button to scale our drivetrain speed down for slow maneuvering (e.g. lining up with the human player station). Pressing the trigger multiplies output to each motor controller by 0.75.
|
Re: Programmers on the Drive Team
In terms of how the robot drives, or the whole co-pilot/operator code? I am on the drive team, but I am the operator not exactly the driver. I do however, drive the robot a lot, so I know what I have to do to it to make it drive nice.
If you do not have some sort of PID / Gyro control on the robot for driving, get it. It really helps a ton with stabilization and driving in general. Almost anyone that picks up the control can drive it nicely with this kind of control on it. This year I am also thinking of adding a button to change the robot's front and back, depending on what we are doing (Our robot has a tote harvester on one side, and a claw on the other). In the end, it all depends on the driver and the robot. Every robot has different things it has to do either faster or more precise. |
Re: Programmers on the Drive Team
Not this year's programmer, but can definitely tell you some things that I've worked with the programmers to implement to make my drivers have a better experience.
Speed Select: 100% speed at no button press 50% speed at button 1 on both joysticks 25% speed at button 2 on both joysticks etc Position Select: Buttons on button panel push the lift to specified levels based on measurements and encoder PID crap that I'm too lazy to go into detail about but took them ages to implement. At least they figured out PID, I couldn't do it for crap. Since our robot has super simple movement that's about it. |
Re: Programmers on the Drive Team
We added a speed control for the drive motors on the controller (left trigger is 60% and right trigger is 40%), along with a filter on the controller joysticks to eliminate slight variations on the direction of the robot (basically to allow for perfect forward backward left right movement by eliminating a few degrees of difference from those directions)
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Our driver last year (still TBD this year) is the captain of programming this year. We have a very simple robot (4 actuators: H drive plus lift). He didn't feel that we needed to do very much with the slew driving; we have an arcade drive on our tank wheels and another joystick for strafing.
However, with no active intake and less than 1/4" tolerance to grab the side of the totes, pickup of game pieces takes a long time if being controlled from a distance away behind the polycarbonate. In addition to a camera which will both provide a driver feed and do some automated tote-finding, we have installed five sensors on the lift (four limit switches and an encoder), two rangefinders (distance to game piece or wall left and right), and four touch sensors (two curb feelers to find the scoring platform, and two on the lift face so we know wen we've touched a tote at both left and right ends). The practice 'bot is alternating between drive sessions and programming sessions to semi-automate pickup, stacking, and scoring motions. |
Re: Programmers on the Drive Team
While I am not a programmer I was the driver on my team from 2013-2014.
In addition to the button that slowed down the overall speed of the robot (I used 1/3, but it can be slowed down to a number of different variants, whatever works for you really) I also had 2 buttons that would slowly turn the robot left or right, but still allow you to drive full speed, this helped with lining up for the high goal/3 pt. goal in 2013 & 2014. In terms of ease of driving I had another 2 buttons that would spin the robot 180 degrees either left or right, holding the stick forward while doing this would allow the robot to drive around a radius. And lastly there was a button on my controller that would flip the axis of robot, so now driving with the back end of my robot was like driving forwards and vice versa. These buttons might not be necessary to every robot because it definitely depends on your strategy of the game and robot design but for us it made sense. That being said the more the season went on I found myself using these buttons less and less and eventually stopped using them altogether. |
Re: Programmers on the Drive Team
We added RGB LED strips on the sides of our elevator. They change color depending on what level our elevator is at so that we can clearly see our mechanisms height. It's pretty helpful! :D
|
Re: Programmers on the Drive Team
Working on an auto-pickup button. Otherwise, changing which side of the robot is the "front" based on which driver trigger is pressed.
|
Re: Programmers on the Drive Team
I'm not on the drive team, but I take it upon myself to make changes to the control scheme/add features to fit the individual driver's needs. We've added automation to the opening/closing of our intake based off of the stake of the intake's wheels, a "slow button" for the driver, and created an auto-stacking button for the manipulator.
|
Re: Programmers on the Drive Team
I'm the lead programmer and one of the drivers this year. I added in an automated program for our lifting device that utilized various limit switch sensors for different states. One can just hold down a button, and the lift will cycle itself appropriately based on the current state. So we can have one driver positioning for collection while the other driver simply holds down the button while totes are being collected. No need to manually control the lift and manually align totes for stacking!
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
1 Attachment(s)
Quote:
Code:
Edit: I attached a photo of how our roller limit switches were mounted. |
Re: Programmers on the Drive Team
Why did you guys decide on limit switches instead of encoders?
|
Re: Programmers on the Drive Team
I have a score button(for placing the totes) and I have control of the roller mechanism. I usually also put an inverse throttle trigger on there for myself(This was super useful last year)
Programming to your needs specifically is super useful |
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Three words: magnetic limit switches. Switched (rim-shot) to these in 2013 and have never looked back.
http://www.mcmaster.com/#magnetic-switches/=w8hmkk We used numerous magnetic limit switches, supplemented with encoders, to pre-program positions for our tote collector and to implement safety-interlocks on most of our robot's mechanisms. |
Re: Programmers on the Drive Team
i am primary driver this year, (not a programer) Really the only thing that our programer aded to the drive is a 50% slowdown on the drive for when getting rcs of the step. We are not even using a gyro on our mecnum drive this year. We had one that worked but i felt that it was just not needed. It almost made the drive feel like it was unnatural. The drive is so much more fluid without it.
On another note, last year i had a button to reverse the front and back of the bot. We shot one direction and picked up the other direction. It was a nice function to show off but it became disorienting to drive with, i always forgot witch way it was going to go if i had been stopped for to long. Never used it much. |
Re: Programmers on the Drive Team
One thing that our mentor team (Team 188) suggested we would do is add an override to our limit switches in case of failure during a match. We didn't think we would need it but literally the game right after putting the override into our code we ended up using it because of a gutsy move on my end trying to get as high as I could on our lift system which in return broke the limit switch.
So the lesson learned here is that always have a backup plan for any point of failure so that way you will always be prepared for whatever may happen on the playing field. |
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
http://www.wcproducts.net/sensors |
Re: Programmers on the Drive Team
Quote:
We've attached them with VHB or small screws, and they work well with ~1-2mm air gap between the magnet and the switch. When we have the robot un-bagged I'll see about getting a photo or two of them. |
Re: Programmers on the Drive Team
I'm the lead programmer, as well as the driver. I made our mecanum drive move the same speed in each direction :D
|
Re: Programmers on the Drive Team
We've added a few things to make driving easier, manual compressor off (in case of brown outs), ability to lock our swerves to front/back movement, auto line up with totes, ability to rotate around the stack, and were able to switch between robot and field centric.
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
A normal mecanum drive moves forwards/backwards at 100% speed, strafes at 50% speed, and moves at a proportional percentage at angles in between. With my code, our drive moves at the same speed in each direction, essentially handling like an omni-drive. Hope I explained it.
|
Re: Programmers on the Drive Team
Quote:
Is this a correct interpretation of what you did? |
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
This really comes into play if a team has less time to practice. Driver can develop the muscle memory needed to drive much faster. |
Re: Programmers on the Drive Team
A few people have touched on this point but I want to stress that it shouldn't matter if the drive team has programmers on it or not. The Programmers NEED to make everything as easy, intuitive, and efficient for the drivers as possible. The drivers are your customer here. The drivers NEED to tell the programmers anything/everything that would make their lives easier.
The idea that a programmer being on the drive team in some way makes any difference on how easy the robot is for the driver to control is just odd to me... |
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Our programmer wrote a code so our bot runs in a sort of auto-pilot mode during tele-op. They flip a switch, and everyone on the drive team folds their arms, sits back, and watches the bot go to work. Our HP still has to feed totes to the bot, sadly, so he still works.
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Indicators, indicators, and more indicators. There is a lot you can do with sensors, it also makes debugging a lot easier.
|
Re: Programmers on the Drive Team
Quote:
Quote:
Quote:
Now my actual reasoning behind that was when we were practicing, I was having trouble smoothly executing omni-drive-esque/swerve-drive-esque maneuvers (with both field centric and robot centric control) with the robot moving at different speeds when moving on different angles. Quote:
|
Re: Programmers on the Drive Team
1 Attachment(s)
Quote:
|
Re: Programmers on the Drive Team
Quote:
It's also convenient when the programmers are testing the robot(we have both drive team members on programming this year) that we can get the practice while the other sub teams keep working. |
Re: Programmers on the Drive Team
Quote:
For the same hypothetical mecanum drive, no feedback is used when setting wheel velocities. Instead, the joystick outputs are scaled as follows: Output x = joystick.X Output y = (joystick.y)/2 This causes the forward top speed to be slowed down so that the strafing speed is never exceeded in any direction. |
Re: Programmers on the Drive Team
Using mecanums and a 3-axis joystick often means you get a turning component when you don't want one. To correct this, there are two buttons on the joystick: one only uses the x-axis and the other only uses the y-axis.
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
|
Re: Programmers on the Drive Team
Quote:
The problem is that, for me and almost every driver I've talked to, you have to be focused in on the robot for the whole match. You need top be able to see if anything is going wrong that you need to fix, and the best way to watch for that is by looking at the robot rather than the smart dashboard. If you do have to make an indicator, make it large and bright. Make it toggle between two colors, rather than showing words, so that the driver can see it from his/her peripheral vision. Then make a second version that can be used for debugging instead, and leave the big colorful indicators for the competition. Looking down and reading wastes previous seconds and takes your attention from the field, where it should be. |
Re: Programmers on the Drive Team
Quote:
It made it really easy on the me and the secondary driver to drive. |
Re: Programmers on the Drive Team
We used 2 limit switches, one at the top and one a the base, so that at the click of a button, our lift can just rush to either the top or bottom. We had also used the triggers on controller that we have for highly adjustable speed control. Holding the left trigger all the way down gives a speed of 30%, holding the right trigger grants a speed of 100%, and a neutral speed of 65% is achieved when no triggers are held. Also, the speed interpolates based on how much you press the triggers, so if I hold the left trigger half-way down, then the speed would be halfway between 30% and 65%, and if I held the right trigger 87% down, then the speed would be 87% of the way between 65% and 100%. The speed applies to both the chassis and the elevator. Also, we have glued a Lifecam USB camera to a servo, which allows it to be controllable, as well as added two fixed positions that can be reached at the press of the button. One of these positions, which aims the camera down at our claw, is snapped to instantly when the 'A' button is pressed, while the other position, which aims the camera into the distance, is snapped to instantly when the 'Y' button is pressed. We also have macros for fixed elevation and declination. So If I press a button, our claw will lift by the height of exactly one tote, and the opposite occurs when another button is pressed. Finally, we also have two buttons dedicated for exact 90 degree turns in either direction, using a gyro as a sensor.
|
Re: Programmers on the Drive Team
Probably the most helpful thing we did for me this year was automated pickup. If I drive into the totes, it picks it up, and if I hold a button it drives until the robot is square with a tote, then raises. Makes our team 200% more efficient.
|
Re: Programmers on the Drive Team
Quote:
|
| All times are GMT -5. The time now is 15:24. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi