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)

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.


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