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 03-03-2015 22:43

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?

NWChen 03-03-2015 23:13

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.

sergioCorral842 03-03-2015 23:19

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.

xXhunter47Xx 03-03-2015 23:19

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.

Aaron (Awe-Sum) 03-03-2015 23:27

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)

TimTheGreat 03-03-2015 23:30

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by sergioCorral842 (Post 1453153)
If you do not have some sort of PID / Gyro control on the robot for driving, get it.

What sort of PID do you use for drive train?

sergioCorral842 04-03-2015 00:55

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by TimTheGreat (Post 1453166)
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).

GeeTwo 04-03-2015 08:13

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.

Damiaen_Florian 04-03-2015 08:48

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.

TylerStaudigel 04-03-2015 11:03

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

NHoffmann 04-03-2015 12:50

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.

Oromus 04-03-2015 16:23

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.

AutoBotAM 05-03-2015 18:48

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!

Ozuru 05-03-2015 23:28

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AutoBotAM (Post 1454159)
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 06-03-2015 00:35

Re: Programmers on the Drive Team
 
1 Attachment(s)
Quote:

Originally Posted by Ozuru (Post 1454270)
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:
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.

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?

lark95 12-03-2015 10:15

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by JamesCH95 (Post 1456863)
Why do you think that this is advantageous?

I would thinks that this would be better because it provides all the axis of motion with the same proportion. This gives a much more consistent rang of motion needed to get the same motion.

This really comes into play if a team has less time to practice. Driver can develop the muscle memory needed to drive much faster.

pntbll1313 12-03-2015 10:22

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...

JamesCH95 12-03-2015 10:35

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by lark95 (Post 1456874)
I would thinks that this would be better because it provides all the axis of motion with the same proportion. This gives a much more consistent rang of motion needed to get the same motion.

This really comes into play if a team has less time to practice. Driver can develop the muscle memory needed to drive much faster.

This falls into the 'we geared are transmissions too fast, but it's okay because we slowed them in code' fallacy. It cripples the drivetrain's performance artificially. I've never had a driver that couldn't immediately deal with the difference in speed with mecanum.

GreyingJay 12-03-2015 11:28

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by pntbll1313 (Post 1456877)
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...

You are right that what it boils down to is that the drivers need to talk to the programmers and vice versa. When it's one guy doing both then it's easy to have him code up exactly what he wants.

Woody910 12-03-2015 14:26

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.

lark95 12-03-2015 14:59

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by Woody910 (Post 1456981)
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.

That is impressive. Does it move the stack to the platforms or does it just make the stack?

Skyehawk 12-03-2015 17:29

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.

AWoL 13-03-2015 06:00

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by Caleb Sykes (Post 1456797)
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?

Eh, close enough. The effect is the same. My code actually has more to do with scaling the speed by the amount of joystick input on the x axis.

Quote:

Originally Posted by JamesCH95 (Post 1456863)
Why do you think that this is advantageous?

Quote:

Originally Posted by lark95 (Post 1456874)
This really comes into play if a team has less time to practice. Driver can develop the muscle memory needed to drive much faster.

Funny that you say that as I think that we probably have the some of the most time for driver practice, and we also put a lot of effort into it, building a full practice field and trying to simulate the most realistic practice matches possible. We end up having about four weeks of practice with our practice bot after the end of build season.

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:

Originally Posted by JamesCH95 (Post 1456882)
This falls into the 'we geared are transmissions too fast, but it's okay because we slowed them in code' fallacy. It cripples the drivetrain's performance artificially. I've never had a driver that couldn't immediately deal with the difference in speed with mecanum.

Well we geared them exactly for the strafing speed we wanted, so we do attain full output through the motors when moving laterally. As for the actual driving reasoning...see my comments above.

Woody910 13-03-2015 08:20

Re: Programmers on the Drive Team
 
1 Attachment(s)
Quote:

Originally Posted by lark95 (Post 1457003)
That is impressive. Does it move the stack to the platforms or does it just make the stack?

Our bot spans the area from the Human Player Station to the closest Scoring Platform, and the stacks are formed within the bot, and moved through the bot to the scoring platform without moving. There's a picture to help you see and understand.

Lij2015 13-03-2015 09:34

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by GreyingJay (Post 1456892)
You are right that what it boils down to is that the drivers need to talk to the programmers and vice versa. When it's one guy doing both then it's easy to have him code up exactly what he wants.

The only true advantage it gives me is that if I have a problem I don't need to try communicate what it is to anyone(sometimes it can be hard to explain), I just go and fix it.

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.

Caleb Sykes 13-03-2015 09:48

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AWoL (Post 1457185)
Eh, close enough. The effect is the same. My code actually has more to do with scaling the speed by the amount of joystick input on the x axis.

Let me try again then:
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.

Ari423 14-03-2015 11:40

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.

JamesCH95 15-03-2015 18:53

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by arimb1999 (Post 1457492)
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.

Not if you buy a quality 3-axis joystick (I used to be skeptical of this too). We bought two Thrustmaster T16000m joysticks this year and they are awesome. It seems silly to me to spend thousands of dollars on registration and building the robot only to use very inexpensive controllers to drive it!

JamesCH95 15-03-2015 18:58

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by AWoL (Post 1457185)
Eh, close enough. The effect is the same. My code actually has more to do with scaling the speed by the amount of joystick input on the x axis.




Funny that you say that as I think that we probably have the some of the most time for driver practice, and we also put a lot of effort into it, building a full practice field and trying to simulate the most realistic practice matches possible. We end up having about four weeks of practice with our practice bot after the end of build season.

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.



Well we geared them exactly for the strafing speed we wanted, so we do attain full output through the motors when moving laterally. As for the actual driving reasoning...see my comments above.

Thank you for the reply. I don't agree with your reasoning (I wouldn't want to do that on one of our robots), but I understand it.

mega900997 15-03-2015 19:00

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by arimb1999 (Post 1457492)
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.

What you can also do is instead of a 3-axis joystick, use an Xbox controller. You have x-axis/y-axis on 1 stick and turning on the trigger. The only problem you then have is potentially getting a strafe when you don't want it, but we found that it's a lot easier to drive mecanum with a controller than with a 3-axis joystick.

AWoL 15-03-2015 19:10

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by JamesCH95 (Post 1457872)
Thank you for the reply. I don't agree with your reasoning (I wouldn't want to do that on one of our robots), but I understand it.

Yup, no problem. I also forgot to mention that we do use the full forwards speed of the motors during autonomous as to complete a triple-stacked tote set in 15 seconds, and I also have a button on my controller that allows me to use full power, which is mainly for getting off of noodles (or destroying them).

Pretzel 15-03-2015 19:19

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by Skyehawk (Post 1457052)
Indicators, indicators, and more indicators. There is a lot you can do with sensors, it also makes debugging a lot easier.

While indicators may make debugging easier, I can count on one hand the number of times I looked at the smart dashboard during the last six competitions I drove for, including the Utah regional this last weekend (where I never looked at it). The only times I used it were to check in 2014 twice if we were in low gear or if two jaguars had browned out instead. I then found it much more efficient to just push my shifter button for high gear to test it.

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.

lark95 15-03-2015 20:03

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by Pretzel (Post 1457877)
While indicators may make debugging easier, I can count on one hand the number of times I looked at the smart dashboard during the last six competitions I drove for, including the Utah regional this last weekend (where I never looked at it). The only times I used it were to check in 2014 twice if we were in low gear or if two jaguars had browned out instead. I then found it much more efficient to just push my shifter button for high gear to test it.

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.

I have to agree that a driver must be 100% focused on the robot, and wont have the time to look at the computer screen. Bet there is one more way to have indicators and that is to have them on the robot. Last year we had a catching and shooting bot. To catch we lust ran the shooting wheels backwards. To aid the drivers, and human players that would be throwing into the bot, we aded led's 360 degrees around our bot. When they were both blue and red it could catch. We also had a laser for distance sensing. If we were in the right range to make the shot the led's turned off, when we were to far they were red and when we were to close they were blue.
It made it really easy on the me and the secondary driver to drive.

Hsifeulbhsifder 23-03-2015 19:51

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.

TimTheGreat 23-03-2015 23:08

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.

Ozuru 23-03-2015 23:11

Re: Programmers on the Drive Team
 
Quote:

Originally Posted by TimTheGreat (Post 1461388)
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.

Mind sharing how you're going about detecting the majority of this? I could understand some sort of touch-based sensor for the automated tote pickup but that might be iffy and would require a large detector. How are you squaring yourself up with a tote?


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