Team 62 Tower Takeover Early Season Teaser

Also, this design has a smaller cube capacity than tray bots (from the looks in the teaser) but it also can stack on existing stacks. This will likely improve throughout the season.

1 Like

care to expound on this statement? i don’t quite get it…

1 Like

and… glad to see 62 still doing early season reveals.

always a totally different approach to how my teams see the game :slight_smile:

4 Likes

What I meant by this is that tray bots lack versatility. They can only deposit one time (per tower) and have a limited number cubes that they can deposit. Once all 3 cube towers are placed, there is little that they have left to do. Aside from playing pushing defense, they can’t restack on an existing cube tower (without knocking it over) or use the multiplier towers to their advantage.

Here is a scenario that should be common for tray bots at the moment. Some might argue that creating and placing a high stack will take a lot time, which is true, and is why some teams opt for a tray bot for their intaking efficiency. BUT autonomous allows for each team on an alliance to create a stack and place it. If EACH team in on the same ALLIANCE is able to intake to their full capacity within autonomous and place the stack (which should be feasible with a good auton routine and good programming) (we’re talking 8 or 9 cubes at the moment), then they have the entire time remaining to place the final stack. Even if auton doesn’t go well, let’s say you program a fail safe to stop the deposit if a sensor senses that the stack is misaligned, you still can place the stack within the first few seconds of the match. This leaves you with so much time left to just focus on defense in a game designed for offense. I’m talking about a refined autonomous routine here.

Once again, I am referring to a dual tray bot alliance in which both teams are competent and can effectively use autonomous.

So, if you’re willing to focus on defense for an entire minute, then go ahead and use a tray bot. But I don’t think the purpose of this game is to focus solely on defense. I think a design like the one in this thread is more useful. Tray bots will reach their peak and then get abandoned or merged into better designs, I believe. Most traybots were ri3d anyways, they aren’t meant to be taken too seriously, they are moreso refined prototypes. Once the season actually gets going, we should see more versatile designs that can use the entire 2 minutes of a match effectively.

This robot (team 62) is a good example of the evolution of robot design. I think more teams are starting to realize the limitations of a tray bot.

5 Likes

think this discussion should be reserved in the other thread… dont wanna derail this.

but the gist of what i wanna say is that obviously there are 2 main schools of thoughts regarding traybot and stacker-bot.
and regarding traybot as ri3d (8059 is 1 day) that shouldnt be taken too seriously… well… internal stacker for itz and 2bc for tp were our ri3d too… so maybe ri3d designs should be given a bit more credits :slight_smile:

and just like this 62 ri3(plus a bit more)d design… it is amazing, and it introduces (as their usual tradition) quite a number of great mechanisms :slight_smile:

6 Likes

Why did you use 2.75" inch wheels @ 300rpm over the standard 4" wheels, @ 200? did you need to be lower to the ground to make the design work?

i believe 2.75 inch wheels accelerate faster but that may not be their reason.

Smaller wheel=more torque. Maybe their drive base wasn’t quite strong enough to get up to speed (accelerate) as quickly as they wanted, and this was their solution. They must’ve been envisioning a more precise driving game, so the full 4” wheel speed wasn’t necessary in their eyes.

Alternatively, maybe the bot was about an inch too tall to fit in the 18” cube, so they used smaller wheels to compensate (which is a sloppy mistake for such an experienced team).

On that note, possibly it was spacing in the chassis that required it, but that small difference in space should be negligible, but perhaps that extra slave was necessary.

Or, maybe they were just what they had handy and needed their other wheels elsewhere. (But I doubt they really have a limited wheel supply to that degree.)

1 Like

The smaller wheels were definitely not an “after market” production. I believe on the discord they said they had the wheels geared so that they would be as fast as 4” wheels. If I am not mistaken McChicken(the bot theirs is roughly based on) also used 2.75 or 3.25, either way smaller wheels. Since the scissor sits so high on the robot (the top of the scissor is close to the limit) they needed save as much space on the base they can. The reason the scissor sits so high as well is so that if your lifting bars start at a higher angle relative to the ground, it is easier to get it to a lifting position. People in Skyrise encountered this problem in scissors, one robot required about 275 lbs of (some type of) force to get their scissor off the ground. This is often why scissors often require more motors than DR(whatever)Bs

1 Like

The 2.75" wheels allowed us to maximize the distance between the contact points with the ground for increased stability. The base is actually pretty short (26 holes) but is still stable with 5 cubes extended 5.5" in front of the base (four bar out, lift all the way up). We are able to do this because of the chassis geometry and the nature of a scissor lift (weight shifts back as the lift extends).

That is assuming the same gearing. 300 rpm on 2.75" wheels is faster than 200 rpm on 4".

6 Likes

Hi…

just 2 questions…

  1. how well does the… passive cube holder keeps the cubes in?
    i am just wondering how well will it withstand opponents clashing their robots against yours. Because for passive, it is always a fine line to keep things not too loose and not too tight.

  2. looking at your extendable cube holder (great work btw), i would presume 5 cubes is not the max? there should be rooms for improvement? :slight_smile:

3 Likes

Can anyone please explain how this passive intake works

Hey!

Yes, you are definitely right, there is certainly a fine line to be cautious of with passives. The same goes for our passive cube intake. It could definitely use some work – we have run into some issues with cubes falling out because the metal and the joints are sometimes too weak to hold in a lot of cubes. We haven’t really had a chance to test against other TT robots yet, but hopefully the walls of the magazine will be enough to hold in the cubes, even under defense.

This leads into the second question as well – we only did a 1 stage passive elevator for time and simplicity. However, with some more time to put in we could definitely add more stages. Overall, there is always room for improvement, but we still have time to make some before our first competitions :slight_smile:

P.S. Looking forward to (hopefully, if everything goes well) competing with and against you guys this year at worlds – you guys always build amazing robots!

4 Likes

The passive cube intake is relatively simple – there are 2 bent pieces of metal (polycarb works too) with some mesh on them on opposite sides of the intake which grip the triangles on the cubes. Rubber bands between the two sides of the magazines apply enough tension to hold in the cubes. They are initially guided into that position with more polycarb as well. We just push the lift down, the intake slides over the edge of the cubes, and then when we lift up again, it grips the top triangles and holds the cube in place. Hope this helps!

3 Likes

The intake definitely needs a whole lot of work. For future iterations we would likely switch to some type of active intake. Using a single motor for both four bar and release really limited how we could configure and tune the intake.

The goal with this robot was to be able to “super stack” onto existing stacks. For this, we don’t see having an extremely large capacity as necessary but we could maybe increase that number by a couple. We originally set out to stack 5 onto a 10, but ended up only being able to reach to 8. This is another change we would make for the next iteration. Our scissor linkages are only 22 holes so there is a lot of room for expanding the height.

3 Likes

Thank you for the explanation!!!

1 Like

ri3d designs are great but there isn’t any actual time constraint. You shouldn’t be like my robot is better because I built it faster. People that do ri3d’s are very good at robotics and it is quite an accomplishment but giving more credit to teams that build faster I don’t understand. :slightly_smiling_face:

I do think though that the 62A and area 51 and Anomaly’s robot is quite good. However being able to hold more cubes is a big advantage people just need to figure out how to incorporate that onto a DR4B.

2 Likes

This is an unnecessary height but currently the lift my team has built can reach 12 cubes tall, stack 15, and can hold 12 cubes…However this robot design you have come up with is really great and has large potential.

1 Like

Why aren’t you able to stack to 24 then…

I would rather do 3 fast cycles of 5 to get to 15 than make unavoidable tradeoffs in speed, stability, complexity etc for larger capacity. At a certain point, you only need to stack a certain height to mathematically guarantee a win. With 3 stacks of 15 the color and tower distribution doesn’t matter, you have already won.

To touch on the discussion of tray vs stacker designs, here’s some of what we discussed when we were designing:

There are obvious benefits to tray robots-- they can process as they drive and have a larger capacity, but once they place a stack they can’t add to it. It’s possible that tray robots could end up being able to build 15 stacks reliably on their own and super stacking becomes unnecessary. Autonomous makes that pretty unlikely though, because both tray robots on an alliance would have to build and deposit max capacity stacks in auton. If you can’t max out your capacity in auton, and you don’t have an alliance that can add to your base stack, you can’t recover those cubes you missed and 2/3 of your points are final after autonomous.

1 Like

Again, nothing is stopping a lift bot from processing while they drive

1 Like