pic: Team 624 2015 Offseason Tesbed

[Jack S.]

loading photo ...

[Munchskull]

Nice drivetrain. Might want to shorten that shaft. Also congratulations for getting on the cad train

[KohKohPuffs]

Nice drivetrain

Couple questions:

1. What was the reasoning behind using different-sized wheels for such a drivetrain?
2. I believe you asked me this same question on my first custom butterfly drive, but to this day I am still confused on how to solve that problem . Here's the question: With a chain-in-tube drive like that, does it take into account rivets and other pieces of hardware that share the drive rails?

[z_beeblebrox]

Originally Posted by KohKohPuffs

Nice drivetrain

1. What was the reasoning behind using different-sized wheels for such a drivetrain?

The chain is a tight fit in the tube, so the center wheels can't be dropped. Using different size wheels serves the same purpose as a dropped center wheel: shortening the wheelbase to reduce turning scrub forces.

[Jack S.]

Originally Posted by Munchskull

Nice drivetrain. Might want to shorten that shaft. Also congratulations for getting on the cad train

Thanks, I chalk the excess shaft up to offseason laziness.

Originally Posted by KohKohPuffs

Nice drivetrain

Couple questions:

1. What was the reasoning behind using different-sized wheels for such a drivetrain?
2. I believe you asked me this same question on my first custom butterfly drive, but to this day I am still confused on how to solve that problem . Here's the question: With a chain-in-tube drive like that, does it take into account rivets and other pieces of hardware that share the drive rails?

1. (Exactly as z_beeblebrox said above) Making the outer wheels smaller in diameter than the inner wheels erases the need for dropping the center wheels as you would on a usual 8WD or 6WD (to reduce turning scrub). They do have different linear speeds, but we found this difference to be negligible since the outer wheels are only contacting the ground a fraction of the time.
2. As you can see in the picture, we don't use any gussets in the corners. This is for the reason you stated above. The wheels are too close to the corners and we can't have any bolts or rivets where the chains and sprockets run. In place of a gusset, we machined 8 aluminum blocks that would slot into each end of each rail. We then bolted them in place at the top and bottom and ran two 1/4-20 countersunk bolts through each corner pair. We found this to provide a rigid replacement for gussets and rivets. All the hardware passes through the tube perpendicular to the chain, allowing the chain to run above and below it. In this way we avoid interfering with the chain.

[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)

[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?

[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

[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.

[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 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?

[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?