Articles by tag: innovate

Articles by tag: innovate

    New tread material test

    New tread material test By Caitlin, Tycho, Max, and Evan

    Task: Initial tests for new tread material

    The standard Tetrix treads and tread inserts aren't nearly as sturdy as we would like. When they snap it's a real effort to put back together stretched over the idlers, and the inserts peel apart, bringing our traction down. The new material is a rubber conveyor belt material from Andymark, and the underside track chain is 3D printed in nylon to mesh with the track drive gears. Outside: high strength high traction rubber Inside: 3D printed nylon to mesh with gears

    Reflections

    We first glue the nylon sections to the treads, laying them out flat so that some of the nylon hangs over one end and let them set overnight. The next day we bend it into a loop and glue the overlapping nylon and rubber together, and then let that set overnight. This isn't strong enough alone, so we ended up using the awl (used previously in Cascade Effect's game) to stitch at the boundary between two nylon strips, sort of like a thread staple.

    Initial tests showed that this design was a huge step up from the tetrix treads, and we're working to make another to complete the pair. One downside is that this design is a much thicker design, and rubs on the underside of other parts that weren't previously a problem.

    Mobile Learning Lab Part 1 - Demolition

    Mobile Learning Lab Part 1 - Demolition By Evan, Max, Tycho, and Austin

    Task: Redo the inside of the recreational vehicle

    Mr.Virani recently aquired an RV so it could be used as a mobile learning center for the Dallas City of Learning this summer. To convert it from someplace you might live on a long road trip to somewhere you could teach science and technology to children means stripping out carpeting, removing walls, and laying down easily cleanable floors and standing height work benches. We also have to put in a lot of computer equipment and 3D printers that Big Thought is providing. It's going to be a long proccess.

    Max and Tycho have completed a lot of demolition. They've removed the bed revealing a strange trap door that we need to look under. The table and chairs are gone as are some of the cabinets. The sofa was metal framed and too big to move out of the door or windows, so they had to cut it apart with bolt cutters and grinders. They ripped out most of the bathroom relying on the big sawzall. The mess of remaining plumbing and exposed electrical wiring looks very scary. And the pile of demoed materials has already grown quite a large:

    Mobile Learning Lab Part 2 - Roof

    Mobile Learning Lab Part 2 - Roof By Tycho, Max, Matthew, and Austin

    Task: Clean the roof of the RV

    We'd noticed that the roof was very grimey looking from the small strip you could see at the top of the side walls, but we hadn't been up there to look at it. Finally climbing the ladder we confirmed it. The roof is a very dark brown. We believe it is simply dirt that has caked into the sticky/gummy surface. It's probably not supposed to be so sticky - it kind of seems like a layer of decaying caulk laid over the rubber roof. We confirmed that this layer should be white. It covers the black EPDM rubber roof that serves as a weather barrier. Because the roof is so dark, it absorbs tons of sunlight, making it much hotter inside. We needed to clean it.

    So we spent today powerwashing the roof. In the morning Matthew (from SEM's FRC team) came over with his father's power washer and we got about 1/2 of the roof partially clean. When Matthew had to leave at noon, Mr. Virani purchased another more powerful washer and we continued washing until dark. Austin, from the other FTC team at our school joined us in the early afternoon. So now all three robotics teams at SEM have contributed time to the mobile learning lab.

    Here you can see the dramatic difference that powerwashing has made. We hope this will cool the vehicle enough that we can operate with only the roof airconditioners so we can turn off the main engine while on station.

    Mobile Learning Lab Part 3 - Flooring

    Mobile Learning Lab Part 3 - Flooring By Evan, Max, Tycho, Dylan, Ethan, Caitlin, Darshan, and Austin

    Carpet ripping is not fun. The carpet is tacked down with so many staples that is is not easy to remove. It tends to rip around the stables leaving nubs of fibers and then we have to attack the stables with pliers and staple pullers. Getting it out from under the edges of walls and the slide out is really hard. And we've gouged the subfloor where removing the old kitchen and bathroom vinyl required heavy work with scrapers. We tried putting down some vinyl planks, and those are much tougher to work with than you might guess. We only got a small portion of the floor demoed today. It's kind of daunting how much work this is. In the end it will be all worth it because we will have provided a place for children to learn skills that will help them in their future working lives.

    Mobile Learning Lab Part 4 - Update

    Mobile Learning Lab Part 4 - Update By Ethan, Max, Tycho, Caitlin, Jayesh, Darshan, Austin, Matthew, Evan, Dylan, Omar, and Trace

    Task: Covert a 1998 RV into the Dallas City of Learning Lab

    The RV exterior


    We have finished the majority of the renovation of the Dallas City of Learning Lab. We've finished rebuilding the roof, going throught the plumbing (including the suspiciously secretive water tank), and also replacing the entirety of the flooring.

    to

    The RV interior

    to

    A full tour of the RV pre-renovation can be found here.

    Changes

    • Removed restroom
    • Replaced carpet with laminate
    • Added widescreen TVs
    • Added black workbenches
    • Removed table
    • Removed cabinet to make room for more technology
    • Removed some 90s decor
    • Removed bedside tables and cabinets
    • Added 3D printer
    • Removed bed
    • Removed couch
    • Removed 90s decals
    • Added shelving
    • Cleaned a decade of muck off of it

    Reflections

    We've put in >250 hours working on this RV. It's going to become a mobile robotics lab so that we can inspire kids to enter STEM-related careers and hobbies. Uaing this van, the team can reach out to children who otherwise would not have the oppurtunity to learn how to build and program robots, as well as gaining skills related to that, such as using a 3D printer.

    Adding Blog Features

    Adding Blog Features By Ethan

    Task: Add Cool and New Blog Features

    I remember, vaguely, that someone on our team wanted to add a post counter for all the posts people appear in. And, today, I did it out of sheer boredom. And, here it is.

    {% assign eh = 1 %}
    {% assign dc = 1 %}
    {% assign ed = 1 %}
    {% assign or = 1 %}
    {% assign js = 1 %}
    {% assign cr = 1 %}
    {% assign dp = 1 %}
    {% assign mv = 1 %}
    {% assign tv = 1 %}
    {% assign jc = 1 %}
    {% assign inc = 1 %}
    {% for post in site.posts %}
      {% for name in post.rollcall %}
        {% if name == "Ethan" %}
          {% assign eh = eh | plus: 1 %}
        {% endif %}
        {% if name == "Dylan" %}
          {% assign dc = dc | plus: 1 %}
        {% endif %}
        {% if name == "Evan" %}
          {% assign ed = ed | plus: 1 %}
        {% endif %}
        {% if name == "Omar" %}
          {% assign or = or | plus: 1 %}
        {% endif %}
        {% if name == "Jayesh" %}
          {% assign js = js | plus: 1 %}
        {% endif %}
        {% if name == "Caitlin" %}
          {% assign cr = cr | plus: 1 %}     {% endif %}
        {% if name == "Darshan" %}
          {% assign dp = dp | plus: 1 %}
        {% endif %}
        {% if name == "Max" %}
          {% assign mv = mv | plus: 1 %}
        {% endif %}
        {% if name == "Tycho" %}
          {% assign tv = tv | plus: 1 %}
        {% endif %}
        {% if name == "Janavi" %}
          {% assign jc = jc | plus: 1 %}
        {% endif %}
      {% endfor %}
      {% assign inc = inc | plus: 1 %}
    {% endfor %}
    <ul>
      <li> Dylan Chorley - in {{dc}} posts</li>
      <li> Evan Daane - in {{ed}} posts</li>
      <li> Ethan Helfman - in {{eh}} posts</li>
      <li> Omar Ramirez - in {{or}} posts</li>
      <li> Caitlin Rogers - in {{cr}} posts</li>
      <li> Jayesh Sharma - in {{js}} posts</li>
      <li> Darshan Patel - in {{dp}} posts</li>
      <li> Maximillian Virani - in {{mv}} posts</li>
      <li> Tycho Virani - in {{tv}} posts</li>
      <li> Janavi Chadha - in {{jc}} posts</li>
    </ul>

    Now, this is not obviously the best code, there's probably a more efficient way than creating one variable per person. But, it works.
    We've been making improvements on the site since the season began - changing the theme, Caitlin's commits that updated the blog for the new season, and purging old member bios from the team, just like how Stalin purged political dissidents from pictures and sent them to gulags.

    Edit: We now have a Iron Reign stats page! We have spent a solid two hours debugging this so please appreciate it. We addded Austin, and cumulative personhours for team members and Iron Reign as a whole.

    Reflections

    We still need to work on the blog. At least for my computer, it takes a long time to load the actual site as it loads every single post made, so I'd like to add pagination. As well, I'd personally want to add a second theme for very easy readability, something like this.

    2016-2017 Robot

    2016-2017 Robot By Ethan, Omar, Jayesh, Evan, Tycho, and Max

    Task: To build the robot for the 2016-2017 season

    As much as we love our robot from last season, Geb, we need a robot that is better able to fit the season's challenges. Our needs for this year are:

    • Manuverable and fast
    • Able to play defensively
    • Can support attachments such as an intake system
    For manuverability, we decided to use mecanum wheels.

    The cool thing about these wheels is that they enable you to strafe side to side, instead of turning. However, they do require different coding than our normal wheels.


    To play defensively against other robots, our robot must be decently sized without falling into the same trap of last year, where are robot barely fit into the sizing limits, and in one tournament, did not at all. As well, it must be heavy enough to not be pushed out of the way by other robots, especially due to our strategy this year (blog post on that later).

    Finally, our robot must support attachments. Currently, we are considering a launcher, and intake system, a circulation system, and a yoga ball-lifter. And, to accommodate all of these attachments, our basic frame is a re-enforced square frame.

    Experimenting with a Mecanum wheel chassis! #ftcrobotics #omgrobots

    A photo posted by Iron Reign Robotics FTC (@team6832) on


    However, we are still experiencing problems, such as our chain falling off due to the supports moving toward each other. As well, we probably need to find a better place to put our motor controller and battery.

    Reflections

    We need to get our robot effectively finished within the next month if we are to go to the Arkansas tournament. As well, we need to add supports to our robot to stop the chain issue. Within the next two weeks, we should have made one or two attachments.

    Launching Mechanisms

    Launching Mechanisms By Ethan

    Task: To build a launching mechanism for the particles

    For the 2016-2017 season, particle scoring is really important. During autonomous, balls that are launched into the center vortex earn 15 points each, and balls that are launched into the center vortex earn 5 points. If done quickly enough, the particle scoring can negate most of the advantages another team has - just 8 particles scored during the driver-controlled period is equivalent to scoring all 4 beacons. With a good scoring mechanism, the only thing that your team must contend with is the other team scoring autonomous beacons and/or moving the cap ball off of the field.

    So, we must seriously consider all of our launching options. We narrowed our options down quickly:

    • Slingshot - Easy to make, but wouldn't hold up
    • Air launcher/Pneumatics - With our team, bad idea waiting to happen
    • Crossbow - Dangerous, but accurate.
    • Flywheel launcher - Accurate, requires least maintenance, but huge battery load
    • Catapult - Less accurate, but simple and powerful
    Of these options, we narrowed it down to the Flywheel and Catapult

    Flywheel

    Above is an example of a fully functional flywheel. The pros of that design are that it is efficient, accurate, and requires little upkeep. On the other hand, it needs at least 2 motors unless someone is willing to do gear witchcraft. As well, two extra motors will drain the battery (bigly), as we learned from last year's mountain climber. Finally, it can take up quite a bit of space on the robot and weigh it down a lot.
    Also, my initial model of it did not function well.

    Catapult

    We had trouble deciding on a catapult design. Initially, we were considering a more complicated flipper design, but after seeing our sister team's struggle with their design, we decided on a simpler, bungee cord design. The pros of this design are accuracy, simplicity, and strength, but the cons are that it isn't *as* accurate and that the elastic band will need to be replaced.

    The coolest thing about this design is that it can be simulated before I change anything, using a catapult simulator. A sample of our catapult can be found here.

    Reflections

    This add-on is the first of many that we must make to prepare for competition. Next, on the build list, we need to create a capping attachment and intake system. In the future, we should probably speed up our development process if we are to head to the Arkansas regional tournament.

    Stabilizing Our Driving Base

    Stabilizing Our Driving Base By Jayesh, Omar, Max, and Darshan

    Task: Stablize Meccanum wheel base so the driving is more stable and consistent

    Our Meccanum wheel base idea started off on a shaky note. While we had a good amount of success in the tass we wanted to complete, like driving right or let without turning the entire robot, including the basic driving functions. However, as we went on with testing, we found that over time, the force the meccanum wheels were exerting on the chain was actually causing the motors driving the chains to come inwards. This was thereby loosening the chain and weakening their effect on the driving chassis. To fix this, we decided to mount angled beams between the motor and Meccanum wheels to stabilize and prevent the motion. We then further strengthened the system by 3D printing trapezoid-shaped mounts that have more surface area and strength to stabilize the system.

    Reflections

    As we go on improving the robot, we keep finding that our new designs have an incredible amount of errors and small bugs that need to be looked at before moving on to the next big design. Now that we have a stable and relatively reliable driving base, we can now focus our attentions to the scoring mechanism. Through our redesigns of the motor stabalizers we have found the use of testing on both the ground and in stationary conditions. We need to design a new mount to make stationary testing more efficient. This will especially be important for the testing we'll have to commit to for our scoring mechanism. (which will be discussed in a future post)

    Launching Mechanisms Pt. 2

    Launching Mechanisms Pt. 2 By Ethan

    Task: To improve upon launching mechanism designs

    Catapult

    First and foremost, we now have one completely functional, terrifying, catapult. The motor mechanism is cannibalized from our sister team's attempt at a catapult, which broke apart on testing.


    Flywheel
    So, while we don't have a functional flywheel as of yet, we have done the math in order to get it up and working on the first try.

    For reference, we need to launch the ball ~1 meter, the frequency of the motor is 2.53 s^-1, and the radius of our gear is 2.65cm.
    velocityfinal^2 = velocityinitial^2 + 2*acceleration*change in y
    velocityfinal = sqrt(2*9.8m/s^2*1m)
    velocityfinal = sqrt(19.6m^2/s^2)
    velocityfinal = 4.427 m/s

    actual final velocity = 4.427 * 1.25 = 5.534m/s
    actual final velocity = 2*pi*radius*frequency
    (5.534m/s)/(2*pi*2.53s^-1) = .348m

    gear ratio = gear1radius/gear2radius = 2.65/.348 = 1:7.615
    However, for simplicity, our needed gear ratio is 1:8.

    Reflections

    We should advance in building our attachments - if we go to Arkansas, we have <6 practices to go. And, from now on, we need to do the math behind them so we know we're doing them right.

    Parasyte

    Parasyte By Jayesh, Omar, Darshan, Caitlin, and Max

    Task: Design a collector for the balls

    We've spent the last few practies creating a ball collector. The idea was to have our track with the gripping rubber bands reach from the bottom of the robot to our 3D designed ramp. The path would guide the balls to a higher position on our robot to the launching mechanism. We needed to adjust the correct orientation of the support beams guiding the balls, needing to drill new holes and adjust beam lengths.

    Reflections

    There have been a lot of adjustments we have had to made to the this tread-based system. Starting from an eyeball test of the length, we had to eventuall lengthen the whole tread to fit the whole system. With our length being about finalized, and our entire path about done, We are about ready to attach our launching mechanism and start adjusting the scoring mechanism.

    Intake System Improvements

    Intake System Improvements By Caitlin and Janavi

    Task: Replace rubber bands with smaller versions and add wider intake area

    New intake area is wider than before


    At the Scrimmage we noticed that the rubber bands would get tangled as they rubbed against the underside of the catapult bowl, and so didn't reach as far down at the bottom. We untangled them before each match but decided to test out the smaller ones when we had the chance at practice. We were planning on adding a wider area for intake with some circles of treads and rubber bands, but with the long rubber bands they just got completely tangled in each other. So this practice we replaced the long rubber bands with the shorter versions and looked at differences

    Reflections

    It took a little while to physically pull out and replace each band, but the rubber bands we use are stiff enough that they can be pulled thin enough to slip in without getting twisted up. The single conveyor with the smaller rubber bands wasn't any noticeably worse than the same conveyor with longer ones, and our load rate stayed pretty much the same. We then added the smaller side brushes/spinners on that axle. Originally the longer rubber bands tangled up and threatened to break the belt, but this made it easier for Tycho and Omar to score. The added wheels on the axle make the intake area almost as large as the robot, stretching from wheel to wheel.

    Beginning the build for the Cap Ball Trapper

    Beginning the build for the Cap Ball Trapper By Jayesh and Omar

    Task: Give Deadshot flexibility in end game scoring by designing Cap ball launcher

    One of the issues we saw in Arkansas was in the lack of flexibility we had in terms of the end game. We efficiently scored balls and beacons, but when our teammate for a specific match could do the same, we lost possible points scored. This led us to conclude that a Cap Ball Trapper, would be necessary for the sole purpose of flexibility. We focused on an extrusion-based system, based on a set from AndyMark. We've rigged up a pair of basic stairway systems, which will form the main lifting mechanism for the Cap Balls, now we have to figure out where to place them.

    We followed the Youtube video above to figure out how everything was put together initially, and then expanded from there.

    Reflections

    The idea of flexibility is a luxury we can consider due to the progress made for the Arkansas competition. The idea is in scoring the maximum amount of points, regardless of the capabilities of our respective partners. The rigs themselves (although they do need some end covers so they don't fall apart) work fine, but we need to figure how it's going to fit into the general scheme of our robot. We have concluded that the rig will require two motors (we're at our limit; hooray traditions). The main goal in finishing this system is in figuring out both its deployment and placement.

    Return to Machine Vision

    Return to Machine Vision By Tycho

    Task: Prepare to reintegrate machine vision

    A year and a half ago while the new Android-based platform was still in pre-launch, we were the first team to share a machine vision testbed on the FTC Forums. That color-blog tracker was implemented with OpenCV on Android, but with a different low-level control system and robotics framework. Then we integrated OpenCV into our implementation of ftc_app, which was in turn based on the great work of rgatkinson's team supporting Swerve Robotics. Our main game repo for FIRST RESQ was also open sourced and we gained a lot of experience using it. But we had many issues that prevented full usage of the capability. There were problems with the whole control system that created extremely variable loop times which really challenged our custom PID implementation. On top of that, we found that in many tournaments the beacons were not working, or the lighting was too bright and our camera was being flooded by the white shell of the beacons. That made it an unreliable solution.

    So this year we switched to the modern robotics color sensor as a slightly more reliable method of detecting the current color while up close. This also gave us the ability to add color sensors to both sides of the robot so we no longer have to turn around when on the blue alliance. And we found we had good-enough navigation based on calibrated odometry so that we could get into position without color tracking.

    But now we need to go ahead and try to re-integrate our previous machine vision code and see if we can improve on the situation. We also need to at least try out the Vuforia object tracking capabilities, even though we've set that as a lower priority because we know that specular reflections are likely to be a problem under varying lighting conditions at different competition spaces. We've noticed this problem at a couple of spaces due to the marker placement behind the planar polycarb of the border walls. So we don't actually plan to rely on this as a primary means of navigation and positioning, but we should try it out and see how robust it might be.

    We still want to use machine vision to possibly track beacons and particles. We are hoping to track particles to create an autonomous behavior that triggers during teleop so that a particle near the front of our particle collector can be automatically approached and pulled in without operator intervention. This should help since picking up particles on the far side of the robot from the drivers is very difficult because of blocked sight lines. We want to use color tracking to make sure we don't pick up opposing alliance particles.

    Research / References

    I checked out Vuforia and there is no ability to track based on color. So we need to use OpenCV again, but when Vuforia is present it also locks up access to the camera. Fortunately there is now a way to get a frame from Vuforia and reformat the image data for OpenCV's use.

    I plan another post to document the actual steps we went through. Stay tuned. If Vuforia proves troublesome, we might revert to getting our image from a camera preview just like last year. Though that would mean messing around with the Android manifest and the layouts in the main FtcRobotController folder.

    Building the Fly Wheel Launcher

    Building the Fly Wheel Launcher By Jayesh, Omar, Darshan, Evan, Tycho, and Max

    Task: Create a particle launcher with a higher scoring rate

    The first particle launcher we saw by another FTC team was actually a crude flywheel and rail design back in October where the rail was a cut up PVC elbow. Back then we considered a number of different designs including impact launchers, catapults, flywheel + rail systems and dual flywheel shooters like our sister team built. We decided to go with a catapult design because Max had experience with catapults and knew that they could create very repeatable trajectories.

    Our catapult has achieved those reliable trajectories. We operated it with a choo-choo mechanism that allowed us to fire and re-cock without having to change direction, so that made reloading easier and faster that it might otherwise be. It accurately scored, with consistent ballistic trajectories, however, the system had problems with ball loading when our 3D printed catapult bowl kept failing due to layer separation. As a result we had a lot of misfires and had to replace our bowl often. So our moderate cycle rate and our misfires meant we actually scored only about 4 balls during our average teleop phase. As the season progressed it became increasingly clear that we would have to radically improve our center vortex game and that was driven home when Technical Difficulties and Technibots crushed us with their world record score in the finals match at our first qualfier.

    So we decided to move on to a flywheel-based design, knowing that we would likely be sacrificing some accuracy for a much greater cycle rate. We knew that dual flywheels tended to have even greater issues with accuracy due to their extremely short contact period and the chance that one or both wheels would hit a slot in the wiffle ball. We saw direct proof of this as our sister team, Imperial Robotics, struggled to get their dual-flywheel design to work consistently. And Ethan had attempted to build one very early in the season, but never really go it working. So we decided to design with a single wheel with a semicircular ball guide or rail. Max created a custom 3D design for both the flywheel and for the rails. The rails were printed in nylon, our preferred structural plastic. He printed three different flywheels for testing. One was in nylon meant to be covered with foam for compliance. The other two were printed in Ninjaflex (urethane) at different infill densities. The foam on the nylon version shredded at the RPMs we were using. We probably could have found a better adhesion solution, but found that the low-density Ninjaflex version worked beautifully and has stood up to extensive testing.

    Reflections

    The continuous improvement of designs is a constant focus we adhere to. Previously we'd gone through two major revisions of our catapult system, with a whole bunch of minor modifications, and that system got us qualified for the North Texas Regionals. We saw the pros and cons, and eventually saw fit to change the system to score more points in the long run. We are now able to score around 75% of the balls we shoot. The key is in how quickly we shoot now. Before we would have to collect balls, turn the robot around, load a singular ball into the scoop, and shoot. Now, we can shoot 4-5 balls right after another without turning around. This will allow us a much greater center vortex scoring rate as we aim to be one of the top teams at Regionals.

    Inspire Award

    Inspire Award By Tycho, Jayesh, Caitlin, Omar, Max, Darshan, Evan, Ethan, Janavi, and Charlotte

    1st Place at North Texas Regional Championship

    Iron Reign members left to right are Ethan Helfman (Build, Communications), Janavi Chada (Programming, Communications), Tycho Virani (Programming Lead, Main Driver), Jayesh Sharma (Business Lead, Build, Communications), Darshan Patel (Build), Caitlin Rogers (Communications Lead, Logistics, Business) and Charlotte Leakey (Programming, Logistics), with Evan Daane (from BTW, Build, Photography) in repose. Not shown: Max Virani (Design Lead, Programming), Omar Ramirez (Build Lead) and Rohit Shankar (Programming).

    Wow, we did it. I mean, we were going for it, but wow - we did it! Out of 118 teams competing in our region, we got 1st Place Inspire (Top Award) at our regional championship! We finally earned the coveted Inspire Banner. We've been building toward this for 7 years! Ever since we started as an FLL team.

    Our total awards included Inspire 1st, Finalist Alliance 2nd, Motivate 2nd, Connect 3rd, Innovate 3rd.

    Not going to Disney World yet

    We are now qualified for the Texas State UIL Robotics Championship and the 12 State South Super Regionals. And we are preparing with the goal of making it to the World Championship. We have an extended season and while some of us have been to super regionals before, this is the first time the whole team gets to go. Our coffers are empty, we need a whole new round of fundraising to keep up the progress for the extended season. We need your help! Please consider contributing to support our extended season and help us represent North Texas at Supers.

    In case you don't know how the game works, it's broken into a 30 second autonomous phase followed by a 2 minute driver controlled period. Two alliances of two robots each compete in each match. Here is our division winning match with alliance mates Technibots. Autonomous:

    And Tele-Op:

    Editing the Reveal Video

    Editing the Reveal Video By Evan and Omar

    One man's harrowing journey through copyright free music lists

    The Robot Reveal video is underway. With most of the filming done, the sky grows dark and the day ends. A night time of editing sets in for the poor miscreant who volunteered for the task. Huddled in the corner with a raw fish and his precious computer, the boy opens premiere pro to begin. All is right with the world. The five hour long dramatic saga of trying to figure out the dang code to his Adobe account is through and the password has been changed. He knew he never should have let his family use his student status for a discount. But it's over and he's decided to leave it in his past. Time to edit...

    So the editing for the Robot Reveal video has begun and so far it's gone fine. I had an easy time getting it all in and except one crash(everything was recovered) it's been good. There won't be too much extreme editing to do. Nothing mind bending. Mostly cutting and arranging. The big problem now is finding a song to use that fits the video. I'm having trouble finding something pleasant sounding, fitting, un-copyrighted, and that lines up with the length of the video. I've been listening to a ridiculous amount of un-copyrighted music. An insane amount. It's not copyrighted for a reason. No man or woman or animal or object should have to endure this. The un-copyrighted playlists should be used as an enhanced interrogation technique and then banned by the UN for being a violation of basic human rights. Its all a bunch of extremely similar songs that should either be in the background of a shirtless guys vlog or the basis for an art students performance piece. A few outliers are some EDM and elevator music and I don't know which one makes me want to pour hot wax into my ear holes more. I'm listening to a song right as I'm writing this. I think it's the background music for the most generic cooking channel on YouTube ever. One way or another I'm going to get this done. Maybe I've made a few hyperboles throughout the post but the robot reveal will be finished. I've saved all the music I think could work into a playlist that I'll let everyone give a listen to at tomorrow's meeting. Now I must return to my hell.

    REV Robot Reveal

    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: