Day 40 (2/14/18)

Authors – Ritik Mishra, Grant Silewski

Introduction

We got a lot of work done on both robots this weekend! We added limit switches to our practice robot, hooked up some more encoders, and fixed small issues all around that needed to be addressed. We also made considerable progress on our competition robot, and there is still plenty more to do with that!

Image uploaded from iOS (4).jpg

Ideas for weight savings

 

What still needs to get done on the practice robot is to finish up adding sensors to the active/elevator, and finish putting on the butterfly.

Image uploaded from iOS (3).jpg

Students working on the final robot drive train

 

What still needs to get done on the competition robot is grinding the elevator so it fits, adding the butterfly, pulleys on the bottom of the elevator with the polycarbonate guide, weight saving techniques, carriage brake, mounting the climber gearbox, and all of the electronics/energy chain.

Image uploaded from iOS.jpg

Pulleys under the Elevator

Carriage Brake

After some development, we found a way to brake our carriage into our second stage for when we climbing. It pretty much just uses the active intake cylinders, as they essentially have three positions. We have yet to test this, but through moving it with our hands, it seems to be a lightweight solution for a necessary subsystem.

Active Intake

We tested our active intake and it seemed to work surprisingly well in all orientations. We had to replace the belt on the rotation to just #25 chain, as it was slipping too much, and we switched out the cylinders on the active to two position instead of single actuated. We also added hard stops and limit switches for safety and ease of use.

Image uploaded from iOS (2).jpg

Ritik and Poorva working on the active

Subsystem Discussions

The robot is currently having issues with different commands interrupting each other. This is a side effect of the way that WPILib structures Subsystems and Commands. In WPILIB, a Subsystem is a group of motors, pneumatics, and other contraptions, while a Command is an action that can require 0 or more Subsystems. If a Command requires a Subsystem, it halts all other Commands that also require that Subsystem. This is a good idea for robot safety, but requiring Subsystems can have unintended effects on the robot.

 

For example, the Command that toggles whether the active is grabbing a block or not requires the Active Intake Subsystem. So does the Command that spins the active in, allowing it to eat cubes. As a result, if Driver 2 grabs the block while spinning in the active, WPILib will halt the spinning-in Command for the 20 ms that the grabbing Command runs (WPILib operates on a 20 ms loop).

However, the grabbing Command should ideally require the Active Intake Subsystem. Not doing checks that prevent unintended behavior can result in — you guessed it — unintended behavior.

 

The programmers have come up with several ways to deal with it

 

  • Don’t require subsystems when necessary
    • This idea has been largely scrapped for the reason mentioned above
  • Put all the solenoids in one big subsystem
    • This makes no sense from a build standpoint, as solenoids from unrelated parts of the robot will be grouped together.
    • Additionally, this will prevent multiple solenoids from being activated simultaneously (e.g climber and butterfly)
  • Put all the solenoids in their own subsystems
    • This has the side effect of creating lots of extra files and making the codebase less maintainable
  • Nucleate the subsystems
    • This involves creating Subsystems inside Subsystems. This is quite similar to the idea above, but will also occur for motors as well. However, this will drastically increase the size of the codebase and also risks decreasing maintainability.

 

Power Chain

Today, the power chain on the practice robot was reworked for the “second to last time,” as a mentor put it. Rather than curving at the top and being straight at the bottom, the power chain has been turned sideways and curves at the bottom, making the front of the robot look like the letter J. As a result, someone suggested that we name the robot Jerome (since J is for Jerome), but another stated that Jerome was a ‘dumb name’. A third onlooker foolishly pointed out that the front of the robot looked like an H, so it should be named Hershel.

Image uploaded from iOS (1)

Safety

 

Quote of the Day

“Robots should not quit, but yours did” — WPILib insulting Hershel

Advertisements

Day 31 (2/5/2018)

Authors – Grant Silewski, Ritik Mishra

Introduction

We have almost finished the practice robot! This weekend we pretty much worked on everything and got it to work. We even got our robot to drive around! More specifically, we adding chain to the drivetrain, finished putting together the butterfly, added the rotation motor to the active, finished making the carriage, finished the elevator and added most of the pulleys, and added the elevator drum/climber shaft with all of the corresponding motors to it. The only things we have left are to finish hooking up all of the motors, make a release latch on the butterfly, and replace the 3D printed parts with the steel ones that we are getting today. We are also getting Kevlar rope today, which we will be adding to the elevator so that it can run.

 

We will hopefully be getting all of the parts to finish both robots by the middle of the week! Thanks Eric! We now have rivets so we can put together all of our competition robot parts when we get them.

Image uploaded from iOS (2)

We weighed our practice robot, and it currently weighs 120.6 pounds, which is really good for this point in the year. We have it to be projected to 125 after we finish adding everything. Yes, it is over the 120 weight limit, but compared to previous years, last year in particular, we are normally at 130. There are a lot of ways to take off weight, such as drilling holes in spots of the butterfly, drilling holes in the currently solid and giant ¼” plate, and swiss cheesing a lot of the polycarbonate. We can even drill holes in the c-channel, which will save a lot of weight. We also have a few backup plans. The butterfly can revert back to 1/16 inch tubing, like how it was on the prototype. We can also take off a cim somewhere. We have lots of options. However, we should work on getting the robot finished first and make sure that it works before we start to worry about weight.

Image uploaded from iOS (3).jpg

The electronics board look beautiful, which will hopefully lead to a clean looking robot. Michael also fixed our battery charger by making new leads/wires. Yay!

Image uploaded from iOS (4).jpg

 

Elevator Assembly

We finally added this to the main robot, and it all fits together and works nicely. We initially had some issues with the bearings running into the supports, but we fixed that and now it works like how it is supposed to. However, we did put on the 3D printed parts temporarily, which we will have to switch. We also added the shaft that drives everything, which was a pain because it had to be taken apart multiple times. We also added all of the pulleys/PVC sleeves for the part that pulls down on the elevator. We still need to add two pulleys to make the upwards part of the elevator function. After that is done, we will string it, and it should be ready to go.

 

Active Intake

We did not do too much for this system this weekend, other than mount it to the carriage. It currently works exactly how it did on the practice robot, which is a good sign. The only part that might be different is the cylinder on the active, or more specifically the gate hinge. There seems to be a lot more movement than compared to the previous active, so there is a good chance it might not have enough force to hold the blocks. This is very easy to fix, however. The prototype was so strong, we needed to put the cylinders on the lowest working pressure in order for it to work/not hold the block too much. We will do further testing on it after we have finished the robot, because that is currently our first priority. Our other priority is hooking these systems up to the electronics board, which will hopefully be done soon.

Quote of the Day

“uhhh” — Barack Obama

Day 28 (2/2/2018)

Authors – Andrew Gazelka, Ritik Mishra, Grant Silewski

Introduction

After a few weeks, we finally got most of the parts back from CEM, or rather enough for us to almost completely finish a practice robot, and make many of the subsystems for the competition robot. CEM is an amazing sponsor, and even though they are really far behind on all of their orders, they still put us at a high priority and got us parts as fast as possible even though this was the most parts that needed to be machined by the team, and even though we scratched their door (sorry Eric!). Huge shoutout to Eric, Greg, Tim, Steve, and Steve. Thanks for making this season possible! We assembled our frame, mounted the elevator uprights, and got it welded by Tim. We decided to go back to the frame/welding style we used back in 2016, where we riveted plates onto the joints, and then just welded the plates onto the frame. We did this because last year when we decided to fully weld the frame, it came back very warped, and it was a pain to do/make it happen. This year it was a breeze, Tim (hopefully) had a fun time welding, and the frame was not warped whatsoever. The frame is amazing! This method is by far a lot better than what was employed last year. We also welded together the second stage of the elevator, because that will be bearing tons of weight when we climb. This was done very well, and in Tim’s words, “It ain’t going anywhere.”

robit

In addition, CEM invited our team to come and watch Steve run our parts through the CNC mill. It was really fun, as we watched our parts get drilled, and we got to talk with Steve about machining and whatnot. It was a great opportunity, and Eric even invited us again so that more rookies could go next time. We are grateful for the offer.

Another side note includes frustration with Fastenal and rivets. Long story short, we are running out of these rivets, but we will have enough for the time being. We will be getting an order of 500 on Monday, which will be plenty for assembling the competition robot.

After finally being able to use our parts we machined, we realized that the parts with the retaining ring in them were amazing. They shafts were so easily assembled, everything fell into place, and we do not have to deal with those stupid shaft collars or taping the end and putting a screw in them, for most of the parts. For example, we do not have to deal with putting something like a shaft collar on inside of the frame for the drivetrain: now it is just a retaining ring. This is definitely something we should pursue more in the future.

Our new goals for this weekend include completing the practice robot (what we can do at least), finishing the practice robot electrical, and finishing all of the competition subsystem parts that we have in our possession. We hope to get everything welded for the competition robot before next weekend (preferably Thursday), so that we can finish our competition robot before the driver’s test. During next week, we hope to be incorporating sensors, such as limit switches and proximity sensors, and a carriage brake into the practice robot so that we can move it into the competition robot.

Image uploaded from iOS (1)

Drive Train

After receiving the welded frame from CEM, we went to work on adding the wheels and the gearboxes for the drive train. After successfully putting on four wheels, we confirmed that the frame was not warped, as every wheel was touching the ground at all times. We were incredibly happy about this, especially since this was an issue last year for us. We then continued to mount the gearboxes, and after a lot of spacer placement skills, we successfully put on all of the wheels on our drivetrain. Since we decided to do our sprockets differently this year, we had absolutely no issue with the two gearboxes hitting each other when trying to put both of them in, contrary to the issues we had back in 2016 and 2017. These are a lot easier to modify/fix if need be. We also had some rookies add the churro supports in between the frame for making sure the frame does not destroy itself when triple climbing. After drilling too many extra holes and sanding down one churro, this job was finished. Our goals for tomorrow include putting on the sprockets, and connecting every wheel to its corresponding gearbox with chain.

Elevator Assembly

After getting the second stage welded, we set out to finish putting together the carriage that goes inside of the u-channel. We also learned about tolerancing again today and what happens when you do not build them into your parts. Yay! We got this finished today, but we had a few issues with putting it into the second stage, and a ton of binding issues. A mistake we made was almost fully assembling the carriage outside of the second stage. Since the second stage is welded, we cannot take the top off to insert the second stage, like in the prototype. We fixed this by taking out the rivets and assembling the carriage inside of the second stage. We also had to shave down the bars connecting the two halves of the carriage, because they were slightly too big for the second stage (yay tolerances). After this, we noticed that the carriage would bind and get stuck a lot, and also make a wretched sound as it traveled. We fixed this by adding white lithium grease to the outside of the bearings, and inside of the u-channel and the sides of the carriage. This helped a ton, and now it slides like a car down an icy hill. Hopefully we will be able to finish assembling/attaching this to the practice robot (using the 3D printed bearing blocks temporarily until we get the steel ones from CEM) before tomorrow ends (Grant wants to go home early on Sunday). We will also plan on making considerable progress on the drum tomorrow/Sunday.

Active Intake

Since our usage of belts and retaining rings, this one bar far the easiest part of the robot to assemble. We even got our competition ones built! The belts are incredibly light, easy to use, not as messy, and incredibly convenient. This is also something we should pursue more in future seasons. We also added this subsystem onto our carriage today, and it went on smoothly due to the retaining rings. These rings also allowed us to quickly adjust the active/take it on and back off again as we put the active on wrong around 4 times. Each bar has a ½” slotted hole, so it can rotate around the hex shaft. It uses a 10-32 bolt as a pivot, which will eventually be controlled by a pneumatic, like on our prototype. Our goals for this weekend will be to add the pneumatic cylinders to the active, and create hard stops so the motor leads do not kill themselves.

Butterfly

We started assembly on the butterfly for the practice robot. Our progress for this is shown below. We will be making a set of wings for the practice robot, but not actually using them until we get them welded by Tim; otherwise, we risk breaking them. Our plan for tomorrow is to finish assembling the wings, make sure they fit on the frame, and get them ready to be welded for next week.

Image uploaded from iOS

Programming

Quite a few interesting events have occurred since last blog. This includes us creating a legitimately working implementation of Pure Pursuit. Here are videos demonstrating the progression of Pure Pursuit.

One of our first semi-successful tests (with voltages)

Two tests at 3 ft/s and 6 ft/s (with PIDF)

Pure Pursuit works by maintaining left and right wheel velocity ratios. Each ratio will create a specific arc. A set voltage ratio does not necessarily mean the velocity ratio will be the same. It is clear from the video that PIDF is much smoother.

Pure Pursuit Tuning

After wheels go the required velocity, there are many possible steps to tune Pure Pursuit. This includes many options, including:

  1. Scaling the lookahead distance based on latitudinal velocity of the robot with respect to the path
    1. This should fix oscillations at high speed when the robot is on a path
  2. Dynamic speed based on curvature (might have a second instance of Pure Pursuit running to look further ahead to when speed should slow down)
    1. Makes it so robot can maintain precision on curves by slowing down
  3. Dynamic lookahead distance based on curvature
    1. Should avoid slipping on harsh turns by making turns less harsh

Potentially, these can be combined.

Encoder Installation

The encoders on the drivetrain are the most essential sensor on the robot, closely followed by the NavX. By using encoders on the drivetrain, the programmers know precisely how far the robot has moved. This allows the programmers to fix bad build quality with good code quality, as seen with Voyager. Voyager suffered from a disease called Warped Frame Syndrome, which is often caused by too much heat being applied during the welding process. This meant that when equal voltage was applied to both sides of the robot, the robot would veer off in one direction. However, the problem was solved by using encoders to verify that both sides of the robot had travelled the same distance. As a result, the robot would correct itself once it had started to veer away from being straight.

This year, we are moving away from the expensive, cumbersome Grayhill encoders towards the cheaper, smaller, officially supported CTRE Mag encoders. Additionally, rather than putting the encoder on the wheel, we are putting it on an alternate output of the gearbox. Grant, Ritik, Aaron F, Isaac AJ, and Nathan all put work towards the process of installing the encoders. First, they had to find the optimal thickness for the 3D printed spacers designed by Grant. Through trial, error, and lots of sanding, they discovered that the optimal thickness was 0.23”. Then, the team had to use the hacksaw, belt sander, and a piece of sandpaper to thin the 0.375” encoder mounts to 0.23”. Finally, Ritik got to screw everything in place. Over the course of 2 days, this process was completed for both the practice robot and the competition robot.

Quote of the Day

“Please clap” — Jeb Bush

robitwithWings

 

Day 11 (1/16/2018)

Introduction

The team voted on prototypes today. The engineering leads will discuss this decision later this week. That decision will most likely be on Thursday.

 

The team decided on the following:

For the active intake, we wanted an elevator integrated active intake. For lifting, we decided that we should go with the linear slide elevator. For climbing, we would want to integrate it into our elevator, and we would also want to persue Project Butterfly.

In the next few days we will finish CAD models for prototypes that were chosen. The team hopes to send those out to Eric as soon as possible to get them machined. There will be a scouting meeting on Thursday this week for anyone who wants to attend. Additionally, robotics build time hours changed and Wednesdays will only be 6pm to 9pm until there is an email. Remember to check the remind and facebook for changes in room time.

 

Various Programming and CAD

Ritik worked on ShuffleBoard implementations and added a force downshift button. In particular, he and Isaac AJ made the crucial discovery of the Sendable interface. This interface allows things to be sent to the Shuffleboard with more detail; in particular, using the Sendable interface allows you to use the more complicated widgets like the DifferentialDrivebase and Gyro widgets, both of which are very informational. Additionally, all of the develop branch is now merged with master (including Pure Pursuit), and more accurate formulas for Pure Pursuit are currently being worked on.

Day 10 (1/15/2018)

Introduction

Today a lot of finishing up prototypes was done. On Tuesday at the team meeting we will vote on the best prototypes, so all prototypes have to be done before the meeting if you want them to be considered. After the prototypes are voted for, then we will start to make them out of the final materials. Also there may be modifications that have to be done to those designs before the final version is made.

Active Intake Forklift Integration

Due to us wanting to include Project Butterfly into our final robot, we are now starting to push weight. We can no longer have a separate system for the active intake and the forklift. The active intake we prototyped earlier was way to wide, heavy, and complex to fit onto the forklift. On top of other limitations such as not holding the block very well, it cannot handle sideways blocks whatsoever. After further game analysis, we concluded that picking up sideways containers is something we will want to be able to do, especially since it could affect the outcome of the match, or travel distance to get the next tote. In addition, nobody has even started prototyping something like this to fit on a forklift. Due to these limitations, we have decided to try and make a lighter active intake that is completely integrated into our forklift. This will save us the weight of an entire new system, pneumatic cylinders and components, and give us the opportunity to pick up sideways bins. If it works as plan, we will be given the option of dropping or shooting the block out of the forklift for scoring. We will hopefully be finishing this prototype before the meeting today.

Drive Train

The modifications to the spacers and shafts were finished today. This allowed for the gearbox assembly to be started. The gearboxes are mostly finished except the team is missing some pneumatic fittings and some bolts to attach the gearboxes.

Day 9 (1/14/2018)

Project Butterfly

We were successful in making one wing for Project Butterfly. The wing was able to hold students weighing about 150 pounds, and our old robot, disc-o, with Titanium on top of it (Probably about 170 lbs). After upgrading the brackets into quarter inch plate, we no longer saw any type of bending at that area. Instead, we found out that the biggest weak point was the frame. After putting weight on the wing, we noticed that the drivetrain frame would want to contort around its attachment point by about 10 degrees. We figured that this will be a huge issue if we did not brace it, and also probably the reason why most teams will not attempt something like this. However, this frame we used was in really bad shape, and it did not have any supports for it whatsoever. After brainstorming and some CAD, we figured that adding braces for bars would add about 5 pounds. We weighed our wing prototype at the end and it was 4.7 lbs.

Image uploaded from iOS

We also started looking at a gearbox that could rest within our elevator shaft, but could engage only for climbing. In order to accomplish this, we took our two speed dog shifter gearbox from last year, took out the high gear, added a ratchet, and there we had what we sent out to get. It might not be the easiest to mount, but for the same weight as a Toughbox Micro, it’ll do just what we need.

image_uploaded_from_ios_720

Pure Pursuit

Finally, the last (big) hardware issue (not including navX) was fixed. Unknowingly, all the Talon IDs had been scambelled after the roboRIO had restarted. The encoders were both on the left drivetrain motors, which = bad since they were were actually on two different sides. After Isaac Ash and Andrew fixed this issue, the robot had completely working encoders. After briefly fixing some code oddities, we successfully drove the robot 3 feet forward — exactly as planned. As we walked to the commons, we were sure everything was going to go great. As we selected our 3 waypoints and pressed the ENABLE button we held our breath. As the robot slowly moved on 25% V allocated to motors, we noted it was going in the precise direction we wanted. It made it to its first waypoint… and didn’t stop. Looking in the code, we inspected the algorithm behind estimating the location of the robot. To our dismay, the robot had an inaccurate encoder-calculated header when testing in teleop. Even though the robot had a nearly perfect reading when going extremely slow, it failed on fast rotations. This is when we remembered the kinematic equations we had implemented are for two wheeled robots — not a 4 wheel skid-steer robot. According to Andrew, the equations for tank drive look “interesting,” as one paper describes “a general theory to accurately define [ this formula ] does not exist.” Time to try to implement this.

navF: S.O.S

Creating a Wormhole

Looking at several papers on Entangled Wormholes through Quantum Gravity, we set out to design our own wormhole to instantly teleport the robot and all needed power cubes directly to their desired location. This was seen as a large challenge to Team 2502. That is, until we remembered that anything is possible through gracious professionalism. Collaborating with other teams, we decided on one simple way to teleport the robot: navX — the integral tool that has continuously paved the path for those on the bleeding edge of quantum mechanical research. We then devised our plan: spinning the robot. Through a quick spin for 1 second, the navX proved our hypothesis. The robot had in fact teleported 40 meters to its desired location.

Mastering Driving on Two Wheels

At Team 2502, we always strive go further and harder; we are the ones who choose to go the extra step. Recently, navX has given us new interesting information regarding our latest achievement — driving our robot solely on two wheels. As we are envious of others who flaunt their expert driving skills, navX has fortunately informed us that our robot always has a pitch of 30 degrees. This proves that we drive cooler than any other team, including Team 254, Team 1114, and Team 2056, to name a few. Team 330 was slightly cooler than our robot during the 2016 Einstein finals, when their robot capsized and had a pitch near 180 degrees; however, their drive team was too uncomfortable and ended up righting their robot back to zero pitch.

Drive Train

Today, the final element of the drivetrain was completely CADded: the gearboxes. Originally, they were just pulled straight from the Vex website; however, we will be making a crucial change to our gearbox. Specifically, we will be putting a double-hub 12-tooth sprocket inside it. This way, we can attach chain to it, rather than sandwiching the sprocket between the gearbox and frame. We were not very found of the West Coast Drive variation for these gearboxes, as clearly they were designed for #25 pitch chain, and the tolerance between the gearbox and the chain for #35 pitch was incredibly small, and super sketchy. We went out on changing the gearbox by literally increasing the width by about a tenth of an inch or so, which means we have to remake new spacers and ⅜ in shafts. A few team members started making some of the parts to modify the gearbox for this. The team finished most of the spacers and shafts. We also modified the shafts so that they could fit the magnet for our SRX MAG encoder. The plan is to finish these items tomorrow and assemble the gearboxes.

Image uploaded from iOS (1)

As a side note, here is our most recent CAD model

asdf.PNG

Day 8 (1/13/2018)

Project Butterfly

After being inspired by team 1717 from 2007, and also from looking at a RI3D team, we started work on what we call project “Butterfly”. It’s the idea that we will be able to carry two robots with us on the way up for when we climb. We built our first Proof of Concept today, and we found out that there was a lot of weak points at the corners/wherever we used a gusset. Our plan for tomorrow is to remove all of these week points by replaced it all with solid quarter inch plate, and adding triangle braces to the spots that are inside of the bumper. We will be redoing a lot of this prototype tomorrow.

Because Sagas are “Long Stories”

NullPointerException

Ritik investigated the code for 15 minutes. The first issue was an issue of “circular reliance”, if you will. A variable was being assigned a value given by a method, which itself used the value of the variable. At the very beginning of the pure pursuit, this variable would be null, as it would not be assigned a value. Once this code was tested, the robot jerked before another

NullPointerException

Ritik thought it was another instance of a variable not being initialized to a value; rather, a variable was being assigned a value from a method which happened to return null. In particular, this variable stored the location of the point that the robot should drive towards. Since the robot was too far away from the path, the method got confused and returned null. Ritik worked around this issue by changing the location estimator to use the encoders and changing the path from a complicated turn to a straight line.

This time, the robot drove in a straight line, and didn’t stop until disabled. However, when the path was changed, the robot would jerk around, and wouldn’t stop until disabled.

After some deliberation, Isaac Ash decided to look at the encoders. After all, if something was wrong with the encoders, then the robot cannot know where it is, and therefore will get confused.

2 things were wrong with the encoders

  1. The wire of 1 encoder had been slaughtered by the merciless drivetrain chain
  2. The code assumed that the other encoder was a different type of encoder.

These issues were fixed, the code was deployed, and the robot was enabled.

To be continued

 

Programming

After installing the right mag encoder yesterday and finally having two mag encoders working, the left mag encoder was very nice and suddenly gave 0 input. The wires were all connected. We then attempted to flash the talon, but the Microsoft Silverlight web server was not displaying anything — not even one single talon. After getting tired of trying to fix it with successive restarts/reboots of the RoboRIO, robot, and web server, we left for a short period of time. When coming back, it magically fixed itself. ¯\_(ツ)_/¯

Also navX was “interesting”. Due to (probably) magnetic fields from the motor, the navX thinks the robot is at a pitch of ~33 degrees, and is about 20 degrees off when doing a full rotation when getting yaw values.

We are now using GitHub Issues for a variety of different purposes, including (but not limited to) bugs, electrical problems, and ideas. If there is something you want to see happen (or don’t) include it here!

Day 7 (1/12/2018)

Introduction

The team is still working on the various prototypes in the room. The entire team needs to help with making the prototypes so if you are available during build time please stop in and help for a bit. By next Tuesday all prototypes have to done and ready to present. At Tuesday’s meeting we will vote on the best prototypes. The other deadlines will be available on the team calendar. Also on Wednesdays the build time will be changed to be from 6 pm – 9 pm. Additionally, The drill press stand should be done in the upcoming couple of days.

Some more miscellaneous news

  • Dr. Steve Jons has suggested using the ceiling and a vision processing system to figure out the absolute position of the robot.
  • The elevator carriage is in progress.

 

Active Intake

The team did a little bit of work on the active intake today. The pivots were brought in a little bit to make sure the active will fit in the frame. There was also progress made on the CAD. Tomorrow it would be nice if the active could be tested. There was also a discussion of where the motor for the wheels should be. The team was thinking that there would be a shaft in the pivot that would have belt connected to both wheels and the motor which will be attached to that bar.

 

Programming

Today programmers worked more on Pure Pursuit. It is starting to get smoother and smoother, and it can be seen that the robot can now rotate and move. However, it is still deviating far enough from the waypoint-based trajectory that it is forced to stop. This is because it cannot find any goal points within the given look ahead distance. Oddly, when the robot is supposed to go straight it initially rotates. This might be due to a number of reasons, but most probably it could be because of:

  1. Inversion somewhere in motor-related code (something should be multiplied by -1). This would cause the robot to rotate when it should go straight
  2. The robot thinking it is not where it really is.
    1. Tomorrow we will test the estimation of absolute robot location in teleop to provide insight to this issue

We also crushed some other issues today as well. Both a mag and quadrature encoder were on the robot which would have led to problems since they have different resolutions. However, this really was a problem because the quadrature encoder was not connected to the robot at all (chain + cable = not happy cable). This caused the location estimation function that used left and right encoder values to give wrong data.

A side note: trajectories can get more complicated (and fun) when more minute details are considered. There is a paper that has been briefly looked over and will most likely serve as a foundation for upcoming trajectory improvements.

Something cool…

Coming soon

Day 6 (1/11/2018)

Introduction

Today there was an Engineering Leads meeting. The leads talked about the upcoming weeks and the plans for what should be done. By next Tuesday all prototypes have to done and ready to present. At Tuesday’s meeting, we will vote on the best prototypes. The other deadlines will be available on the team calendar. Also on Wednesdays, the build time will be changed to be from 6 pm – 9 pm. Additionally, The drill press stand should be done tomorrow.

IMG_5339.JPG

Active Intake

The team did a little bit of work on the active intake today. The team decided that the bumper did not need to be behind the active. This gives us more room to intake the power cubes. The bumper that was on our prototype was removed. The team also adjusted the things that stick out the side of the robot so that they were less than 28 inches. This allows them to fit in our frame width. This adjustment will change the angles of the front part but not by enough to change how the active works. There was some other fine-tuning work that was finished. The CAD has also been started and worked on. The CAD is mostly the only thing that needs to be done and maybe some more fine tuning and adjusting.

Programming

Today programmers worked more on Pure Pursuit. It is starting to get smoother and smoother, and it can be seen that the robot can now rotate and move. However, it is still deviating far enough from the waypoint-based trajectory that it is forced to stop. This is because it cannot find any goal points within the given look ahead distance. Oddly, when the robot is supposed to go straight it initially rotates. This might be due to a number of reasons, but most probably it could be because of:

  1. Inversion somewhere in motor-related code (something should be multiplied by -1). This would cause the robot to rotate when it should go straight
  2. The robot thinking it is not where it really is.
    1. Tomorrow we will test the estimation of absolute robot location in teleop to provide insight into this issue

We also crushed some other issues today as well. Both a mag and quadrature encoder were on the robot which would have led to problems since they have different resolutions. However, this really was a problem because the quadrature encoder was not connected to the robot at all (chain + cable = not happy cable). This caused the location estimation function that used left and right encoder values to give wrong data.

A side note: trajectories can get more complicated (and fun) when more minute details are considered. There is a paper that has been briefly looked over and will most likely serve as a foundation for upcoming trajectory improvements.

CAD

Today, the CAD team’s decision to send in the drivetrain drawings on Tuesday was vetoed by the engineering leads and captains, who instead opted to send in the sidebars immediately, and send them back and front on Tuesday, when it will be confirmed that the drivetrain will or will not require a hole in the frame.

Isaac W made drawings of the sidebars and sent them in.

Something Crazy

Coming soon…

Day 5 (1/10/2018)

Introduction

Prototypes are still continually being tested and modified. However, due to the many minuscule changes that often take place, it is often difficult to continually write about it all. Today was a light work day, partially due to the fact that many other activities often schedule events and gatherings on Wednesday. It was partially due to this that we left Wednesdays as a no-build day last year for the first few weeks of build. In the coming weeks, we will have much more consistent and thorough updates to this blog as we pick up the pace and decide what our robot will look like and what mechanisms we will use. Most prototypes just had CAD done on them today. So instead of that, let us tell a story.

OutOfMemoryException: A Saga

Let’s begin with some backstory. Way, way back at St. Louis champs, Grant took 2 unsuspecting programmers on a trip to see the Cheezy Poofs win their division. Ritik and Isaac AJ were mesmerized by the smooth autonomous that the Cheezy Poofs possessed. In a mad attempt to recreate their beautiful autonomous, Ritik tried implementing a system called “Trajectories” that would drive the robot along a trajectory by controlling position and speed simultaneously.

 

It was a failure.



Cut to late November. A mathematical genius — Andrew Gazelka — has become active on the team and started trying to recreate the smooth autonomous using a different system called “Pure Pursuit”, explained in a previous blog post. Gazelka initially used a simulator (that he built from scratch for the sole purpose of testing his code) to test his algorithm.

 

In the simulator, Pure Pursuit was a success.

 

By Winter Break, Andrew had ported all of his Pure Pursuit code from the simulator to the robot. However, it would not get tested until after Kickoff. Once it did get tested, the programmers were shocked at what they saw.

No Robot Code

Ritik, remembering from past experiences, SSH’d into the robot and attempted to manually start the script.

OutOfMemoryException

The programmers had never seen such an exception before. They cleared the memory with a restart of the robot, and tried again.

OutOfMemoryException

Donovan, being the local expert on the inner workings Java, noted that Andrew’s code made extensive use of double precision decimal numbers. After converting a great many variables to single precision floating point numbers (which are 32-bit, as opposed to the 64-bit doubles), Donovan was satisfied. Ritik pulled from GitHub and deployed.

NullPointerException

To be continued . . .