Go to Post If you have not had a positive experience in FIRST, please don't bring those that have down. - Jeff K. [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 3 votes, 5.00 average. Display Modes
  #16   Spotlight this post!  
Unread 19-05-2014, 14:48
Cel Skeggs Cel Skeggs is offline
Robot Software Manager Alumnus
AKA: Previously known as Colby
FRC #1540 (The Flaming Chickens)
Team Role: Alumni
 
Join Date: Feb 2013
Rookie Year: 2009
Location: Portland, Oregon, USA
Posts: 107
Cel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of lightCel Skeggs is a glorious beacon of light
Re: What's your favorite programming/control system magic this year?

One of our team's members developed an emulator as part of our software framework that let us thoroughly test our code without a real robot:

This let us have our robot code mostly ready before we even had a prototype robot, and then let us make sure our changes would work before deploying.
__________________
Software manager alumnus. Developer of the CCRE, a powerful robot code framework based on dataflow and composibility.
Refer to as she/her/hers. Years of FRC: 2012, 2013, 2014, 2015, 2016. FLL for a few years beforehand.
Team 1540: The Flaming Chickens | Portland, Oregon | Twitter | Facebook
  #17   Spotlight this post!  
Unread 19-05-2014, 17:04
billylo's Avatar
billylo billylo is offline
Registered User
FRC #0610 (Coyotes)
Team Role: Mentor
 
Join Date: Mar 2012
Rookie Year: 2012
Location: Toronto
Posts: 161
billylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant futurebillylo has a brilliant future
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by Colby Skeggs View Post
One of our team's members developed an emulator as part of our software framework that let us thoroughly test our code without a real robot:
This let us have our robot code mostly ready before we even had a prototype robot, and then let us make sure our changes would work before deploying.
The robot emulator can be very useful for training new programmers too. No need to share a physical robot to test their code (and reduce safety risks too.)

I would very much look forward to seeing this running on the new roboRIO platform. Very well thought-out.

Thanks for sharing it here!
__________________
#go610
  #18   Spotlight this post!  
Unread 19-05-2014, 20:12
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,189
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by Thad House View Post
That is absolutely incredible. Hopefully they actually release that code, because that would be so cool to read through and learn how it works.
Yes, we will be releasing the code for this (both path generation and follower controller) later this year. Right now we are turning over student leadership and most mentors are busy barbecuing

I would like to elaborate on this system a bit though.

From the start of the season (Or rather, once we were set on a robot that carried 3 balls to a closer shooting position) we wanted the ability to drive smooth S curves. The reasoning was we knew we were going to need to get over to the one point goal to avoid defensive goalie robots by the time Einstein came around. In place of this system we could have used the typical "Drive, turn X degrees, Drive" auto driving architecture, but decided this was not going to work based on our troubles with translating and spinning in 2012 and 2011.

The implementation of this system was a tool [1] that allowed the programmer to specify a list of waypoints for the robot to drive. Each waypoint consisted of a X coordinate, a Y coordinate, and heading (Assume the robot starts at 0,0,0). From there, we found a set of splines that intersect each waypoint (at the desired heading) and fit within a maximum radius which was something that we knew we could drive (aka no abrupt 180* turns).

Next, we figured out what it would take to get the robot to drive that path.Given a maximum velocity, acceleration, and jerk (derivative of acceleration) for the robot to drive with, we walked the spline-y path generated above in steps of 0.01 seconds. For each step, we generated (Position, Velocity, Acceleration, Jerk, Heading, X, Y, and current time step) for the geometric center of the robot. These values corresponded to how the robot /should/ be moving at that point in time. From there, given the wheel base of the robot, we were able to build two sets of steps, one for each wheel. These lists of steps were built into arrays which we serialized to a text file.[2]

On the robot side we built a controller that would drive the robot on the path (after deserializing). The controller that made the robot move consisted of 3 sub controllers: 2 wheel controllers for the left and right wheel, and a heading controller that would correct the angle of the robot on the field.

The wheel controller which followed the trajectory basically looked like this (one running for each wheel, using the given wheel's path data:
Code:
double update() {
  Segment step = follower.getNextSegment();
  double motor = 0;
  motor = (step.vel * K_vel) + (step.acc * K_acc) + (step.jerk * K_jerk);
  motor += ((step.pos - getWheelPos()) * K_p);
  return motor;
}
The heading controller looked something like this
Code:
double updateHeadingController() {
  Segment step = leftWheelFollower.getCurrentSegment()
   return (step.heading - gyro.getAngle()) * K_heading;
}
And the overall system looked something like this
Code:
updateDrive() {
  double l = leftWheelController.update();
  double r = rightWheelController.update();
  double turn = headingController.update();
  leftMotor.set(l+t);
  rightMotor.set(r-t);
}
So basically, even without a gyro or encoders we could drive something like the path just by pressing 'play'. Once the closed loop position and heading controllers were turned on, it was much better.[3]

We will release this code over the summer. Hopefully it will make more sense then.

[1] This tool was run on a laptop, as the math to build all the paths was pretty slow on the cRIO.
[2] We originally wanted to render java class files with static arrays defined for each path, but we ran into an issue with the tool that packages the final jar file for deploying. It could not handle more than about 1KB of static data in any Java class.
[3] We did no work to validate that our paths did not cause motor saturation. Whenever the driving looked weird we would down the velocity or move the waypoints to make bigger curves.

Last edited by Tom Bottiglieri : 19-05-2014 at 20:16.
  #19   Spotlight this post!  
Unread 19-05-2014, 22:36
randantor randantor is offline
Registered User
AKA: James Y
FRC #0624 (CRyptonite)
Team Role: Alumni
 
Join Date: Jun 2013
Rookie Year: 2012
Location: Katy, TX
Posts: 48
randantor is a glorious beacon of lightrandantor is a glorious beacon of lightrandantor is a glorious beacon of lightrandantor is a glorious beacon of lightrandantor is a glorious beacon of lightrandantor is a glorious beacon of light
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by Tom Bottiglieri View Post
The wheel controller which followed the trajectory basically looked like this (one running for each wheel, using the given wheel's path data:
Code:
double update() {
  Segment step = follower.getNextSegment();
  double motor = 0;
  motor = (step.vel * K_vel) + (step.acc * K_acc) + (step.jerk * K_jerk);
  motor += ((step.pos - getWheelPos()) * K_p);
  return motor;
}
Very cool! Your last second change in the Einstein finals was exciting to watch, and the controlled s-curve was very impressive.

What I can gather from this code is that the motor speed for each side is first calculated with a feedforward term from the velocity, acceleration, and jerk, and then additionally a proportional feedback term is added using feedback from the actual encoder position. Is this correct?

If I'm reading it correctly, is there a reason why the feedforward velocity (the velocity, acceleration, and jerk sum) is calculated on the robot using the curve values rather than calculated beforehand and output as motor velocity values?
  #20   Spotlight this post!  
Unread 19-05-2014, 23:46
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,189
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by randantor View Post
What I can gather from this code is that the motor speed for each side is first calculated with a feedforward term from the velocity, acceleration, and jerk, and then additionally a proportional feedback term is added using feedback from the actual encoder position. Is this correct?

If I'm reading it correctly, is there a reason why the feedforward velocity (the velocity, acceleration, and jerk sum) is calculated on the robot using the curve values rather than calculated beforehand and output as motor velocity values?
Yes. Most of the real work is done by the feed forward terms of vel, acc, and jerk. Since we know what position we want to be in at that particular point in time, we can close the loop on the error in the case that we are trailing or leading our moving carrot.

Yes, you could also back out the motor values on the front end since it is all open loop. We did not because we wanted everything in the path to be in same units, and it made it a bit easier to tune the gains on the robot without re-generating a path.

The neat part is it's crazy easy to find K_acc and K_vel. Put your robot on the ground, give it full joystick forward, and log encoder values and time. Plot velocity and acceleration. Find max velocity and max acceleration. K_vel = 1.0/Max_vel and K_acc = 1.0/max_acc. Think about it, when you are commanding half your max velocity, your feedforward term should be about half max voltage. The acceleration term will add a bit more power in and the loop closed around position should help fix any error you get (from chain tension or battery voltage differences).
  #21   Spotlight this post!  
Unread 20-05-2014, 00:31
Thad House Thad House is offline
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,107
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by Tom Bottiglieri View Post
Yes. Most of the real work is done by the feed forward terms of vel, acc, and jerk. Since we know what position we want to be in at that particular point in time, we can close the loop on the error in the case that we are trailing or leading our moving carrot.

Yes, you could also back out the motor values on the front end since it is all open loop. We did not because we wanted everything in the path to be in same units, and it made it a bit easier to tune the gains on the robot without re-generating a path.

The neat part is it's crazy easy to find K_acc and K_vel. Put your robot on the ground, give it full joystick forward, and log encoder values and time. Plot velocity and acceleration. Find max velocity and max acceleration. K_vel = 1.0/Max_vel and K_acc = 1.0/max_acc. Think about it, when you are commanding half your max velocity, your feedforward term should be about half max voltage. The acceleration term will add a bit more power in and the loop closed around position should help fix any error you get (from chain tension or battery voltage differences).
So how do you guys tune the p and the jerk gains? I've always wondered if there is a good way to tune loops without just guessing and checking. And even then I don't really have a good idea on where to even start with the guesses.
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
  #22   Spotlight this post!  
Unread 20-05-2014, 12:24
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,189
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: What's your favorite programming/control system magic this year?

Quote:
Originally Posted by Thad House View Post
So how do you guys tune the p and the jerk gains? I've always wondered if there is a good way to tune loops without just guessing and checking. And even then I don't really have a good idea on where to even start with the guesses.
Oops, I lied. We don't apply jerk to the control output.

We find the position controller gains (we have I and D terms coded in, but we ended using 0 as a gain for those) by plotting the position setpoint and measured position over time. The setpoint moves and you can watch how closely the sensor is catching up to it. If it's slow, up the gain until it starts to overshoot. Then back it off a little. For this application, close enough is fine.
Closed Thread


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 19:23.

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