|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Here is a quick demo... I have changed how the magnitude is computed in this demo. It blends from 0.87 when theta is 0 to (1/(pi/2)) when theta is 90. Let me know what you think.
![]() http://youtu.be/NKd6inx9OH8 Last edited by JamesTerm : 29-07-2013 at 21:57. |
|
#2
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
I really like this demo, it does a good job of explaining the jist of how "Culver drive" works. I'll leave the magnitude computation change assessing to Andrew.
If you look up at my name you'll see that the second one is "Culver." I just wanted to explain why this is named after me (I'm not egocentric, I promise.) Last summer I picked up a controller to drive the 2012 robot and was very disappointed by my inability to do arcing turns using Cheesy drive. Walking out of Chrysler that evening I explained to Andrew what I would rather have -- point the stick forward and move it around the way you would if you were driving a car with one hand on 12o'clock, keeping the throttle the same. Andrew coded it from there and after we tested it on a robot and liked it we were trying to think of a catchy name for it (WASPdrive was already in development and named at this point.) We couldn't think of anything and Andrew already had it named after me in the code at this point so, much to my displeasure, left it "Culver drive." In any case, our driver really liked it this year and we'll probably be using it again next year. Cheers, Bryan |
|
#3
|
|||||
|
|||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
The demo is interesting.
The question of how to deal with the quick turns comes up a lot, not just for Culverdrive but also for Cheesy vs Halo drives (I've usually defined them as the same algorithm, but the switch from including Throttle to not including throttle is done via a button in Cheesy and when throttle = 0 in Halo). One design logic is that the quick turn button is an additional button that can be optimized out, the other is that with the button it's possible to slow down to 0 speed while in an arc turn without suddenly spinning. We initially used the design logic that the enablement curves would sum to 1 so as soon as the driver exceeded 95 degrees it would pull throttle out of the equation but the rest of the result would remain the same, to allow turning in place without the throttle. That is the 'alternate raw' implementation, which is actually the original. The current raw implementation is more similar to the original cheesy drive, and we just switch based on quick turn switch. There's still more optimization we can do. I like the interp curve function because I can plugin a set of points and map the curve as I want, however nonlinear or strange it is, without finding a mathematical way to represent it, and it's not that inefficient for relatively small tables. |
|
#4
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
That's pretty cool. I like the idea of automatically switching to quick turn after the driver pushes the stick far enough to the side. This is similar to a team who used an actual steering wheel to control their robot one year!
How do your drivers feel about this setup? In the past we've tried some similar things (cheesydrive/right stick steering wheel), but our drivers preferred a tank drive setup, claiming that the cheesy drive was better for driving around an empty field, but when in pushing matches and having to line up, tank drive was better. Also, do you know if anybody has come up with a way to use these style algorithms on swerve/meccanum, or with the sort of drive that 148 used in 2010 (I forget what it's called). |
|
#5
|
|||||
|
|||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
-Drivers did not complain. I personally loved it, and I drove a Halo style drive in 2012. High speed driving performance is WAY better than with a tank setup, and alighment is easier by optimizing it when the quick turn button is pressed.
--Driving with a steering wheel is not uncommon, we tried to emulate it with this, as we believe it is a superior HMI to a two-stick tank drive. -Purely subjective driver analysis has shown that it's MUCH easier/faster to master the graceful high speed arc maneuvers we want with a culver or cheesy drive than the two-stick tank. We actually have a lot of code in our 2011 robot (two stick tank) to modify the inner wheels to arc nicely when the driver lets go of one stick to turn, but that code was quite a bit of work to develop fully and not a good solution, since it really makes driving three-state (both sticks same direction, one stick full one stick zero, both sticks opposite direction) and the driver bumps it on and off a lot for jerky turns. -Judges loved it, noted 'Culver Drive' in championship award speech -We used a Halo drive with a slide drive in Vex (what 148 in 2010 had, except without the droppable traction wheels and bump crossing ability), we just used the left stick for translation and right stick for rotation. Since the left/right wheels control steering, we simply ran a normal Halo drive and mapped the slide wheel to left X (left Y was throttle for left/right wheels, right X was wheel). This ran three Vex robots and all drivers loved it for that drivetrain, one was able to pick up some 'fancy' moves like circling around a point in front of him or spinning around off a defender extremely quickly. For a mecanum, I would find theta/R of both sticks, and use left theta for translation angle, left R for throttle, and right stick would determine the rotation as it does now. Then you would just have to solve the mecanum math and warp everything back into the +-1 range nicely. |
|
#6
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Quote:
I should add that I have incorporated the culver drive into some simulated swerve and nona drive code and they work great because this is solving the x-axis method, and passes the value as if it was the x-axis. Quote:
![]() |
|
#7
|
|||||
|
|||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Quote:
-We do like velocity controls as well, but we haven't implemented them since 2011. I think that would be a logical improvement to this system. -That said, a simple PI controller to speed does not have a fast enough response time for drivetrain usage. We did this in 2011 and turned the gains WAY up for fast response, and oscillations weren't very good, but it worked. -A better solution is one of the better speed control algorithms designed for shooter flywheel speed control (2012 was especially big on this, 2013 less). We ran a PI-FF algorithm with a feed forward equation (now we would just use a table), which is an improvement |
|
#8
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Ah ha... now it all makes sense.
Mechanical engineers like to solve the controlling aspects of the drive and leave little for software to do... they are happy with just raw voltage input from the controls... and from this whatever non-intuitive issue arise it is left for the driver to get use to them and overcome them. This goes against the mentality of a software engineer which figures out intuitive solutions for all users to be able to pick up and use. If we cannot make it intuitive people will not buy our stuff. Quote:
![]() |
|
#9
|
|||||
|
|||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Those graphs definitely show improvement over the years.
I've always liked to feed forward as much as possible for best transient performance. The P-I-FF design feeds forward the steady state output (FF), corrects for steady state errors with I, and handles transients with P (what the D term in a 'normal' position PID would do). FF can be implemented as a math model, curve fit, or lookup/interpolation table. I agree that mechanical engineers tend to solve problems mechanically, as a controls engineer I disagree with this approach. |
|
#10
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Quote:
As far as the open field maneuvers- I love it. It allows me to change directions quickly, which often lets me ditch defenders without shifting into low and slowing down. The arcing turns and quickturns were extremely useful when navigating around the pyramid, and I could use either depending on the attack angle. In regard for lining up, I tend to use quickturn (I use it more often than Palardy and Culver designed it for, but it works) paired with a hard stop on the arm to zero against. At the beginning of the season before we installed the hard stops it was pretty squirrely to line up, but that has improved since I've gotten more comfortable with it. With pushing matches, I usually just shift into low and use quickturn to spin out of them. Overall, it's a pretty flexible drive system. As a newer driver, I loved that it made me less choppy and inconsistent. I'm definitely planning on using it again next year. |
|
#11
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Quote:
![]() I have made a graphical representation of 3 different setups that try to illustrated the distribution. The one on the right is halo drive with just x and no y, and the top left is the culver theta * r where r is just magnitude with no scale. The bottom left is the blend of 0.875 to (1/(pi/2)=.64ish). The green tries to highlight the smaller numbers and how they are spread out. The spread of numbers between the 1.0 magnitude and the halo are virtually identical for the precision workflow (i.e. when using the max y stick up)... This means the actual benefit of precision (using 1.0) is a mechanical solution and could be accomplished using the halo drive. It does however have brighter red and blue intensity on the sides this is because when you get there your range will exceed past 1.0 to 1.57 (half a pi). The bottom one will keep the range 0-1 intact for halo while spreading out the centered area for Culver. This makes it both mechanical and functional benefit of precision. This suggestion makes the Y component a bit more interesting in that when Y is centered... it is identical distribution as the halo graph (therefore a perfect fit for anyone's driving system), and then when Y is used for Culver steering... the x distribution is greater for precise turning and then curves down quick to meet up with 1.0 at the end. I hope this makes sense... I can see a work flow solution to use halo drive for quick turns and culver drive for precise turns without need of a button. Quick turns in this context are in terms of what the x axis submits to another function... this means it is possible to use this for some other kind of control (e.g. arm) when it is broken down to just this functionality. I'll save the actual drive implementation for a separate post. |
|
#12
|
||||
|
||||
|
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)
Quote:
Thanks for the feedback on the demo... (Thanks Palardy and Magnets too). Sometimes I feel like no one appreciates the effort and thought that goes into this... so it means a lot. ![]() |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|