pic: Uber 3.0

[AdamHeard]

Originally Posted by MattC9

Sorry, I'm not a programmer so I don't have the software to view it (CAD actually takes up most of my computer) but i will have one of my guys look at it and explain it to me, but thanks for sharing!!

You have the software to view it, the type of code they (and most of industry) uses is just text.

[Wildcat]

is that thing rockin a V8?

[AustinSchuh]

Originally Posted by NickE

Check out the drive code in this: http://www.chiefdelphi.com/media/papers/2397. For more information, talk to Austin, Tom or Kiet would be your best bet.

Nick

The code definitely makes a huge difference. The drive code in that paper ran on 2 of the robots on the winning alliance last year. It helps make a 16 fps robot controllable and fluid.

[ratdude747]

I am going to differ from the crowd and say that the high gearing is OK.

here's what you do:

in the code, use a button/toggle to scale back the joystick inputs to create a "virtual gear". you can also route this to a throttle if you are using joysticks instead of a gamepad. my team has a demo bot made from an IFI kit chassis and the 2011 kit cimlple gearboxes... we had to make the output cog larger to fix chain tenison issues and as a result, we had to map a scalar to the left joystick throttle (in arcade mode, the only stick) since by default it was too fast.

this year's competition mecanum used a "turbo trigger" to give the motors full power, otherwise, the joysticks were scaled back.

the only other note is you will have a lot less torque but depending on what you want to do with it, this may be more or less of an issue.

[apalrd]

Two comments:

Originally Posted by ratdude747

...in the code, use a button/toggle to scale back the joystick inputs to create a "virtual gear"....

While this does work, you are now limiting your motors to a max of a certain power output (since you can never feed them full voltage)

We implemented something like this to create an automatic "1.5" intermediate gear, of around 9 ft/sec (low is usually ~5.5, high 12) which was automatically used when the elevator was above the score-mid height (and another "1.7" intermediate gear of about 10-10.5 when the elevator was in the score mid range). However, we implemented this as a speed request instead of a power request, so the closed-loop speed control could give the motor full power to accelerate or push. Why? Because just blindly limiting motor power gives little benefit (why not just change the gear ratio to make it correct? For a chain drive it takes a few sprockets from Andymark to correct an error that should've been found when you did the initial drivetrain math). However, limiting speed but not power allows the speed control to give full power to accelerate, and we found it useful when scoring.



Also, while I like the cheesy poofs code (and 33 re-implemented it for an off-season project), I still don't get why the code Nick pointed to (cheesy poofs 2010) has a switch for QuickTurn vs SpeedTurn. Why not just do quicktunrs when the throttle is at 0 and speedturns the rest of the time?

That said, the cheesy drive algorithm is very solid.

[AustinSchuh]

Originally Posted by apalrd

Two comments:
Also, while I like the cheesy poofs code (and 33 re-implemented it for an off-season project), I still don't get why the code Nick pointed to (cheesy poofs 2010) has a switch for QuickTurn vs SpeedTurn. Why not just do quicktunrs when the throttle is at 0 and speedturns the rest of the time?

That said, the cheesy drive algorithm is very solid.

That switch is partially that way because it has always been that way. We have found that particular choice to work well, and have no desire to change it.

Say you want to turn 5 degrees. If the robot is still in "SpeedTurn" mode, you can slam the wheel to one side, and it won't move. Then, you can tap the quick turn button. This will cause it to send +- 1 to the wheels for a very short amount of time. The net result is a turn by a small amount without having to steer carefully. We find this rather useful. This move is a lot harder to do if you try to turn the wheel with quickturn already engaged.

I also like being able to send any set of powers to the left and right wheels. So, the "SpeedTurn" algorithm won't let you send +1, -0.1. But, if you hit quickturn, you now can send that set of values out. This can't be done if the robot does it automatically for you.

Also, I am a big fan of devices having a psychologically linear response*. Having a device switch modes without a command from the user doesn't fall into that category for me. If you are driving slower and slower, and have the wheel in a full turn, once you stop applying throttle, the robot will stop. If it switched into QuickTurn automatically, it would instead suddenly start to spin. That rubs me the wrong way.

If you have any more questions about why the code does what it does, fire away. I like to believe that every line of code in the drive algorithm is there because it is necessary and helps handling.

(I have heard that the algorithm for QuickTurn isn't quite right in that code. It should be that quickturn does left = throttle - turn; right = throttle + turn; rather than setting throttle = 0.)

*It doesn't have to actually be linear by the technical definition. The driver should feel like turning the wheel twice as far turns twice as much, or the elevator moves twice as fast, or etc. It may not actually be that 2x the wheel moves 2x as fast, but if the driver feels that way, he/she will be able to control it better.

[lemiant]

What did you do to get such a good render?

[kajeevan]

I just used inventor studio, very quick.