Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Programmers on the Drive Team (http://www.chiefdelphi.com/forums/showthread.php?t=135439)

TimTheGreat 06-03-2015 16:49

Re: Programmers on the Drive Team
 
Why did you guys decide on limit switches instead of encoders?

Lij2015 06-03-2015 17:24

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

Ozuru 09-03-2015 11:49

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by GeeTwo (Post 1454306)
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:
Code:


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

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 09-03-2015 12:15

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.

lark95 09-03-2015 12:28

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.

Shaif 09-03-2015 13:20

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.

Shaif 09-03-2015 13:23

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by JamesCH95 (Post 1455466)
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?

Gregor 09-03-2015 13:29

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by JamesCH95 (Post 1455466)
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

JamesCH95 09-03-2015 13:54

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by Shaif (Post 1455514)
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.

AWoL 10-03-2015 22:42

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

ShinyShips 10-03-2015 23:44

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.

Caleb Sykes 11-03-2015 00:57

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AWoL (Post 1456289)
I'm the lead programmer, as well as the driver. I made our mecanum drive move the same speed in each direction :D

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

AWoL 12-03-2015 00:23

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.

Caleb Sykes 12-03-2015 00:42

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AWoL (Post 1456793)
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?

JamesCH95 12-03-2015 09:50

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AWoL (Post 1456793)
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.

Why do you think that this is advantageous?


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