1. Get your software working before putting it on the robot!

2. My name: Chris Hibner Mentor FRC 51 - Wings of Fire  Control Systems Engineer  Involved with FIRST for a LONG time  Plenty of industry experience  Cool Degrees (Go Blue!) chiefdelphi.com: “Chris Hibner”

3.  Motivation: why learn this stuff?  Simple Logic Simulation  Modelling: 1 st order models  Modelling: Physics equation models  Simulating some example software  Moving between simulation and the robot  Where to go from here...

4. Why should I care about this? 1. Good for complex control code: state machines, feedback loops, automated sequences, etc. 2. Time crunch: You don’t get much time with the robot to test and debug. 3. Safety!!: Software bugs can damage your robot or people. 4. Makes debugging much easier: not only can you pause the software – you can pause the motion too. 5. Allows programming students a “safe” environment to experiment and learn.

5. Complicated example: 2010 Kicker Control

7. 1. Create your control software  Make your software a portable unit LabVIEW: create a vi Java/C++: create a class 2. Create a simulation environment 3. Create a mathematical model  What’s a model?  How accurate does it need to be?  Model Inputs? Motor commands  Model Outputs? Sensor outputs, position, speed, etc.

8. Simulation Environment

11.  A “First Order” model uses a simple filter to simulate speed changes.  Why?  Most objects controlled by a DC motor: the “step response” very closely follows a filtered version of the step. time Step Input

12.  What does the step response of a motor look like? time 1 2 3

13. Step Response – Actual Physics

14. Step Response – First Order Filter

15.  How to get the filter to match the physics?  Need to know two things: 1. The top speed multiply the filter output by the top speed (simple) 2. How long it takes to reach the top speed set “time constant” according to how much time it takes to get to the top speed.  “Eyeballing” is usually good enough  Let’s eyeball the motor step response and see how close we come.

16. Step Response – Actual Physics ~3.23 ~1.7 sec

17. Step Response –Physics vs. Filter

18.  Elevator without gravity  LabVIEW example of elevator speed

19.  We modelled speed in the last example, but we need position...  Acceleration, Velocity, Distance:  you only need to know one – the other two can be calculated Acceleration Velocity Distance integral derivative

20.  Back to our example  We knew velocity  Let’s add distance and acceleration

21.  How to add external forces, like gravity or springs?  Use “equivalent motor command” method  How to add travel limits (like for an elevator)? 1. Set output of filter to 0 speed (stop it moving) 2. Stop motor command like you would with a limit switch You need to add a little logic

22.  Elevator model with gravity  How do you add gravity to an arm?

23.  Let’s add some control software  What do you want it to do?

24.  You rarely need to go to a physics model.  If you find yourself making a physics model, ask yourself if you really need it.  You probably won’t need it for software testing, but maybe the mechanical team needs to see if their gearing will operate the arm.

25.  Newton’s 2 nd Law is everything Linear Motion: F = m*a Rotational Motion: T = I * alpha  Solve for the acceleration: a = F / m or alpha = T / I  Important: F is the SUM of ALL forces

26.  Acceleration, Velocity, Distance  You only need to know one – the other two can be calculated Acceleration Velocity Distance integral derivative

27.  Ignore what is insignificant!  For robot drive system, just calculate forces at the wheels  Ignore wheel inertia since mass of the robot is MUCH larger  For arm model, ignore inertia of motors and gears – just use the arm inertia.

28.  Are they important?  It depends.  Does the sensor dynamics affect your control?  Encoder model

29.  Sensor noise – especially if using D control. Sensor value Sensor value with noise

30.  Software from a team

31.  Since you made your code as a unit (right?), just put the code in the project and “hook it up”  Use the same FILE in your robot project as you used in your simulation.  That way, if you make future changes and want to test them in simulation, you don’t have to maintain two copies of the code.  IMPORTANT: Before running on the real robot, check that 1) motors go in expected direction, 2) sensor polarity is correct.

32. If you didn’t notice this on the last slide, I’ll say it again:  IMPORTANT: Before running on the real robot, check that 1) motors go in expected direction, 2) sensor polarity is correct.  What happens if a sensor or motor goes in the opposite direction of what you expect?  Let’s check the simulation

33.  Demonstration

34.  Why? Get the bugs out of your complex control code BEFORE putting it on the robot.  How: Create your software.  Create a simulation environment.  Create a model (if necessary).  Use the simplest model possible!  Use a little calculus

35.  LabVIEW  Microsoft Visual Studio Express (free!)

36.  Presentation material and sample software will be posted on chiefdelphi.com in CD media whitepapers area.  Feel free to send me a PM on chiefdelphi.com: “Chris Hibner