REV Robot Reveal
By Tycho, Austin, Charlotte, Omar, Evan, and Janavi
Argos V2 - a REV Robot Reveal
This video was pulled from Argos visits to: The NSTA STEM Expo in Kissimmee FL, in the path of eclipse totality in Tennessee, and in North Texas at The Dallas Makerspace, The Southwest Center Mall, Southside on Lamar and the Frontiers of Flight Museum. We hope you find it interesting:
Task: Compare build designs for the cryptobox intake system
The block scoring system is going to be an integral part of the competition this year, and it will have to built sturdy. It’ll have to be reliable for us to have any shot of winning any matches. So we got to brainstorming. We spent a while at the whiteboard, drawing up various mechanisms and ways to pick up blocks. One idea was the idea of a block delivering system similar to those modern vending machines that have two degree of freedom movement. We began to design the contraption so that a conveyor belt could be placed on an up and down linear slide to position the blocks just right to make the different symbols. Another person came up with the idea to use our tank treads from Geb, our competition robot from two years ago, to push the blocks up a ramp and deposit them into the cryptoboxes. Neither of us could convince the other about what was to be done, so we both split off to work on our own models. Next week we will keep working on this build off of the century.
After the game reveal video was released we had some ideas on how to
have our robot grip onto the blocks, but we couldn't test it without
a makeshift glyph to hold onto. So we decided to upcycle some old
cat and weather damaged field tiles by cutting them up into 6 X 6 squares
and placing them in a cube formation. Attached below is an image of our
handiwork and a image of the glyphs used on FTC fields
This did not end up work very well and in hindsight we could have used other materiel
like printing out a 6 X 6 X 6 frame on the 3-D printer or by making it out of foam board
so it would be more similar to the real thing. But thanks to the generous donations of the
DISD STEM department we were provided with a full field set so we don't have to worry about creating
our own glyphs. However, we will remember this for the future.
The sun came out and it was back to the field. We got started right away, both of us building our designs. Since the cryptoboxes were wider than the 18 inch sizing cube, we started by designing a fold out for the conveyor belt. This was entirely proof of concept, purely to see if it was at all aplicable in the game this year. We spent an hour or two gathering parts and put together an extending conveyor belt. This device would swing down, like the arrow suggests, allowing for more space to move the blocks back in forth, giving us accuracy in rune completion. This will be later attached to linear slides, allowing for an up and down motion.
Over the past couple of days we’ve experimented with a horizontally mounted track system that we had hoped would serve to move blocks through the entire length of the robot and into the crypto box. Immediately we noticed a few issues, the primary one being that the tread was static in terms of mounting and therefore wasn’t accepting of blocks when feed at an odd angle. To correct our feeding issue, we widened the gap between the tracks and added rubber bands in hopes of maintaining traction and adding to on demand orientation ability.
Initial tests of our second prototype went fairly well, however the design suffered from some severe drawbacks; the first was its weight and size which would limit robot mobility and take up much needed space for other components, the second issue was that keeping the treads tensioned perfectly for long periods of time was nearly impossible and they would often sag leading to loss of grip, and finally the system was still fairly unpredictable especially during intake (blocks were flung occasionally). These finding lead me to believe we may scrap the idea in consideration of time.
Aside from our track intake we’ve also been working on a gripper and slide system that shows promise.
In an attempt to get a working lift system before the coaches meeting we will be presenting at, a linear slide has been attached to the robot, along with a pair of grabbing arms. They work surprisingly well and aren’t as complicated as my idea. Plus the importance of speed has really taken hold on me this year. We need to be as fast as possible but my contraption is slow compared to the grabber arm. I think we'll be scrapping the idea for this grabber arm bandwagon everyone seems to be hopping on. While the grabber arm allows for quick pick ups and easy placement, our idea was only bulky and unnecessary because of our use of mecanum wheels which eliminate any need for a system to go side to side. Since the grabber was rudimentary, we’ll be making improvements and new iterations. We toyed with some materials earlier on in the season, and we’ll probably be implementing that into it.
After determining that the treaded channel was much too buggy to perfect with the time we had, we shifted attention to other scoring systems like grabbers, however before finding the right grabber we decided we needed to get the track for it completed first. We’ve had experience in the past with all sorts of rails from Tetrix kits that convert their standard channels into lifts, to the newer REV sliding rail kits which we also toyed around with in initial prototyping shenanigans.
One of our key concerns was also wear and tear, in that we have had systems slowly breakdown in the past, such as our mountain climber and catapult, since they had plastic components that broke over time, we knew that long periods of use over multiple competitions would deteriorate the plastic components of either rail sets, and other rails that used full metal parts would simply be bulky and rough to fit in snugly with our robot. After a bit more research we settled on standard steel drawer slides from home depot, mainly because they were streamline and all around sturdy. The slides also provided us with easy mounting points for our future claw and attachments.
We understood that whatever option we picked for slides would have to be easily repairable or replaceable during competition, should something go wrong. Since the drawer slide were easy to come by and needed little modification we could easily make duplicates to act as stand by and demonstration parts during competition.
These positives came to form more than enough of a reason to continue prototyping our grabber that would eventually be attached once completed to the lift, which was now mounted to the robot and used a system of spools and pullies to extended above the minimum height for scoring in the top row.
The games have begun and it’s time to build. So that’s what Austin and I did. A war had been declared. Legions of the indentured collided on the battlefield. Millions were slaughtered during this new age armageddon. Austin had his army. I had mine. Two different ideas to do the same task: lift glyphs into their correct positions. A simple job but one that caused a rift in Iron Reign, an incurable rift between the forces of light and darkness.
But then I decided to stop because his design had more speed than mine and speed is more necessary this year. My idea had been a lift that could move the glyphs back and forth but I realized that it would be a little too slow for the competition. Or, another solution would have had a side to side conveyor belt that moved glyphs back and forth to arrange them in the correct order, and then push them into the slots. This movement would have been separate from the four mecanum wheels that we are using in the chasis. His idea was simpler than mine, a conveyor belt that ran through the middle of the robot to bring the glyphs to the keybox, where they could be slotted in with the side to side movement provided by the mecanum wheels. So, like an outnumbered Supreme Court judge, I decided to join the winner so I could have a say in the early design. Once he got a prototype ofhis contraption working, it was able to pick up blocks effectively but it still needs improvement. It has issues with blocks at an angle, and it has trouble slotting the blocks into the keybox, but it's a nice step toward a working block system. We are currently planning to use the mecanum wheel base we used last year but this could change anytime. We left practice with a direction and that's better than nothing.
Task: Design the grabber design and make future plans
The grabber has been evolving. A column made of a turkey baster and a wooden dowel attached to servo has come into fruition. The first drawings and designs are coming along, and some 3D printed parts have been thought up to allow the square dowel to become a hexagon. An adapter of sorts. The grabber and lift have been outfitted with a back board to stop blocks from getting caught underneath the backing bar. The back board is just some 1/16th inch wood cut to fit. The new turkey baster columns are in the first stages, so more info on them will come as more is discovered and progress has been made. The sketches will explain these designs better.
With our single degree of freedom lift fastened to the robot we focused on the appendage that would grip to within an inch of its life any glyph we fed it. We initially toyed with simple tetrix channels to form a make shift rail that would hold axels for pivoting points, however we found tetrix to be a bit too cumbersome and decided to use rev rail instead. Using two tetrix U-brackets we built a makeshift grabber that used rubber bands and a servo to secure blocks without letting them slip through its grasp. To add extra grip to the long L-beams that formed the pincers of the claw, we added even more rubber bands, and moved on to testing.
Initial tests were very positive, the high strength servo coupled with a few rubber bands maintained enough of a grip on one or two blocks with ease, and because the entire system was mounted to a rev rail we could easily slide and size the pincers to the right distance. Feeling confident in our work we attached the grabber to the lift and attempted drive practice, which ended relatively quickly due to a surprising number of jams between the lift and glyphs.
The key issue we now faced was that as the lift returned to its home state blocks were getting stuck beneath the retracting claw causing jams. To fix this relatively simple problem we added a back plate to the claw that kept blocks from slipping to far into the robot, this was easily fashioned out of a bit of thin wood board we had lying around from the decks of other robots. The overall performance of our glyph wrangling device was astounding, so long as whoever was operating the robot was a well-trained driver.
We were tearing up our glyphs like this because our wheels had no guard for their screws:
More specifically, we had multiple issues with damaging the glyphs. First, the exposed screws on the mechanum wheels (Fig 1) tended to cut into the glyphs as seen in the above picture. As well, you can see relatively sharp edges on the wheels where the block could also be cut, and that the blocks could be pinched by the wheels on the wheel. As well, the corners on the REV and TETRIX pieces cut into thr glyphs when they were rammed into the walls of the field (Fig 2).
Because our robot at this point has merely become a collage of prototypes that we compete with, there are often subtle improvements that need to be made. Starting with the wheelbase, Abhi has written a blog about the shields we printed to protect the glyphs from the gnashing bolts of our mechanum wheels, and we also tensioned all our set screws and motor mounts to make sure that our base was preforming in terms of the speed and strength we needed. As we add components to the robot things often are shifted around as well, after tuning up the drive train we focused on realigning our REV expansion hubs and their wiring so that nothing would be in the way of critical lift or drivetrain components.
Any jettisoning bolts that have been catching components while moving, and any sharp edges have all been ground down to ensure that any motion is smooth and that there are minimal catching hazards during operation. Because of the earlier mentioned prototype state our robot was in, many of the key components laid outside of the 18 inch cubic limits and so these components we brought in and neatly fastened to the internals of the robot bearing in mind ease of access for future updates to components. This entire push for cleanliness was the result of upcoming scrimmages and practice matches that we would be participating in.
Since damaging field elements is a huge no-no, we needed to fix this, we decided to create a 3-D part to protect the glyphs from our wheels
During the first attempt, I had just self taught Creo hours prior to construction. As a result, I was
not very precise nor efficient in my design. Nevertheless, we recognized that there were some
basic shapes we could use for construction such as a semicircle for the bottom half and two rectangles
on the top part. We decided to use measurements that were estimated from a singular mechanum wheel.
This culminated in the design below.
The part itself is made out of nylon as usual. Our main issue was measuring the wheel accurately to create a functional part. The two parts hampering the design was that the U-shape must be off the ground slightly, and that the shape's semi-circle would not have the full radius of the wheel. So, we iterated through various designs of the U-shape, changing the height off the ground by ~1mm each time. We also varied the radius, until we realized that we could measure the width of where the semi-circle segued into the rectangle and get the estimated diameter of the semi-circle.
Refering back to the design of the wheel guard, we decided it was time to actually mount it on the robot.
At first, it seemed like the part was perfect for the robot since it fit just snug with the
screws on the wheel. However, upon mounting, we discovered the following:
Turns out that the part is acutely shorter than the real height of wheel relative to the
horizontal axis superimposed upon the vertical plane. As a result, a second and better
trial for modeling needed to be conducted. For this run, I chose to measure the dimensions
directly from the robot rather than a spare wheel.
As seen above, the corrected version of the part looks and works much better. Though there is a slight
margin of error in the success of the part due to the dynamic nature of the density of the field tiles
, the part should be reliable for the most part
The jewel thief, the mechanism for knocking off one of the jewels, was going to be one of the tougher parts of our bot to integrate, based on the chassis we began with. But, with a little engineering and some long thought, we came up with a few ways to implement it. First, we began with a side mount, and it was alright for the angle, but we switched our autonomous plan to begin pointing forward, presenting me with a new problem. The part we had used before would simply not work. We tried a modified version of the pusher we'd made, but it didn't fully suffice. It was impractical and would require more than a little wire extention for the servo. We finally decided that a frontwards approach should be taken from the side. Instead of a single middle forward facing prong, a two bar prong sticking from either side, meeting in the middle, and providing a platform for a potential relic placer. While not completely finished, we intend to have it done by the first qualifier, fully functional. It should allow us to knock the jewel off during autonomous effectively and efficiently, although that’s all to be seen.
The task today was simple. We replicated the prior work with the first gripper, as stated in the prior post, so we can begin connecting them.
The biggest problem was finding all the parts to make it. We are hoping we can connect and mount them in the
next couple days so it will be ready for the qualifier in Oklahoma. The improvement over last post was the addition of the rubber gripping material, as found in our "Material Test" post.
Task: Become experts at driving the robot and scoring glyphs
Iron Reign’s robot drivers Abhi, Charlotte, and I, have been working hard to decrease our team’s glyph-scoring time. The past
few meets, we have spent many hours practicing maneuvering on the field and around blocks, something that is crucial if we want to
go far this competition season. When we first started driving the robot, we took approximately 4 minutes to complete a single column
of the cryptobox, but now we can fill one and a half columns in two minutes.
When we first started practicing, we had trouble aligning with the glyphs to grab them. The fact that were using our prototype arms
was partially at fault for our inability to move fast and efficiently. We also had some human error to blame. Personally, it was
difficult for me to not confuse my orientation with the robot's orientation. In addition, our drive team had yet to establish a
communication system between the driver and the coach, so the driver had no guidance as to which glyphs seemed like the easiest to go
for or whether or not the robot was in position to grab a glyph. Below is a video that shows our shaky beginning:
Our driving has improved significantly. We have done mock teleop runs, timed ourselves on how long we take to complete different tasks,
and have repeatedly tried stacking blocks and parking on the balancing stone. When our robot doesn't break, we can fill up to two
columns of the cryptobox!
Overall, we feel that we can further improve our driving skills with more drive practice. Driving the robot really does require being
familiar with your robot and its quirks, as well as the controls to move the robot. Abhi, Charlotte, and I know we are still far from
being driving experts, but we are putting forth our time and effort so that we can give it our best at tournaments.
Task: Learn how to Assemble parts in Creo Parametric
In addition to making parts to print in Creo, it is sometimes useful to combine multiple parts to make a model. For example, we can
make a robot model by assembling parts in Creo. We have conducted a video on how to do so.
For this tutorial, we first created two simple parts which fit snugly inside one another (done before the video). Then, we created a new
assembly file and uploaded the bigger part first. We placed the smaller part and did the assembly by matching the sides of the cylinder.
That is how we ended up with a cylinder with its hole plugged in the end.
We hope to use Assemblies to make models for various structures in our robot in the near future. We hope this tutorial helps you with
The basters are here and in full swing. We spent a late night putting together the two intake columns. They were attached to a backing by previously, allowing to finish it by attaching the final servo and tieing it to the two columns. Since the new intake needed new code, we whipped up some code to allow us to have control. Upon doing this he realized we needed two controllers, one for movement and controlling the lift, and a second purely to work the two columns as they spun. This allowed the operator to operate the whole robot just a little easier. The new columns are set on a majority REV base, allowing for more choices in design that normal tetrix doesn’t provide. The new grabber has already been placed on the robot and seems to be working smoothly, only time will tell if it is a long term solution.
At the Oklahoma qualifier, we saw numerous teams with similar systems to that of ours. However, since we had the mobilized gripper arms to stack with auto alignment,
we were able to collect glyphs easier. In spite of that, after observing other teams in action, we realized our current gripper method had the issue of not being ready by the time
we got back to the cryptobox. This is because we had to turn around everytime we needed to pick up glyphs and we also needed to pick up glyphs. This leads to longer time
to fill the cryptobox, something that is not good if we plan on recovering the relic later in the season. As a result, we decided to upgrade our arms to a new level: a chain
based intake system.
The idea behind this system is that the grabber arms would be on a mobilized chain system, kind of like a conveyor belt. One of the reasons this is much faster than
our old system is that we don't need to turn our robot around as we approach the cryptobox. We can drive forward, pick up glyphs, and as we drive backwards, we can use
a toggled button on our gamepad to move the grabber arms to the back of the robot upright. As a result, by the time we get back to the cryptobox, we have the glyphs ready to place.
Another benefit of this new system is that we don't need to stack glyphs. When we drive forward to pick up glyphs, we can tilt the grabber arms forward so that even if the pre
stacked glyphs look far apart, they can still be in-took with the tilted system. Also, this system can be used for intaking the relic in the future. If the chain system is placed
on an elevated level on our robot, the grabber arms will be taller than the field walls. Because of this, if we pick up the relic when it is on the ground, we can place it easily.
This picture represents our current progress. We hope to complete this system soon so we can test it on the robot.
Version 2 of our gripper arms worked much better than our original. Due to their silicone material and trianglular
shape, we definitely had more control over the glyphs than our one degree of freedom grabber arms. However, we still
had issues we needed to address. When glyphs were taken in, since the silicone surface did not have much mobility
and compressibility, glyphs would often fall. Due to slight changes in glyph size, the bigger glyph would determine
the space between the grabbers, meaning the other glyph would be mobile despite us wanting its control. This is
when we develoepd the first version of our new rotators.
The first edition of our rotatory mechanism allowed us to play with ninjaflex printing and flexibility. They
were 15mm extrusions designed to stack on one another on a REV rail or similar rigid structure. Since
Ninjaflex can bend, we got more grip on the glyphs. It was definetely a well designed model but had many
issues. First, each fin of the fan was very thick. Though it was able to grip glyphs well alone, the system
was not able to grip much better when stacked together. We decided we needed more surface area contact with
glyphs during intake.
This led us to create a new model with thinner fins and thin tabs at the end. The thin flaps allowed more grip area
with the glyphs allowing us to work better. Though good in theory, when we went to print out the part, we discovered
our 3-D printer didn't allow printing vertically of surfaces less than 1 mm. Since this idea didn't work, we started
thinking of the idea of suction cups. This led us to our current design.
The design worked very well. We decided to name them Octopuckers since they had suction cup shape and there were
8 fins to a pucker. The surfaces of the octopuckers which would contact the glyphs were large and had a large area.
Since this was heavier than the bridge connecting them to the center, the branches bent easily allowing for a grippy
surface which was also flexible. After testing it on a small scale, it seemed to work well so we will continue development
and implement it on our next edition of the grabber arms.
The jewel thief we built before *worked* but that was about it. More often than not it failed by not hitting the jewel, or even worse, knocking
off the wrong jewel due to instability. And, in the Greenhill Qualifier, we lost several rounds by the margin of error that could've been fixed
by hitting the jewel. So, we had to redesign it.
The jewel thief was intended to be simple at first, it was comprised of no more than a 180 degree rotation servo and an arm with a standard rev color sensor. The arm was foldable and collapsible so that it would fit inside our robot, and as the servo turned out to its extended position the arm would open up with the help of a single bungee cord. This plan had a few inital downfalls: first the arms were rather large and clunky and never really folded well into position, second the arms was heavy due to the use of tetrix bars meaning that the servo would strain, and finally the overal position of the arm was inconvenient for our autonomous programing, so we moved on completely. Rather than focusing on a single arm that could extend to reach the jewels, we decided to focus on something that would conform well to our current setup and then focus on making it long enough to reach. We realized that the outer edge of the robot was open enough to contain a V-shaped device that would rise 180 degrees over the head of our robot. The immediate perk to this was the fact that the system would be 18 inches in length. We felt no need to update which sensor we were using at the end of whatever mechanisim we finally attached, since the rev color sensor served it purpose correctly and effectively each time we had tested it in the past. Our final design was the V-shaped rim that laid flush with our robots exterior and was made from cut and bent L-bracket and was moved with two continuous rotation servos.
The world advances on innovation. We strive to make the most efficient devices and aparati to complete jobs for us. There’s a hundred different ways to work a task, but only one will be the best at functioning in the areas of efficiency and timeliness. Just as America runs on Dunkin, advancement runs on efficiency. That’s why the robot must be outfitted with a flipper system to intake and deposit blocks. It’s the only design that will make it to the world competition, and it’s the only way that we will make it out of local competitions. I personally have taken it upon myself to develop the prototype while the majority of the team is focussed on a new grabber arm.
While our grabber arms were *good*, they weren't great. The arms currently attached to the robot, which use the turkey-pans, didn't grip as much as we hoped, and while we're designing a new version which has specialized 3-D printed arms, we can't put all our eggs in one basket. So, we decided to make the flipper system. The advantages of the flipper system as compared to the other systems is that the flipper system:
Does not depend on friction to hold blocks
We had previous issues with block slippage with the arms model, and this should fix our dependency on high-friction materials.
Our old arms depended on stacking to get more than one block, while this one wheels blocks in, reducing the time needed.
Less precision needed
Before, we had to align blocks directly with the arms to pick them up, but this can just use the wheels to intake blocks.
So far I have built a flipper and an intake system, both that function well, but have yet to get the teams’ permission to attach it directly to the robot, as it would require a lot of dismantling. Since it won’t be able to be put on before the upcoming Wylie qualifier, it’s been put on a backburner as I also throw myself at the new grabber arm. The flipper is being held in a frame I built around it but as a system is comprised of a board attached to a servo attached to a drawer slide that works as a vertical lift. The intake system is composed of two intake wheels made of the same foam tiles that make up the field floor attached to two axles that are chained to two opposite rotating gears powered by one of the new REV motors. The intake works with the flipper well and only needs some side guards. I’m half of the way through designing. It should be on the robot before any regional qualifiers we go to.
When we designed our new grabber with the octopuckers, one of the variables we neglected was the width of the new grabber once assembled and resting. After the grabber was completed it’s width was actually greater than that of the housing bay we had built into the current drive train, so to get the grabber to fit we actually had to widen the bay. We had know from past experience that the base was never truly square, so we took this necessary widing as a chance to resquare the base and drastically improve the efficiency of our mecanum drive. We added ¾ inch to the inside base and the resquared the frame before finally bolting everything down and attempting to mount the new grabber. Because the closed grabber barely fit within the new widened bay we had to cut away portions of the frame over the front wheels to allow the octopuckers room to actuate.
The other key chassis modification needed to accommodate the new grabber system was a lift bolstering. We decided that to handle the newly doubled weight of the grabber we would share the load across two strings and convert to a double pulley system. The lift was also strengthened with newly squared and adjusted cross beams similar in length and angle to the other iteration. Because of the double pulley, we also centered the drive motor and utilized a second spool. The pulleys rest on either side of the lift system and are both being run by the same motor.
One of our issues with the previous iteration of the gripper was the fact that the material that coated the actual pincers weren't even and would often lead to blocks slipping from the bottom of the gripper and falling out. Our solution to this was to retest materials and in this process we decided to try our hand at 3D printing a circular and pliable material that could be part of our new rotating pincers. We designed the OCTOPUCKERS and built the rest of the grabber around that. Because the octopuckers were designed to slide onto typical rev-rail extrusions we also had to design a new system of bearings that could house the rails with skewered octopuckers.
We developed a “revolutionary” new 3D printed rev-rail bearing system that was liked with a series of chains and pulleys that could be attached to our current lift system and not severely alter the base and drive train. Previously the grabber was actuated via a system of servos controlled by a rev hub back on the main drive train, however in this newer iteration of the grabber, we decided that all of the necessary wiring would be kept inside the grabber to eliminate tangling by mounting the rev hub on the back of the grabber. While this grabber was a major upgrade that drastically improved our glyph handling capabilities, it did in fact double the weight that our lift had to bear.
Over the course of this past season, I have been learning how to use Creo Parametric to learn 3-D modeling. Since this is Tycho's
last year on the team (so far he has been our main modeler), I decided to learn from him so the modeling legacy would continue.
The first project I was tasked to design was the wheel guard on the robot. As a very early learner, I ran into many issues. For example,
I used to eyeball all my dimensions. This clearly didn't work out as evidenced by my epic fail of the first form wheel guard. However,
after experimenting with the constriants, I jumped all the early hurdles and learned the basics.
My first assembly project was to CAD the conveyor belt we hope to eventually mount the grippers onto. As someone who had never dealt
with assemblies before, I felt like someone going through a maze. Even assembling basic parts like an axle hub to the axle, it took me
10 minutes because I struggled changing dimensions and such. This project, though very basic, seemed impossible to me. However, after working
through it, I was able to become more familiar with constraints to apply to the next biggest task, the robot model.
So far this is what we have constructed of the robot chassis. After training on the conveyor system, I was able to complete the
chassis easier. By doing this, I have dealt with more constraints and have been moving faster.
After learning a lot so far from Tycho, I hope to finish the model soon and continue growth on the model. The only thing remaining on
the model is the vertical bars connecting the lift and the lift itself.