OFFICIAL DAY 1 ROBOT DESIGN THREAD

[Sam Hassall]

Toss in all early robot ideas/designs into this thread.

[sebastianf]

my first recommendation to newbies looking at this thread is to go over first history particularly 2008's overdrive game
here is the overdrive video. successful robots in the past can help you soooooo much by giving you design ideas.

https://www.youtube.com/watch?v=4a9KfpBZ4DQ

btw thats the 'big ball' robot we have in the shed at the school

ill be first to bring 118 to the table that are extremely mobile, can catch and shoot but to what accuracy?
https://www.youtube.com/watch?v=CAJBC-DDL9w

heres einstein finals for 2008
https://www.youtube.com/watch?v=NYNEAL_dK6I

atm what i like the most are wenched elastic shooters or armed robots i really dont know yet to read the manual be back in an hour

[William Surmak]

http://www.buildblitz.com/ 3 robots being built in 72 hours.

[sebastianf]

"For the rest of the match, drivers remotely control robots from behind a protective wall. Once all balls in 
autonomous are scored, only one ball is re-entered in to play, and the Alliances must cycle a single ball 
as many times as possible for the remainder of the match. With the single ball, they try to maximize 
their points earned by throwing balls over the truss, catching balls launched over the truss, and scoring 
in the high and low goals on the far side of the field. "


the big question becomes how to effectively time our passes- is it worth catching for the extra ten points but take an extra five seconds to do it or just rush goal with 3 passes

[William Surmak]

Interesting things to note that I found...
1.) In order for an assist to count the robots passing must be in different zones
2.) Question? What would happen if an alliance completed a number of assists but missed their shot into the upper goal? If the robot were to pick up the dropped ball and shoot it into the upper goal, would they still get the assist points? 
Answer: Assists only get reset at the end of a cycle (when a ball is scored) so you would still get the assist points.

Watch this is you're confused with assists https://www.youtube.com/watch?v=etLj6iytcsw&list=UUHA7zyPRS3VPDvl4ehss-zw

[William Surmak]

I believe catching should be a priority. Passing on the ground would be clunky, easy to defend, and hard to direct.  I don't think passing in the air would be too difficult with practice, you could line up on the edge of the playing field with another robot, have them shoot it, and move our robot forward or backward based on how far the ball is travelling. If you disagree, explain why.

[Sam Hassall]

I think catching is also an advantage. even if we don't catch, we can still easily pass normally as long as the ball doesn't bounce out of the white zone. If it does, we just lose some time bringing the ball back to the white zone then passing it. Remember, passes only count when each robot is in a different zone.


If we want to catch, we have to discuss with our alliances 

a) who is the best shooter; they will accept the ball in the scoring zone and shoot it
b) who is not the best shooter, and how far their shot goes; they will get the ball and shoot it to us over the bar
c) whether we are the best catcher; if not, we need to be ready to either shoot into the goal, shoot over the bar, or accept in the middle. I think I know how we can accomplish both catching and shooting, but complex design decisions will require discussion tonight.

regardless, the design I have in mind is going to be somewhat similar to our big ball design, but with some very key changes. I believe we can accomplish shooting without a camera, as well. No laser pointers- too hard to see. One team had a lot of success using a really bright flashlight for aiming. it provided an easy to see target, but its key advantage is that by looking at the light's size relative to the shot opening it could allow distance estimation. 

However, the scoring zone this year will not have a large reflective/visible area around it, so a camera might be required. again, this will require experimenting. however if we can put a physical sort of reticle in front of the camera- little wires, perhaps- we can cut down on code required versus putting an overlay on the camera image. I don't know how hard that is for will to do, and I don't know how far we are towards having basic streaming camera code.


depending on our design choices, this game could be accomplished very easily if we stick with good designs- and I think I have one. it'd also look really cool.

[William Surmak]

Camera is just for autonomous, to track when the lights turn on for the target.

[sebastianf]

which you just look for some flappy shiny thing on the side of the goal

[William Surmak]

Well if everyone seems to agree that catching is a priority, we need to find out how to accurately catch those balls. They bounce quite easily so we need a way to clench the ball once it lands in our robot.

[sebastianf]

youll just need something to dampen the energy of the falling bouncy ball before it reaches the harder plastic surface of the ball funnel (if thats what youre leading to)

[Sam Hassall]

You don't have to dampen the energy of the falling bouncy ball if you have touch sensor activated "fingers" that snap down on it quickly. Very little code.

[Jane Elizabeth]

Re: Sam's post about alliance communications, and given the integrally assisting nature of this year's robot...

Has it been discussed yet amongst our team if we wish to make some loose strategy alliances ahead of time, as 1114 does with 2056? The roster of attendees for UOIT and Montreal are on usfirst.org. Would it be worth sharing more-than-usual design information with, say, Les Aigles d'Or from Montreal, who will be at both competitions? Waldo will be at UOIT, but not Montreal, but they would be close by to practice assists with. Or any other teams on the rosters who might be interested in a little assist-collaboration ahead of time?

[William Surmak]

Yeah, like Sam said, there would be a switch at the bottom of our collector, and when tripped something will block the opening like an air ram.

[Sam Hassall]

Alright, I think I know how to grab, catch, and shoot. This is a very very simple and rough inventor sketch. 

https://i.servimg.com/u/f58/18/68/43/43/grabbe12.jpg

This entire assembly is mounted so that it tips up and down. the four "fingers" that are currently in their closed position are 1.5 feet long so that they are able to grab the  2 foot diameter ball without being too long, and without being too short. The claws are at a diagonal to the ground, making an "X" when sitting, not a plus.



the fingers rotate 90 degrees from being open to closed, making an even bigger X when open. they are mechanically actuated by rods that are turned by a single wheel (aka only one motor, probably a fisher price made really slow. will explain more at the meeting, I know it doesn't make any sense right now) and when in "catch mode" can be closed very quickly by touch sensors on the cross part that can close them in a fraction of a second. The wheel/sprocket that is attached to the mechanical linkages has an opening the same size, and in the same spot, as the hole in the middle of the grabber. The hole for what, you ask?

the ball will be propelled by a surgical-tubing powered plunger in the same way our big ball robot did. Because it keeps it simple stupid. (KISS). When the ball needs to be shot, the entire assembly will rotate upwards (I know how to do this as well) and shoot by sending the plunger towards the ball. When that command is sent, the claws will simultaneously open very quickly, and the tenth of a second or so delay in the delivery of the plunger, combined with the deformation of the ball, should make it so the ball is hanging freely just as the plunger hits it. This is because the claws will have rubber grip on them. I suspect that they will not need rubber grip, however, and can probably stay there to guide the shot for a second.

For aiming, we will have a set position for the claw to rotate, and a camera set up so that when an onscreen reticle is lined up with the upper goal, it will go in. This shouldn't be hard to do, and it will let us act as both a catcher and a shooter, if needed.

pickup can be accomplished a number of ways, most likely just by tilting the grabber down to ground level (the arm will extend off the robot perimeter slightly when in the down position, and be within in the straight up ball carrying position unless we want to bring down the centre of gravity) and driving into the ball. it can work just like "catch" mode- the ball should bump up and into one of the catch sensors and shut the fingers. the fingers can also open partway and close to get the ball into the right position, like our big ball robot did.

Drive can be accomplished through whatever we deem needed, as this design should be completely separate to the drive system sitting on top.

Note: The stationary cross could also be canted slightly inwards to form a cup for the ball, but at the moment I'm not sure what would work better. Also, a three-finger grabber should also be possible, if we want to lower weight or extend less robot stuff outside of our frame.

[Sam Hassall]

When open, this design allows for a massive surface area that the ball can hit, and now that I think about it the thing should be canted slightly inwards to allow for a bucket effect no matter where the ball hits.

[Sam Hassall]

Also, responding to jane, I think we should definitely team up with Les Aigles D'or. We have the history to succeed again, and they are also really good. Practicing with the waldos, and alliance-ing with them at UOIT, would be awesome. They're a very good team. the three of us would make a great alliance.

[William Surmak]

Are you saying the switches will be mounted on the "fingers" or the cross? If there is no switches on the fingers, what if the ball makes contact with the fingers in the open position but not the cross, if there is no switch on the fingers then the ball will simply fly off. The more surface area to catch the ball the better.

[Sam Hassall]

There will be switches on both, thanks for correcting me.

[Sam Hassall]

Also the 3 day robot guys from vex are testing their funnel. 20 inches past the outside of the frame is a LOT more than you'd think.

[ErikNikiforuk]

I like the idea Sam. the "fingers" prongs, or whatever they're called i think will work, but I think it would be better for catching if the 2 bottom ones were to be stationary, and only the top ones open up, that way when the whole assembly is rotating, we can line up by the angle the ball is coming, then the top prongs snap shut. I think that would be greater accuracy.

When picking up the ball, whether the bottom prongs are stationary or not, we may have trouble with the ball just being pushed away from the arm. It would be nice if we could have some kind of suction on the surface so that once it touches the ball, it doesnt just roll away. Or if we had a way to go straight down on top of the ball to pick it up. explain to us tonight.

Also the stationary ones on the bottom will help us because the camera not moving. if the camera is on the prong, if the prong is opened, you're not going to see the ball if you are trying to catch it, or pick it up. but if it is on that stationary prong, it will not move, thus allowing the driver to see where the ball is to pick it up, angle to catch it at, and where to launch it. 

A downside I thought of the all moving prongs, is the ball already has momentum, and since it does, it will keep on moving until it is stopped (one of neuton's laws), so the bounce on the surface of the sensors will send it back (also a reason for suction), but the prongs can either stop it, make it bounce around against each other, or let it fly out at a different angle. having the two stationary ones minimizes the risk of these.

Also when shooting, it will be easier for the ball to have a track to follow, so that when it releases, it doesn't just fall like a centimeter before the shooting thingy hits it. this is so that it hits the center of the ball and goes where you want it to go, and not at the wrong angle. (This is for best shooting accuracy)

[Sam Hassall]

I like the idea of the bottom two being stationary, Erik, I hadn't given it much thought.

I was also looking at spinning wheels on the pickup assembly to suck in the ball, but I hadn't really focused on pickup at the moment.

although I spent all afternoon on this design, after looking at the robot in 3 days guys and teams in 2008 videos (2008 was a very very similar game) I've realized that it's probably too complex. This is a very simple challenge design-wise.

[ErikNikiforuk]

Also a way to bring in the ball from the ground, we could possibly use another arm (great more parts...) that extends out and drags the ball in towards the grabbing assembly.

[kenneth]

I'd have to say passing over the truss might be a little less predictable since you would be depending on having another robot capable of catching. You could have a mechanism that inherently has the capability to launch the ball over but before bouncing around too many design ideas, add up where points are and how much time it would to acquire those points, then finding design constraints for getting those points.

For example, max points in autonomous is 25pts in under 15 seconds. this would require that the robot can launch a ball and drive. Try to avoid immediately designing mechanisms before figuring out what the robot should do.

-Ken

[sebastianf]

with this satellite dish idea i think were sorta concentrating/depending/assuming the ball will be in the air a lot. Were thinking a lot of that truss throw and that catch in the white zone but were forgetting about the ground pass between robots that will happen. also if the robot fails to catch a ball because of a push or for whatever reason is this idea going to easily pick up off the ground.

and kens right, maybe the catch isn't even worth doing in "average points/sec" timing because if you screw up getting the ball back in position may take a lot of time

[Sponsored content]