pic: Team 624 2015 Offseason Tesbed

[Beaker]

Originally Posted by Ari423

Can you talk about your motion profiling program? 1-2" accuracy without encoders sounds almost too good to be true (assuming you're going more than a few inches, which I think is a fair assumption)

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

[Abhishek R]

Made something in CAD and then built it for real too, what a time to be alive :')

It looks great! The black hexagonal cutout lightening pattern looks nice.

[RyanCahoon]

Originally Posted by Beaker

- We use a Trapezoidal Velocity Profile.

- It does not integrate with PID (feedback) yet

I assume everything is feed-forward. I'm interested if you would describe (a graph would be great) the control signal that you output in order to achieve a trapezoidal velocity profile

Originally Posted by Beaker

- We actually got it to hit 10 feet perfectly multiple times.

Are you doing anything to compensate for battery charge level? Have you tried running your controller with batteries at different levels of discharge?

[Beaker]

Originally Posted by RyanCahoon

I assume everything is feed-forward. I'm interested if you would describe (a graph would be great) the control signal that you output in order to achieve a trapezoidal velocity profile

The only "graphing utility" I have access to at the moment is MS Paint, so I will post graphs for clarity later. Below is a technical description of our program that hopefully answers your question.

Given a distance, the robot generates a piecewise function. Since we know a maximum acceleration, we can create a triangular graph to determine max reachable velocity. The area of this triangle (integral of the velocity) must be the distance, and since we know the acceleration (slope of hypotenuse) we can find the max reachable velocity and the total time required for the profile.

After finding these two things, there are two possible cases. Either a) The max reachable velocity is less than the max allowed velocity or b) the max reachable velocity is more than the max allowed velocity, where the max allowed velocity is the maximum speed of the robot.

If case A is true, then motion profiling is simple. We make a piecewise function with 2 pieces, accel and decel. Each piece is v=at.

If case B is true, its a bit more complex. We now have to determine the time spent cruising. This can be achieved through geometry; All that needs to be done is find the base of the trapezoid that represents cruising velocity, and since you already know max velocity (height) and base 1 (total time), the math is not that hard. After these calculations, we have 3 times for 3 pieces of the function, 2 of these are v=at, then the cruise phase (the second piece) is v=cruise_vel.

Finally, our program outputs velocity and acceleration. However, motor controllers take in powers. What has to be done now is that we need to scale the outputs to create a power. Since we use the Talon SRX, we can assume that the scale is linear. The conversion to power goes as follows:

Motor Power = (Kv*velocity) + (Ka*acceleration)

We coerce this value between -1 and 1, just in case. All that is left to be done is to output this power to the motor controller.

I encourage you to read through the 254 presentation if I missed something. There are some graphs there and in the other (non Youtube) link that might clarify some things I have said.

Originally Posted by RyanCahoon

Are you doing anything to compensate for battery charge level? Have you tried running your controller with batteries at different levels of discharge?

Not yet, which is why integration with feedback is still important. If the battery level is low, feed-forward will not behave quite as expected, but the feedback system should be able to compensate.

[philso]

Originally Posted by Beaker

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.

[1493kd]

Hopefully someone can help me out a little on the belly pan. We would like to do something similar this season for our belly pan and I was wondering how attaching electronics to it works?

Do you need to plan on exactly where everything will be laid out or do you just place them on after the pan is cut out? If so what method is used to attach everything to the belly pan.

BTW- great looking testbed, we did something similar this offseason and its going to make testing and prototyping so much easier/quicker

[philso]

Originally Posted by 1493kd

Hopefully someone can help me out a little on the belly pan. We would like to do something similar this season for our belly pan and I was wondering how attaching electronics to it works?

Do you need to plan on exactly where everything will be laid out or do you just place them on after the pan is cut out? If so what method is used to attach everything to the belly pan.

BTW- great looking testbed, we did something similar this offseason and its going to make testing and prototyping so much easier/quicker

You need to decide how you are going to attach each of the electrical components to the pan; screws, zip ties, Velcro/DuoLock, etc. You would then decide where to place each component and where the wiring channels will go. It would be good idea to place some extra motor controllers while you are at it. Use this layout to determine the pocketing pattern and mounting hole pattern. It might be best to not pocket where your wiring channels go to reduce the chance of cutting the wire on a sharp edge. We found it difficult to use Velcro to attach a motor controller when the only place for it is over a large hole in the pan. Zip tying components to a pan with a triangular pocketing pattern can lead to the components being at all kinds of funny angles.

Alternatively, you can install all your electrical components on a thin polycarbonate panel then attach the panel to the pan.

There are many examples of good electrical layout here on CD. You can also refer to the white paper we published for suggestions on how to layout the electrical components.

http://www.chiefdelphi.com/media/papers/3177?

[Jack S.]

Originally Posted by philso

Alternatively, you can install all your electrical components on a thin polycarbonate panel then attach the panel to the pan.

This is the approach we used with the testbed. However, I would have preferred to design the pan based on the electronics layout like you suggested, but we were in a time crunch. If we use a belly pan this season (I hope to, but in my memory I don't believe we ever have), we will most likely trim down the weight and base it off the electronics layout.

[shlynfrhm]

Hi, can any of you clarify what type of thin polycarbonate paneling you would reccomend to mount your electronics on? And what reccomended thickness? Thanks!

-Ashlyn

[philso]

Originally Posted by shlynfrhm

Hi, can any of you clarify what type of thin polycarbonate paneling you would reccomend to mount your electronics on? And what reccomended thickness? Thanks!

-Ashlyn

These last two years, we mounted all the electronics on polycarb panels. I think we used 1/8 inch thick polycarb both years.

In 2014, the components were pre-assembled onto the panels outside of the robot. The panels were then stuck onto metal panels in the chassis using Velcro. The polycarb panels were fully supported by the metal panels so we could have used 1/16 inch thick polycarb for these if we had any.

In 2015, the panel (about 16 x 22 inches) was riveted to the frame tubes and was only supported around the edges so 1/8 inch thick polycarb would be needed to prevent the panel from flopping around too much once the heavier electrical components were installed. There was a second polycarb panel mounted on the other side of the tubes with the pneumatic components mounted on it. Don't make the mistake of installing anything on the panels with screws and nuts. The nuts were inaccessible once both of the panels were installed.

[Beaker]

Originally Posted by philso

Did you select the acceleration/deceleration values such that wheelspin is minimized or eliminated in order to get the positional accuracy?

We set a maximum acceleration and maximum velocity in order to get the most accurate results. We also tune 2 constants that scale the profile's output velocity and acceleration to actual motor power.

Originally Posted by philso

How straight is the path the robot takes? How much variability is there, side-to-side, from a straight track?.

The robot currently has a very slight drift (2 inches over the course of 10 feet), mostly due to chain tensioning. This drift can be corrected in the code with gyro feedback control, which we do in the season.

[philso]

Originally Posted by Beaker

We set a maximum acceleration and maximum velocity in order to get the most accurate results. We also tune 2 constants that scale the profile's output velocity and acceleration to actual motor power.



The robot currently has a very slight drift (2 inches over the course of 10 feet), mostly due to chain tensioning. This drift can be corrected in the code with gyro feedback control, which we do in the season.

That is pretty good performance. Does the amount of drift or the distance driven change if you reduce the acceleration to half or if you double it?

[Beaker]

Originally Posted by philso

That is pretty good performance. Does the amount of drift or the distance driven change if you reduce the acceleration to half or if you double it?

The distance does not change if we adjust acceleration, only the time it takes to travel the distance given. This is because the profile recalculates the motion profile with the new values. The drift also does not change.