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?

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.

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.

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.

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)

What sort of PID do you use for drive train?

This year we are using the Talon SRX’s built in PID that takes input from an encoder (4 Six Inch Vex Pro Mecanum Wheels, 1 encoder connected to each motor and then connected directly to the talon).

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.

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.

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! :smiley:

Working on an auto-pickup button. Otherwise, changing which side of the robot is the “front” based on which driver trigger is pressed.

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.

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!

How are you ensuring the lift mechanism hits limit switches? We’re having trouble doing so.

We have limit switches on our lift as well, actually four. We used some long-lever switches from Jameco and bent the arms up about 45 degrees one needle-nose-plier width beyond the end of the switch, and down about 90 degrees another plier width down. It ended up looking something like this:

 
   _________/\
  ┌───────┐   \
  │       │    \
  └───────┘

We mounted this inside our lift channel beside the place where our lift plate passed. As the plate reaches the switch, it pushes back on that 90 degree bend, activating the switch. The long lead at the end keeps the lift from jamming the switch on the return stroke, which was a problem we had with rollers that weren’t precisely aligned.

Edit: I attached a photo of how our roller limit switches were mounted.





Why did you guys decide on limit switches instead of encoders?

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

Interesting. That’s an eloquent solution, our original idea was something like that. Thank you!

Three words: magnetic limit switches. Switched (rim-shot) to these in 2013 and have never looked back.

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.

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.