Reveal: OSIZR by ALBA

It’s later this week, so here it is!

OSIZR: Open Source In the Zone Robot by ALBA

Much like last year, the goal was to build a simple robot ideal for new teams and the early season. In order to keep the robot simple and cheap, a reverse double four bar was specifically avoided. The only other major goal for the robot was that it carry the mobile goal around and stack while carrying it. Many other decisions (such as the parts to use and how things were built) were guided by the goal to keep the robot minimalistic, easy to build, and cheap.

It’s very similar to last year. I initially imagined it would use less metal, but the mobile goal lift ended up taking up a decent amount.
Total cost came out to a little under $1300.
I’d say this represents a good list of standard parts to buy and also represents (approximately) the minimum price tag of a competitive robot.

The code is on github
It was programmed using PROS (of course :D).
It demonstrates basic operator control programming and includes a simple proportional position controller and slew rate control for the lift. Oh, and there’s a struct. People seem to be using those more lately, so maybe a good thing to try out if you haven’t yet.

While I’m not trying to argue that RD4Bs aren’t the best type of lift this season, I do think teams should keep in mind that the speed with which they can stack is as important as the height. If you are able to score all of the cones at your first tournament, then you are doing pretty well, but if not (most early matches won’t get close), then you should build a robot with matching height and speed capabilities.
Also, RD4Bs are a pain. Yes there are a lot that seem to work perfectly on youtube from skyrise worlds, but those are from top-tier teams who spent a whole season on them. If you’ve never built and competed with an n-bar linkage before, then I wouldn’t go straight to the RD4B.
You’re welcome to argue/discuss below :slight_smile:
The starting bar: The 3.25" wheels don’t seem to have a problem with the starting bar, but the gears on the drive do, especially when holding a mobile goal, so if you were to build this, you probably should use chain (which I didn’t have enough of) or pillow blocks (and maybe 4" wheels). Also, the arm towers would need the bottoms cut off (which I didn’t want to do because now I need to build a 24" robot and I’ll want 18" c-channels).
This is getting too long. There’s more I could say, but I’ll save it for questions. I’m guessing tl;dr set in about two lines after the video anyway.

I didn’t take a bunch of pictures this year or finish a CAD model (partly because I’m guessing no ones cares too much), but if anyone wants more details, then I probably can provide pictures or at least explain. Let me know what you think, criticism is welcome!

Finally someone shows the power of a robot that carries the mobile goal with it!

What about the two extra motors?

very impressive for such a simple robot

Simplicity at its finest. Great job, it should really send all teams (new and old) in the right direction.

I’m glad you asked! (Thanks for catching my typo by the way)
Last year’s robot also only had 10 motors. The reason is so that if anyone builds this, they can decide for themselves what to use the last two motors (or pneumatics) for. The robot is meant to be a starting point, not an end. Only using 10 motors encourages that.

To answer your question, before building this I would have said lift or drive. But now I’m not sure. You probably could make the lift faster without more motors (I never tried a faster gear ratio and it never has overheated) but controlling would likely be the biggest challenge. This thing is already rather wild.

Right now I think that making tasks that require precision (10 point zone and intaking) faster would be the best improvement. How one might use motors or not to do that I’m not sure. I do think that the attraction to passive so that more motors can go on the drive and lift isn’t good if passive is slower than powered.


I mean damn, that’s pretty good!

Love the robot! I’ve been a fan of the pick up from the top claws for months

I love it how now a days a robot that integrates two different lift styles along with having slew rate and a p control is now thought of as “simple”. Great job though I’m sure this robot will inspire many teams (such as my own) into building within their means. Having been part of a team that has built a solid R4DB I can attest that they are very hard to build well. The best part about this bot is it is a way for many “steel” teams to be able to build something competitive.

Now that’s a great robot. Brilliant. Well done. Every year, starting designs are usually very complicated and ineffective. Later in the season they converge towards simple and effective solutions. Thanks for showing us well ahead what one simple and effective solution looks like.
This is not building the SR-71; you can play most VRC games well with rather simple designs, if you get them right.

Epilepsy warning

Every season it’s amazing how good simple robots can be.
It’s also worth pointing out that the smaller one of those Wingus and Dingus robot’s (7682E) continued to be successful all the way through to NZ nationals that season. 7682E was only able to build 4 sections and stack cubes on the low and medium posts, and still went undefeated in their division.

I don’t remember if it was in the video, but can your robot put mobile goals with stacks on them in the 10 point zone without going over the bar? Great robot!!

I don’t know why going over the bar would be a problem.


Yeah, I think the ability to come down on cones is important. This one could still use some improvement to grab them tighter.

Haha, yeah. This whole game is complicated and things sure have changed a lot from when no one had heard of PID and now it gets thrown around.

Haha, yeah all of my videos should probably have that

I love their little robots. Kind of wish we had built something simpler that worked 100% that year. I’m guessing this game is gonna be hard to max out like skyrise.

I honestly haven’t tried; I should have thought of that. I don’t think it should be a problem, but I can get back to you on that

How do you plan on accounting for going over the bar in programming? From what we have researched, going over the bar will cause autonomous routes to be exetremely inconsistent/unreliable, which is why scoring without going over the bar would be a better approach to scoring.

I won’t, because I think programming skills is a waste of time (if you enjoy it, feel free to enjoy it. I will be impressed with your efforts). I also doubt that autonomous programming routines will get so complicated as to require me to go over the pipe and then back and then continue doing something else within a mere 15 seconds.

I think the strategy for early season will be to stack preloads on the stationary goal.

@Aponthis We are in an incredibly competitive state where skills is very important for qualifications. We know that this most likely will be a problem we have to overcome, so we are just trying to think of ways we can solve it while we are in the designing stage.

This is actually very similar to what I am planning to do.

Nice and simple

Nice work, I’m glad the tradition of posting fully (well somewhat) documented, low cost robot designs is being kept alive.