“But I do agree with something mentioned here, and I told my teams even before SingVex - it seems to be a lot of metal used just to move one cone (i.e. rd4b + chain bar) :(”
It’s funny, I’ve told my husband the same thing. My description is little less eloquent: using those contraptions to pick up one cone is like using a sledge hammer to kill a fly. I have a feeling that by the end of the season, there will be lean mean cone lifting machines. There is absolutely no way that it should take 4 motors to lift one cone that weighs just a few ounces. We are pushing our team to really brainstorm on ideas. What worked last year, might not be the best solution this year. If you have a hammer, everything looks like a nail. Need to step outside the box a little.
Wait what? Your theoretical ALBA robot would be lighter and use less resources, but the DR4B is more efficient? Also the type of lift you use (at least to me) depends 100% on strategy. If you want to stack more than 12-13 then sure a DR4B is the best simply because anything else gets heavier at that height. But anything under that should be obtainable by a simple modification to ALBA’s robot. Also DR4B only have low friction if they are build very well. You also are:
-Driving with more weight
-You less space to work with
-More Complexity
-Higher CG
If you look at it with a strategy where you are only stacking around 12 high it is simply the better design (IN THEORY) because its so much simpler and easy to work with.
@meng@Highwayman It certainly looks violent, but since you already have a control loop, use a curve like the one attached to smooth the takeoff and landing of the pickup/stack motion. The speed in the middle can go up then without jerking and overall speed can increase if the power is there.
to do this you can put commas in the column after the integers that represents the curve, then cut and paste those two columns into a *.c file, then make an array in that file with those contents. You have to #include the file for RobotC (which is a terrible practice) or just make it part of the project in PROs. SIgmoid.xlsx (91.1 KB)
Actually 8059’s chain bar is a lot more… gentle than Alba.
Alba is using 2 motors for the chain bar - which is kind of overkill.
And I suspect because 8059 intake the mobile goal into the center of the robot, it helps a lot in terms of CG.
The 8059 chain bar is only using 1 motor. Much easier to control. But at the same time, my teams found that it was too slow to match up with the lifting speed.
But you are definitely right - the control loop, or power curve will help
I’m not sure if I understand correctly, but it looks like your idea is to create a LUT of motor values which change more slowly around the ends and faster in the middle - is that right?
If so, the motors work in such a way where the motor gains speed more rapidly with the small control values while the bigger ones make much less of a difference. So to do this, you would want to first linearize the motor control-speed curve and then apply this. Or just figure out experimentally how to fit the control, values to this curve all in one step. Not sure if that makes sense. I do think that doing something like this could be helpful in various situations in vex.
Although, isn’t a similar effect already achieved by slew-rate control and a p-controller? You could tune both of those to make the arm less violent. The reason why I didn’t do anything more was because it didn’t seem to be a serious problem and anything to reduce it would just slow the arm down.
Also, the arm is “violent” in two ways which are separate problems in my thinking. First is that without some protection in the controller, reversing the arm suddenly will bend the axles on the 84 tooth gears. This could be helped by using a different gear setup (that is one without 84 tooth intermediate gears), but for me it was solved with the slew-rate control. The Second problem is that the robot rocks while stacking. This could be helped by reducing the speed/acceleration of the arm mechanically or programmatically, reducing the inertia of the arm, or increasing the mass of the base. The robot is pretty light and the arm is pretty fast - both are usually nice things but in this case they have a drawback. I think the best solution is to carry the mobile goal in the middle of the robot and (if possible) to reduce the range of motion of the arm.
i mean, considering ALBA’s entire design is based around this no, however if you plan on going something meta, but instead of a rd4b you use a 6 bar, (with a chain bar intake) you wont have good results. Because the nature of the robot makes it so that it ends in roughly the same position.
I should have been more clear, sorry. No, I’m not replacing motor values with the graph. This particular graph is meant to be used with a positioning PID control (I believe you said yours was P only, which is a fine start). It’s a generic sigmoid with a value from 0 to 1.0 (It’s actually 2 independent functions, you can pick which one fits best).
There are 400 elements in the table, 400 was just picked to replace a current system in place, nothing magic about it, could be more or less depending upon your memory use and required resolution. There are two columns of values that are usable as arrays, the first is floating point 0 to 1.0, the second is integer 0 to 65535. The floating point one you can use directly, the integer one is for those familiar with fixed point fractional number multiplication and it’s use. The integer one uses less processing power, but for VEX floating point is fine.
So to use this array, the easiest thing is to have an update rate for your position control loop PID, let’s say every 20ms (for Vex it’s fine, this is slow for real life stuff), so 50Hz. You decide how far you want to go, how many 20ms time clicks you want to take to get there, divide the number of elements in the array (400) by the number of time clicks you wanted, then use that value (needs to be a float) as the increment for the index into the array each 20ms tick. The value looked up is multiplied by how far you wanted to go and gives you the new position target for your PID loop.
There are some controls short cuts in this description, but fine for Vex application.
Decided the first image was perfect only to find out it was from the Vexforum. What should have been obvious at this point is that it was from @jpearman
So now for the actual explanation. A simple motion profile is about not only getting to the goal but actually controlling the motion/path in some way. If you look at the positions on the different graphs you can see that they both slow down to the target but pure PID just does that for accuracy. The motion profile also starts off slow.
You can see from the top picture that the you actually take into account max acceleration of a robot. A simple profile like that is pretty similar to what a robot would look like under serious load.
Heh, yeah, I really need to update pros on my programming laptop I’m usually pretty adamant about updating to the latest version of things, but for whatever reason I’m not very good about that when it comes to PROS. I will make a point to update and switch to atom before summer ends, though.
On the subject of holding up mobile goals, ours holds them up fine without any power. Lots of rubber bands and great angle, basically. More details later, when the whole thing works probably, but I’m actually fairly happy with the state of our robot after a few tweaks.
When I posted the reveal, I hadn’t made one. But I ended up wanting a CAD model of an In the Zone robot for another project, so I quickly made a rough model of OSIZR. It doesn’t include most of the spacers, so the exact placement of some parts on joints is a little inaccurate, but otherwise, it should be helpful.
It’s not online anywhere right now, but I’ll try to upload it later today or tomorrow
