Go to Post Could you explain this concept of a break from FIRST? Did my wife put you up to this? - Gary Dillard [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 26-07-2013, 18:40
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

The alternate vs normal raw mode is interesting. It was our method of removing the 'quick turn' switch, but we decided we liked the switch better.

In any case, the Radius component should be active from 0 to 90 degrees, plus a little for driver forgiveness. R allows us to return to 0 when the stick is centered, and the math works out such that you can drive it like a halo/cheesy drive if you want (although that's not quite ideal, the math works out the same). I am aware that above 90 slightly more turning power is possible, but I didn't really care. I also probably mistyped the radians to degrees, I actually used 180/Pi in the LV implementation and didn't precalculate it.

The initial ('alternate') raw implementation was designed to provide 'quick turn' functionality (steering without throttle for turn-in-place moves) by allowing the driver to move the stick in a fairly binary way around the bottom of the stick bounds (near +-180). It did not use theta at all (except for the enablement curves). We did not like this behavior, and decided to use the 'quick turn' button to switch.

It's interesting to see some SW design choices you made in your implementation.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Reply With Quote
  #2   Spotlight this post!  
Unread 26-07-2013, 21:15
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

Quote:
Originally Posted by apalrd View Post
In any case, the Radius component should be active from 0 to 90 degrees, plus a little for driver forgiveness. I am aware that above 90 slightly more turning power is possible, but I didn't really care.
Ok... the key here is anything above 90 you didn't care... the original code reflects how I illustrate in this diagram below... so if the user went above 90 it would start to drop back down to 0 like this:
..........0
....-45.....45
-90.....+.... 90
....-45.....45
...........0

here is that implementation using atan2;

Code:
	//Find arctan of wheel stick relative to vertical (i.e. swap the x and y components)
	const double theta = atan2(wheelx,fabs(wheely));

	//Find the magnitude of the wheel stick
	double r = sqrt(((wheely * wheely) + (wheelx * wheelx)));
This should have identical functionality to what you have written... assuming this is how you intended to do it. It is a great idea and can offer forgiveness if user accidentally goes past 90... or if they don't want to push up it would still work if the stick Y was accidentally done below center.

Now then assuming this is true... both calls to interp_2d() are no longer needed as they will always return 1.0. Especially the Radius Enablement curve. So really the theta and r (magnitude) are the heart of the culver drive. Just using these by themselves can be a nice sweet substitute for anyone's function that takes an x-axis. I'll give this a shot in our drive and perhaps post it on you tube this weekend... the other cool thing is doing it like this... after obtaining the normalized value (i.e. theta * r )... it can be used with Ether's equations for even greater control of the distribution of the curve.

Here's a little snip of that...
Code:
if (AnalogEvents)
{
	//Now to use the attributes to tweak the value
	//First evaluate dead zone range... if out of range subtract out the offset for no loss in precision
	//The /(1.0-filter range) will restore the full range
	
	double Temp=fabs(Value); //take out the sign... put it back in the end
	Temp=(Temp>=key.FilterRange) ? Temp-key.FilterRange:0.0; 

	Temp=key.Multiplier*(Temp/(1.0-key.FilterRange)); //apply scale first then
	if (key.CurveIntensity<=1.0)
		Temp=key.CurveIntensity*pow(Temp,3) + (1.0-key.CurveIntensity)*Temp; //apply the curve intensity
	else
		Temp=pow(Temp,key.CurveIntensity); //apply the curve intensity

	//Now to restore the sign
	Value=(Value<0.0)?-Temp:Temp;

	std::vector<std::string>::iterator pos;
	for (pos = AnalogEvents->begin(); pos != AnalogEvents->end(); ++pos)
		m_controlledEventMap->EventValue_Map[*pos].Fire(key.IsFlipped?-Value:Value);
}

Quote:
Originally Posted by apalrd View Post
R allows us to return to 0 when the stick is centered, and the math works out such that you can drive it like a halo/cheesy drive if you want (although that's not quite ideal, the math works out the same).
When you say halo/cheesy drive in this context... do you mean driving the steering without using the y component?
Reply With Quote
  #3   Spotlight this post!  
Unread 26-07-2013, 21:27
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

Quote:
Originally Posted by JamesTerm View Post
When you say halo/cheesy drive in this context... do you mean driving the steering without using the y component?
Yup. At y=0 the math works out the same for x-only movement as the Halo drive did.

The intent for Radius was to replace the x-axis input in the Cheesy Drive with the theta*r input. We provisioned a lot more to place the raw/quick turn elsewhere on the stick range (the negative half) in the alternate-raw implementation, but the normal raw is just a cheesy drive with a quick turn button.

In fact, the entire reason we used the interp curves was to support the alternate raw implementation. We never revisited the math when we decided we didn't like it.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Reply With Quote
  #4   Spotlight this post!  
Unread 28-07-2013, 07:59
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

Hi Palardy,
So I have started to integrate the Culver drive controls in our simulation and I have found some interesting findings:

When I started testing this, I found that not all circular controllers have the same diagonal intensity as the LogicTech F310. I tested the AirFlo which is also circular, but in testing, it reached full x and y intensity at the corners. I am not sure if there is a spec yet for identifying this, but it should probably be in a form that shows the full x and y intensity ratio (when diagonal), because the F310 I have tested if you normalize x and y readings and move the joystick to its full diagonal where they are equal...it is more than (sin(45) / 70.7...) it's around 80. I believe though that controllers like the AirFlo can still benefit from the Culver drive, because the faster speeds really shouldn't matter as much.

So using just the theta and magnitude and testing this with full y component magnitude. I put a UI feedback that shows what the value would have been if I just used the x component right beside the new value of (theta * r). It turns out they were equal (at first)! This means anyone can simply use halo drive code and control the wheel in the same manner to get the same effect. Now then in regards to the 80% normalized value I mentioned above... as you rotate the wheel closer to 90... the magnitude will actually exceed 1.0... to around 1.14... so as it gets closer and the magnitude increases you lose precision you would have had otherwise, but at these faster speeds it doesn't really matter.

So I have some good news though... I'd recommend you try the same tests if you can and see if you are getting the same results. If I scale the magnitude to around 0.875... this works out perfect where it starts with a magnitude of this (0.875) moving joystick to full Y with x centered... and then by the time it reaches the corner it will be around 1.01. With this you can finally achieve a greater precision for the slower speeds. The derivative of the distribution looks like a "soft" x^2 when compared testing against the x components raw value otherwise.

One other interesting note is that I tested the halo drive scenario (i.e. no Y component)... this turned out to lose more precision than otherwise, but not by much. That said, this solution cannot substitute the need to filter out the dead zone of the joystick, and it should be virtually the same amount as otherwise. This loss of precision could be a benefit for an alternate quick-turn solution. For our setup the workflow may be to use halo drive for most quick turns, and then the Culver wheel drive to fine tune the turns. On Monday I'll try to show a demo of this and these number findings on YouTube.

Last edited by JamesTerm : 28-07-2013 at 08:03.
Reply With Quote
  #5   Spotlight this post!  
Unread 16-05-2013, 23:16
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: paper: FRC #33 The Killer Bees 2013 Software - BuzzXVIII (Buzz18)

Added file buzz_lib_sw_2013.zip (BuzzLib 2013)

New functionality from last year:
-Simple Vref Diagnostics - Used with shorting jumper on adc7 (between 5v and analog pin), used to diagnose simple faults of 5v rail and provide ratiometric multiplier for ratiometric sensors.
-Sharp IR - Scaling blocks for all three Sharp IR sensors sold by Sparkfun. Analog to cm values copied directly from datasheet and interpolated using multipoint linear interpolator (see below)
-2d interpolation - Interpolates a 2d curve from a prelookup and 1d array of Z points. Also variants to round down and round up to nearest Z point.
-3d interpolation - Interpolates a 3d map from two prelookups and a 2d array of Z points.
-Prelookup - Finds the index and fractional index from a x input and 1d array of X breakpoints. All breakpoints must be spaced least->greatest, there is no checking of this. Used for 2d and 3d interpolation, as it is the most computationally intense step a single prelookup can be shared by multiple interpolations who share the same axis breakpoints.
-Accel calculator - Calculates the acceleration of a velocity assuming 10ms iteration time. Really just finds current derivative, but used for acceleration of shooter wheel speed.
-Hysteresis - Threshold with hysteresis.


The 2d and 3d interpolation tables are the most interesting. For an example of their use, see the Sharp IR blocks in BuzzLib, as they do 2d interpolation in the most basic form.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:54.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi