Redshift Project Depot

Didn't update this for a while; so I did it just now.

updated pincher speed fix.

Updated with the new pincher (RIDE) info.

To change the max file upload size in Wordpress, do the following:

   
• Go to the Xampp control panel.
• Stop Apache
• On the Apache line, click on "Config" and select "PHP (php.ini)"
• Edit this file - look for "upload_max_filesize" and set it to the value you want.
• Start Apache
• Verify file size in Wordpress - Look at "Media", "Add New" and see what it says.

It's currently set to "256M". I tried 1024M but all that did was max it out to 260M so either there is another setting somewhere else or the internal max is 260M.

OP has been updated to reflect the code used at RIDE with the new Pincher mechanism (that replaced the old arm extension / wrist / gripper / intake)

For the 2018 version, we replaced the raspberry pi with a Dell laptop. The software platform is Wordpress. This provides ease of programming & a rich set of features. Limitations include the inability to run MAME from the web pages (at least not easily since this is a security feature of a web server & browser combination).

A few students showed up for the debriefing. Here's what went on the white board.

Problems encountered at RIDE

   
• Ice pick sometimes did not release cube
• Drive team user errors - picking up and dropping Cubes
• Arm movement is slow (not everyone agreed here. But SW says they did not max out the arm speeds)
• Ice pick open/close is slow
• Observation - drive team could have used a camera to better see the placement of Cubes on the Scale.
• Drive team coordination and teamwork - not always in sync
• Cube can fall backwards off the arm (happened a few times)

What we can do in the next few weeks leading up to BC19. In parenthesis is a number and letter. The number (1,2,3) is priority. The letter (S,M,L) is size of task. Tasks with some element of uncertainty are bumped up one size from where they would otherwise be. Boldface text is current status. Tasks that provide new functionality have higher priority than those that are improvements over something we already have.

   
• Weight is about 107 pounds so we have 13 pounds to play with.
• (2) (S) Make ice pick open and close faster (done 4/4/18, reverted 4/11/18)
• (1) (L) Add climber (done 5/8/18)
• (1) (S) Fix cube release (seems to be good 4/11/18)
• (2) (S) Max out motor speed on arm (done 4/9/18)
• (1) (M) Fix arm pot (done 4/9/18)
• (3) (?) Add feedback / sensing aid for cube placement. Add camera. (done 5/7/18)
• (2) (L) Add intake for faster acquisition (no longer needed 4/6/18)
• (3) (M) reaching behind to drop cube (no longer needed 4/9/18)
• (3) (M) narrow cube pickup (Skip)

Lessons learned

   
• KISS
• Do not repeat past mistakes

Other things to do:

   
• get parts / IMU (4/4/18) Ed got some belts and pulleys from McMaster for prototyping. Turns out we already have the NavX IMU)

Open issues:

   
• who is on drive team? (Ben K, Pablo, Sepher, Saharsh, Gargi, Ishita)

This posting is obviously late but it's important to document everything.

I took a picture of the workroom whiteboard and transcribed it here. The flow of the discussion is reflected in the grouping of the items below.

First we discussed what went right and wrong. The focus is of course on what went wrong since that's what we wanted to fix between WPI and RIDE.

   
• arm is slow, cycle time too is long. We can't process enough Cubes in a match.
• intake and claw alignment issues.
• exposed, easily damaged, and inoperative limit switches
• gyro drift means arm does not know how to get to the same place over time.
• intake alignment is questionable; does not work as needed.
• auto is not reliable.
• extension is a PITA
• lead screw hub broke.
• software did not monitor all motors. We burned out a motor that was stalling.
• bad swerve drive? We replaced one swerve unit but it later tested fine. A cable from the unit to the RoboRio was later found to be loose. Did the symptoms match the cable problem?
• we had problems with the arm pot - is the unit bad or is it just bad wiring?
• grabber alignment to cube - not reliable
• tower is shaky. When things get tall, things get tipsy. It's just physics.
• swerve reset when not driving. This is normally not an issue on flat ground. But the game's angled flooring near the Scale can cause enough movement of the robot to affect the game.
• arm positioning not optimal

Now that we have a list of problems, we tried to summarize the root cause that lead to these problems from a design point of view.

   
• lack of consistency and repeatability
• lack of overall speed
• intake has only 2 wheels so Cubes can get stuck in odd positions.
• any one failure breaks everything - too fragile
• too much automation, no recovery when something goes wrong
• too susceptible to misalignment (little margin for error)
• lacks robustness
• two isolated subsystem to get Cube - intake and grabber
• too many exposed delicate items - limit switches, intake assembly, electrical board
• intake not optimal, can not handle 11 inch Cube side.
• too much wiring, too much everything
• no climber

Finally we need to identify what led to a poor design so we don't do it again in the future.

   
• Linear motion is generally a bad thing on our robots. They tend not to be as easy to create, deploy or use.
• We employed too many band-aids to make things work. Needing a band-aid is often a sign that there's an underlying design problem that needs to be addressed.
• We built subsystems but did not integrate them during the design phase.
• There was a lack of communication between members of the team.

Post RIDE update.
This arm worked for the most part. The most glaring problem was that it sometimes refused to release the Cube. We didn't see this happen until about halfway through the matches. We believe this happens when the Cube's fabric starts to stretch from use and when we grab the Cube where the handle lies. The circular guard plate we use to keep the nubs from digging too deeply into the Cube is getting caught on the plastic lattice behind the nylon fabric.

We tried to fix this by enlarging the guard a little bit (we have to be careful how large to make this to keep within the 16 inch rule). Finally we removed the plate entirely. This seemed to work but we would need extensive testing to prove it really is fixed. We'll also need Cubes that are beat-up to simulate the real game pieces.

Update - after trying with a wooden mock-up, we found that using a spring has a drawback: when the added mass of the Cube is taken into account, horizontal movement of the arm (such as when the robot turns) shifts the force applied to the Cube by the 2 pincers. The forces are no longer even due to the robot's movement and this causes the Cube to fall out. One solution is to add strength to the spring. Another is just to lock down the pincer. We decided to replace the spring with a motor that will effectively close the pincer to a fixed position and keep it there.