@jack_chapman set the channel purpose: Get cargo into cargo ship and rocket
@Harrison Gilmore has joined the channel
@Ethan Rininger has joined the channel
@andrew_peterson has joined the channel
@julian_bonifaci has joined the channel
@emerson_nicholas has joined the channel
@Jack Scheiderman has joined the channel
Paul suggested that we use a 'zigzag' belt and pulley design using 15mm wide belt and (custom) double-wide pulley for the middle pulleys. These pulleys would have two belts on them, one going to the pulley below them and the other going to the pulley above them. This way we can drive all the belts from a single motor (775Pro) without using extra belts. For example, lets say we need three lengths of belt to make it the full length. We will have single width pulleys at the lower end and the upper end of the assembly (call them P1 and P4) and two double wide pulleys in the middle (P2 and P3). The first belt connects P1 and P2. The second belt connects P2 and P3. The third belt then connects P3 and P4. This design functions as if it were a single, long belt with two idler pulleys in the middle. @Sunny_Gregson -- the longest belt we have is the 170 tooth x 15mm, 5mm pitch belt from Vex. We have other belts in that same width, (e.g., 90T, 160T and others in between) https://www.vexrobotics.com/vexpro/motion/belts-and-pulleys/htdbelts15.html
I've started work on a design document for the Chute assembly. This document should contain everything we decide about the chute including design, assembly, a bill of materials, how it operates, etc. Everyone is free to edit and contribute.
The google doc is here: https://docs.google.com/document/d/1bpDpMS1MDrPNxcwFAF5Kr4hUYNl7jd49rVZZ_MU-sn4/edit?usp=sharing
I had an idea for cargo “capture” in the chute, and want to share in case it sparks better ideas. I realize that this drawing may be upside down relative to the current design thinking, but the idea should transfer. Basically it is for a “flap” or one-way door to trap the cargo in the chute. It can include a limit switch for simple sensing of cargo position, and it prevents the need for software to monitor cargo position while in transit. It does prevent the ability to eject cargo out the intake, if that was important.
*Thread Reply:* Thanks! That would work and could be integrated with the current design if we need it. The current plan (aka "hope"? "prayer"??) is that there will be some compression between the upper and lower surfaces as you've drawn them and that the motor/belt friction will suffice to prevent the ball from creeping down. I'm not sure I totally understand the limit switch operation as the switch state is the same before and after acquisition. It only changes when the ball passes the catch. If we don't see that transition then we're out of luck. If you got rid of the spring, put the switch where the bottom stop is (underneath the spring) and then balance things so that the weight of the ball pressing against the lever is required to trigger the switch, then the switch & lever would be a reliable indicator of whether the ball is present.
*Thread Reply:* What if you used the elevation adjusting cylinder to act as the stop. The cylinder would have a sleeve on it and when the chute lowers, the sleeve would protrude into the chute.
*Thread Reply:* Also, it might be something for marketing to use if they want to do anything about this robot’s integrated design.
@declan_freemangleason has joined the channel
I won't be at the meeting this wednesday, feb 6th
@Kenneth Wiersema I'm working on chute CAD and was thinking about replacing the "Chute Assembly" with 2 assemblies. "Chute Static" would be all of the static components (belt drive, hoops, motors, etc.). Then "Chute Assembly" would build on that and add the pneumatic components with more complex joints. I think this will make it easier to work with the chute and not break all of the complex joints once you have them set up.
@Kenneth Wiersema I've completed an update to the chute CAD (it's in a new design "Chute Static"). I changed how the lift pneumatics attach to the chute so that should be double checked carefully. Also, the motor and mount are finally in the design. Feedback here is also appreciated. A link to the web view for the design is https://a360.co/2S73Awd
@Kenneth Wiersema Do you know if we have this? Even if not @Mark Tarlton it might be useful for inspiration https://www.vexrobotics.com/versarollers.html. We have long synchronous belts and could print a bunch of small diameter pulley/roller hub combinations and use pvc or something to make our own powered roller system like this
Yes, I think something along those lines is the answer. One idea is to add two or three churros wrapped the blue PEX tube between each line of pulleys. They should be placed high enough that they are just touching the belts when no pressure is applied. then when the ball moves through, they will provide good support and the belts won't deflect under the pressure.
Another thing I noticed was the ball was slipping on the top aluminum tube. We should try something rougher, like a piece of plywood to see if that gives better traction. Remember, the belts spin the balls, but if they don't get good traction on top, they won't go anywhere.
*Thread Reply:* We have a bunch of that gritty (like coarse sandpaper) tape for putting on exterior stairs for anti-slip. Could put it on the aluminum. Or wrap the aluminum in something grippy. Or there is this stuff: https://www.amazon.com/WOD-Translucent-Tape-Traction-Available/dp/B079MJ9FGJ/ref=mp_s_a_1_12?ie=UTF8&qid=1549433491&sr=8-12&pi=AC_SX236_SY340_QL65&keywords=anti+slip+tape+clear
*Thread Reply:* yes, thinking along the same lines .. thanks
*Thread Reply:* I think existing belts could still work if install a supportive, slick plane underneath them so belts cannot sag. Like slick finish hdpe, maybe with the corner rounded on the end where the belt teeth approach.
*Thread Reply:* Not sure if you saw this ^^^. It seems like it could work & would be quick to try.
*Thread Reply:* Delrin sheet like this under the belt spans to prevent sagging? Acetal Copolymer Sheet, Opaque White, Standard Tolerance, UL 94HB, 1/16" Thickness, 12" Width, 24" Length https://www.amazon.com/dp/B0070ZY3OW/ref=cm_sw_r_cp_api_i_eEYwCb8D128PN
*Thread Reply:* I like the HDPE idea too; worth a try.
*Thread Reply:* @chrisrin .. sorry, no I didn't see your comment until just now. I think slick plastic is worth trying, I thought just sliding a bit of polycarb under the middle would be easy to try. The bottom of the belts ride about a 1/4" below the level of the side bars, so we can't use too big a piece of plastic. Assuming that works, I like the rollers you suggested as a more permanent solution -- they have less friction with the belts and are about the same difficulty to install.
*Thread Reply:* Mental note for future... this kind of problem we’re encountering is why most teams do a lot of iterative prototyping with game elements before settling on a design. I’d really like to find a way to shift mindset about prototyping on the team... a “prototyping day” like we did does not cut it
For the top, we had some material for friction that we used for Helios’s intake. I will look around the shop to see if any of it is left. It would help prevent the cargo from slipping.
If you recall, we also use a blue yoga mat with Helios. We have more in the robotics room.
I was also thinking about stair tread tape like this https://www.amazon.com/3M-Safety-Walk-Resistant-180-Inch-7635NA/dp/B0006HVKM4/ref=sr_1_5?ie=UTF8&qid=1549438569&sr=8-5&keywords=tread+tape
For rollers, I suggest placing them at intervals of 3.2" and 0.45" from the top edge of the rail. The rods are made from churro bars with blue PEX tubing over them. The rods are cut long enough to go from the outsides of the rails -- that's where they attach. The hole on the inside of the rail should be large enough for a churro rod to go through. the hole on the outside of the rail should be 0.25" to hold a 1/4" - 20 screw. I added this to CAD and made a drawing to show hole spacing. the drawing is in the Chutes folder. @Sunny_Gregson you may want to print it out. @Kenneth Wiersema can help if you have questions. I'll be checking slack when I can.
... You might also consider using delrin rod instead of churro if that's easier..
And now that I think about it, the rods don't actually need to be attached to the side rails. They can simply rest in the holes drilled on the inside of the rails. They may rattle a little bit, but that's fine for now. We need to verify that this solves the problem.
Chute team. The goal for today is to see if we can verify that the chute design will reliably move and eject Cargo. If it doesn't, then we need to come up with an alternative design as soon as possible.
The specific questions to answer today are: (1) does the belts work to move the Cargo given proper tension and support underneath the belts (either flat plastic or rollers)?
(2) do we need to increase the friction on the top bar so that the cargo can get a grip to roll out?
(3) is one motor enough to drive the cargo out of the chute?
For the first question, several solutions to the belt sag have been suggested in threads under yesterday's message. The easiest to try is sliding a bit of plastic underneath the belts. If that works, then there's no need to experiment with rollers
For the friction question, some ideas are using a piece of wood instead of aluminum bar or putting blue painters tape on aluminum to make it less slick. There are better permanent solutions, but we first need to determine that it will work at all.
If you want to try the flat plastic support idea, I suggest using "L" shaped aluminum attached to the side rails to support the plastic sheet. You might be able to use double sided tape to attach the "L" to the side rails and the plastic sheets to the "L". attach the L upside down so that it won't stick up. I think if you scoot the front edge of the plastic towards the front pulley and then angle the bed down slightly, you can minimize chances of the belt snagging the front edge of the plastic.
here's what it looks like in CAD https://drive.google.com/open?id=1SsVt5AWwNpC1AHFkKEbzMsVXTsKKj2ZQ
@Mark Tarlton Did you need anything printed today?
It went good today, the belt situation was figured out. All we had to do was to separate the versa-blocks to the measurement that you recommended. The motor had to be move due to a lack of a certain belt size. The hoops also had to be moved due to the new location of the motor. Unfortunately though we couldn’t start any 3-D print jobs today. But the hoops are mounted and the top bar is going to be put on at the start of the first meeting. I can explain it all into more detail at the Friday or Saturday meeting, based on the weather.
*Thread Reply:* Thanks!! That's pretty good news. Glad to hear we don't have to start over and design something new. Appreciate your help.
@Kenneth Wiersema I'm working on the lift / hatch pneumatic brackets in back. I found the correct CAD model for the clevis so will make everything larger. How far apart do you want the lift pistons?
Further is better, I’d say the maximum distance that can be safely supported. They need to be at least 1/2 in further apart if possible
@Kenneth Wiersema -- the new mounts for pneumatics is in CAD. I left the old in for comparison. The new structure is in blue. I've linked the two sides together so that the hoops don't have to. This eliminates motor drive belt interference.
I have it integrated into a fairly recent copy of the Full Robot CAD v73 in the CHUTE folder. Let me know what you think or if you see problems.
The hatch / lift pneumatic mounts have been printed. I won't be making any more changes to the CAD on this. @Kenneth Wiersema let me know if you find any problems.
Also, the 'scoops' that go at the front of the chute have been printed in PLA.
The new position look good, the angles are looking at 33.7 and 44.8. If Cruz can get the parts, we could have the mounts done soonish.
Sounds good. I've started printing the next iteration of hoops .. the rear mounting location is awkward. I'll drop the stuff I have at Paul's tomorrow.
Yeah, and you'll want to look at the current setup, the motor mount drifted back a bit, but the current design doesn't seem to provide a problem with it. The mounts are done now too.
We installed the chute in the robot this afternoon and tested it with a drill. We were able to eject the cargo with the chute, so the basic mechanism works, but the velocity wasn't what we were hoping for. We don't know whether this will hold true when the built in motor is used, but we should probably assume so. There are things we can do to help. For example: (1) we can add star or 4"compliance wheels on the rear-most axle to give a little extra push as it exits. A simple experiment showed some promise. (2) change the motor gearing to generate more belt speed and add a second motor for more torque (assuming the motor that's installed behaves like the drill). (3) We can add a second motor and divide the belt into a lower half and an upper half. The lower half would be geared for torque and get the ball started while the upper half would be geared for speed to give it a kick. (4) We can use change the construction of the belt assembly to get rid of the 'VersaBlock' holding the bearings. Unfortunately, this option may add weight to the robot and weight right now is a big concern. (5) we can abandon the belt approach altogether and do something different.
@Kenneth Wiersema If we proceed with option 1 above (which I support) then the cross bar on the pneumatic lift mount will interfere with the wheel. It already interferes with the motor belts. You may need to remove the center bar before you install the bracket.
That's workable, we should see about getting another one further back to secure things
*Thread Reply:* Yeah, its getting crowded back there. one option is to slide the pneumatic mounts further forward and then do a new, deeper cross bracket right underneath the versablock.
*Thread Reply:* I'm also rethinking the motor mount since we want to drive the center pulley. We could go back to the 'hanging box' design I had a while back and put the 180 motor in that. we could then slide it on the rails until the belts are the right tension. I'm also wondering about how we could add another motor.
@Cruz_Strom @Kenneth Wiersema FYI The top bar should be 27" long and start as far forward as the chassis limits and intake allow.
Got it, can you post the drawings for the main rails?
@Mark Tarlton can you get me the needed size and location of versa block holes?
... and this drawing shows location of belt adjusting cams if you can use them in polycarb. I'm not sure the polycarb will take them. https://www.vexrobotics.com/bearingblocks.html#Drawing
Idea for the top bar: https://www.amazon.com/Pack-Open-Cell-Conditioner-Weather-Strip/dp/B011T0ZCM0
I got some of this at ACE https://www.3m.com/3M/en_US/company-us/all-3m-products/~/3M-Safety-Walk-Slip-Resistant-Medium-Resilient-Tapes-and-Treads-370/?N=5002385+3293414317&rt=rud . It seems to work really well.
@Harrison Gilmore @Cruz_Strom did the new chute rails get made yesterday?
I had to leave early that day due to bad weather. But when I was there it didn’t get started
@Cruz_Strom was super busy that day with other groups parts
Just so you guys know, I will be arriving around 12pm tomorrow because of martial arts.
Nearly all of the chute parts got printed before I ran out of filament again so we should be all set to put the pieces together tomorrow and get robot 2 finished up. The only thing missing is the lower mounts (we have PLA versions of those) and the motor mount for the first robot.
*Thread Reply:* @Mark Tarlton Did you print the improved mounts to mount the hatch system?
*Thread Reply:* No, chute parts that were fully designed had first priority. I worked on a bunch of ideas around grabbing from the middle but couldn't get them to work out due to interference problems with the chute.
*Thread Reply:* I've got ideas for where we can mount velcro to get an 'ok' grip on panels that will survive contact with the loading station by using a soft flexible mount on the rear climb legs. It may also need a similar mount at the bottom. I've also looked at ways we can improve the eject system. Two suggestions are making the ejecting arms wider so they touch the hatch panel close to the edges where it's being held and by using longer pneumatic tubes to push it all the way to the rocket body. For a more secure grab of the hatch, the options are the 'hook in the middle' and then lift the chute -- that will require one more pneumatic but I think we can fit it in at the chute. Another option is to grab it at the bottom edge to help secure it during removal and transport. That would also require another actuator of some sort.
@Harrison Gilmore @Kenneth Wiersema -- Yesterday we saw that we can't eject to the cargo ship and that the problem is the chute angle isn't steep enough when the pneumatics are extended. I took another look at the angles and estimate that we need to change the upper chute angle from about 45 degrees to 53 degrees. This means we'd have to change where the pneumatic cylinders attach to the chute and where they attach to the chassis. The chute attach points will be close to the front of the center axle (about 12" back from the front axle). The chassis attach point would be around the rear cross member. I think this puts them on either side of the battery. The chute motor may be in the way as well -- we just have to work around that. <sigh>
Before we commit to changing the pneumatic attach points, we should verify that the new angles are correct and that we can eject cargo at that angle -- nothing's in the way and the motor's strong enough. Otherwise, we will have to stay with the current configuration and ask the programmers to move the robot away from the cargo ship before ejecting cargo.
In any event, the first task for tomorrow should be mounting the ball depth sensor in the chute.
*Thread Reply:* I don't think your proposed solution to moving the mounts is workable, due to all of the other structure in the area that already exists. A better solution might be to revert the mounting brackets to their lower configurations, and then to use 5 in pneumatics to lift the chute, giving an extra inch on the travel of the arm-I haven't verified this, but we need to work around existing systems, and being mindful of everything else that has already been placed on the robot, as moving the pivot forward on the robot will produce far more problems than it might solve
*Thread Reply:* Yeah, interference is a huge problem, but I don't think an extra inch of lift is enough. That's why I want to move the lifting point towards the front of the robot -- a bigger multiplier on the lift.
I'll take another look at the CAD and see what else I can come up with.
*Thread Reply:* I'm struggling to get good measurements in cad but it seems like we need almost 2" of extra elevation. Maybe we leave the mount as is, and go to the 5". The angle may or may not be too high for the rocket.
*Thread Reply:* The rocket is looking fine with the 5 in, but it still seems a little short for the cargoship-Check the chute mount testing folder that I made, there's a stand alone jointed chassis chute combination that has a separate chute file that can be used to adjust the pneumatic limits to act as a different length one.
*Thread Reply:* Ok. looking now. The other option is to move the attach point on the chute closer to the front and keep the tube mounts where they are now.
*Thread Reply:* The joints in fusion are fighting me but perhaps we can stay with the 4" cylinders but change where they attach to the chute. It looks to me that the cross member just behind the middle axle is about the right place.
The way to check this is to detach one clevis pin from the existing mount and try to rotate the cylinder down and see where it sits relative to the cross-support. (that would be the mounting point when the cylinder is retracted). Assuming it's close, then remove the other clevis pin, and lift the chute up as if the first cylinder was fully extended. If we extend the line formed by the belts out until they intersect the rear frame perimeter. That point should be around 32" or more above the floor. that's the height of the cargo ship opening.
*Thread Reply:* I've created a new part called "Test Cylinder Support" in the Chute folder. The idea is that these could be temporarily attached to the middle support and then run a 1/4" aluminum rod through the holes. We could then experiment with different attach positions and see if they work.
2nd task for tomorrow is to shorten the top rail on robot #2. It's 3.5" past the rear hoop on robot #1 and that seemed to be working well.
@Harrison Gilmore @Kenneth Wiersema we should compare the length of the top rail on robots 1 & 2. I think we may need to shorten it on robot #1 another inch on the outlet end. That may be one reason why chute eject didn't work as well as I expected. Also, we should decide if we want to insert the blocks in the top to maintain belt tension.
I'm printing a mirror image depth sensor mount so that we can move the sensor to the electrical side of the robot. This will improve the wiring situation and reduce the chance of disconnecting the sensor.
I'm also printing new mounting blocks for the front of the chute with a tighter fit on the hex shaft and the angled aluminum so we don't need the spacers.
We need to decide on the rear pneumatic mounts before I print a replacement for the broken mount.
Finally, we were talking about adding a second motor to the chute.
Is there anything else we need to do to the chute?
@Kenneth Wiersema @paul_vibrans @coachchee we have plenty of filament to print the chute cross bar -- 100cc needed, 225cc available. I want to revisit the design regarding chute angles, modifications to the lift pneumatic placement and strengthening before I start the print on sunday.
Tonight we made a fair bit of progress on the chute repairs on robot #1. We installed the new motor mount with twomotors, installed stiffening blocks in the back of the tubes to support the versablocks better. new front mounts were printed that will fit tighter. the depth sensor was moved to the other side of the chute to shorten the wiring. and we checked the length of the top bar (its shorter than robot #2 by about 1.5"). I will modify the design of the pneumatic mounts tomorrow and get the print started on sunday so that it will be ready to install on monday. On monday, we still need to test the motors on the chute. We will need the #electronic_pneumatics team to provide a new controller for it and the #programming team to use it when ejecting Cargo.
@Kenneth Wiersema @paul_vibrans I worked on the chute angles again and suggest we lift the chute from the center hoop instead of at the back. This is so we can lift higher and avoids possible interference with the hatch handling. I found a mounting location for the lower end of the pneumatic cylinder that allows us to try both positions. Screen shots showing the two configurations are above. Both configurations have a chute angle of about 33.5 degrees in the low position, but in the high position, the angle improves from about 45 degrees to 50 degrees. However, in the images below you'll see the interference problem with the hatch handler. Avoiding interference will raise the low position a few degrees.
In the high angle position, we still have other interference problems with the climb system and with the intake. This does give us the best chance at the cargo ship though and it also reduces interference with the hatch handler.
What are the interferences with the climbing system and the intake?
For climbing, the front hoop scrapes the aluminum cable termination. Last I looked, it's about 1/8" interference on each side. For intake, it's the top rail of the chute and the main intake bar. I really don't want to lower the intake arm when we raise the chute -- it's just asking to be ripped off by another robot.
I don't know if these are totally critical, but I do expect them to keep the chute from going up to full height. When we add all the changes we made, we might be able to eject into the cargo ship ok. If not, we'll still have to back away a couple of inches.
Once again, the interference issues I mentioned are all about the chute going to full elevation when we're at the cargo ship. nothing new really
We can remove a small amount of material from the cable terminations, about 1/8" on each side. I don't think that is enough to solve the problem. What happens when the chute hits the intake arm? Can we notch the top bar sufficiently to clear without preventing proper ball transport? The CAD profile indicates the top bar clears the hex shaft with the chute raised.
I don't know what happens when the top bar hits. It may keep it from going higher, it may interfere with ejection, or it might not matter at all. We need to test it. I'd rather not touch the climb towers - I think we're better off living with backing away from the cargo ship than messing with those cable ends.
The top rail doesn't actually clear the hex shaft -- its more like passing through it on the way up 🙂
We could experiment with making the top bar shorter in front, but I worry about not transferring the cargo ball cleanly between intake and chute
Does the top bar attachment allow the intake shaft to push the bar down when the chute gets pushed up? This will squish the ball, but I think that may be acceptable.
yes, the elastics will give it some play, and the polycarb also has a bit of give to it. Worst case is that pinching down in the front causes the back open up a bit. We may lose traction with a small ball.
Just watched the final match of Detroit Einsteins: https://www.thebluealliance.com/match/2019cmpmi_f1m3. Of all the robots I've seen that pass the Cargo ball through the robot body, 5406's robot does it the smoothest & most reliable. It'd be interesting to get a closer look at how they did it.