Programmers on the Drive Team

[Ozuru]

Originally Posted by AutoBotAM

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.

[GeeTwo]

Originally Posted by Ozuru

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.

[TimTheGreat]

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

[Lij2015]

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

[Ozuru]

Originally Posted by GeeTwo

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.

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

[JamesCH95]

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.

[Shaif]

Originally Posted by JamesCH95

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.

Can you post a picture of them on the robot?

[JamesCH95]

Originally Posted by Shaif

Can you post a picture of them on the robot?

I'm sorry, I don't have any decent close-ups of the switches we've used.

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.

[Gregor]

Originally Posted by JamesCH95

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.

We love WCP's hall effect sensors. Light, cheap, and very easy.

http://www.wcproducts.net/sensors

[lark95]

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.

[AWoL]

I'm the lead programmer, as well as the driver. I made our mecanum drive move the same speed in each direction

[ShinyShips]

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.

[Caleb Sykes]

Originally Posted by AWoL

I'm the lead programmer, as well as the driver. I made our mecanum drive move the same speed in each direction

Can you describe in more detail what you mean by this?

[AWoL]

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.

[Caleb Sykes]

Originally Posted by AWoL

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.

For a hypothetical mecanum drive, top speed in the forward direction is 10fps, and top speed in the strafing direction is 5fps, and at other angles the top speed is between these two speeds. With your code implementation, feedback is used to assure that the robot's top speed never exceeds 5fps, regardless of which angle the robot is moving.

Is this a correct interpretation of what you did?