View Single Post
  #11   Spotlight this post!  
Unread 06-01-2016, 08:25
philso philso is offline
Mentor
FRC #2587
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Houston, Tx
Posts: 938
philso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond reputephilso has a reputation beyond repute
Re: pic: Team 624 2015 Offseason Tesbed

Quote:
Originally Posted by Beaker View Post
Hello,

After attending the Cheesy Poofs' seminar at CMP on Motion Planning and Control Systems, I was inspired make a program that could drive without encoders. Here is how it works:

- We use a Trapezoidal Velocity Profile. It is trapezoidal because of the shape that the graph makes.

- There are 3 stages to our trapezoidal motion profile: Acceleration to Cruise, Cruise Velocity, and Acceleration to 0 velocity.

- Using physics equations and concepts, you can determine the amount of time needed in each phase of the profile. In mine, I give the robot a distance, its max velocity, its max acceleration and 2 scaling constants. The program basically reverse engineers this information to find the time spent in each phase and the velocity/acceleration involved at a given time.

This creates a very smooth acceleration and deceleration, which makes the motion predictable and repeatable.

Advantages of our Profile
- Our profile is computed by the robot on the fly. There are no external data files required
- We actually got it to hit 10 feet perfectly multiple times.

Limitations of our Profile
- Currently, our profile only works in the one dimensional case. We cannot do splines like 254
- We can only use the second order trapezoidal profile. My calculus knowledge isn't up to par with a third order profile (I'm in BC Calculus currently)
- We cannot change distances on the fly
- It does not integrate with PID (feedback) yet

Here are some resources that I used in my quest to accomplish this:

Cheesy Poof Presentation
Cheesy Poof Presentation on Youtube
Online Planning of Time-Optimal, Jerk Limited Trajectories

If you have any other questions, I am happy to answer them!

-Justin
Great work, Justin and Jack!

Did you select the acceleration/deceleration values such that wheelspin is minimized or eliminated in order to get the positional accuracy? How straight is the path the robot takes? How much variability is there, side-to-side, from a straight track?

Being the mentor in charge of the electrical system on our robots, I would suggest using a pocketing pattern that matches up better with electrical components such as the motor controllers of your choice, the PDP, the RoboRio, etc. You would be cutting this out using a CNC process of some sort so an irregular pattern will not really matter and should not make much difference in the weight.
Reply With Quote