Programmers on the Drive Team

[lark95]

Originally Posted by JamesCH95

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]

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]

Originally Posted by lark95

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]

Originally Posted by pntbll1313

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]

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]

Originally Posted by Woody910

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]

Indicators, indicators, and more indicators. There is a lot you can do with sensors, it also makes debugging a lot easier.

[AWoL]

Originally Posted by Caleb Sykes

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.

Originally Posted by JamesCH95

Why do you think that this is advantageous?

Originally Posted by lark95

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.

Originally Posted by JamesCH95

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]

Originally Posted by lark95

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]

Originally Posted by GreyingJay

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]

Originally Posted by AWoL

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]

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]

Originally Posted by arimb1999

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]

Originally Posted by AWoL

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]

Originally Posted by arimb1999

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.