Road Runner Overview and Demo

 

Tonight, we discussed the timeline leading up to the first League Meet, scheduled for the week of 16 November.  We currently have roughly 5 weeks to get everything ready for that meet.  The Mechanical/Engineering team has decided to opt out of building the claw mechanism to hold the wobble goal for the first meet.  Instead, they will focus on ensuring that we have strong intake, holding area, and shooting mechanisms.

This will alter our original thoughts for Autonomous sequencing.  Originally, we discussed having the robot shoot the onboard discs before deploying the wobble goal.  However, if we have to push/pull the wobble goal, we should focus on moving it first rather than risk losing it while performing the shooting.

Prior to the meeting, Nathan asked the development team to download and install Android Studio.  During the meeting, he gave a demonstration of the java code in Android Studio.  He used the RoadRunner code to point out some of the syntax and structure related to programming Java.

Speaking of RoadRunner, we also discussed using it again this year.  RoadRunner is a software package designed by FTC team 4634 FROGBots to facilitate movement.  After giving an overview of the package, Nathan described the tuning process and then gave a demonstration of the dashboard tools that allow you to program movements using a map of the competition field.  





Comments

Post a Comment

Popular posts from this blog

October 17 - Engineering and Programming Saturday Meeting

Image
 Today, the engineers have started working on assembling and implementing our intake system. Our team members have designed and 3D printed many parts to use in our intake system. We still have much to do before our intake system is fully operational and some of us will CAD some more 3D parts between meetings. The programmers tweaked the vision software to fit the camera used. It worked "spectacularly" as noted by a programmer. A flowchart was drawn up for the driver control period.
Read more

Enabling testing for the Intake and Flappy Servo together

 Previously, the programming team had supplied the engineering team with two test OpModes.  The first OpMode, called "VariableMotorTest" was a Teleop OpMode that allowed a driver to set various motor speeds.  This has been used by the team to help determine the right motor speeds to use for the intake motor and shooter motors. We also created another OpMode called ContinuousServoTest which spins the continuous servo.  This was used to help the engineers test the prototype "flappy servo" which is the mechanism used to transfer the disks from the intake to the shooter platform. At the Oct 19th meeting, the engineering team was able to mount the intake system onto the robot frame.  They were able to successfully test both the flappy servo and the intake motor, but not at the same time. At tonight's programmer meeting, we developed a new OpMode called Motor+ServoSpeedTest.  This OpMode combines the features of the other two OpModes by allowing a user to se...
Read more

Consistent Shooter Power

The PROBLEM:    During meet 1, we found that the shooter accuracy was very inconsistent. This made it hard to score rings in both Autonomous and Driver-Controlled portions of the meet. During the Driver-Controlled portion, the team could compensate somewhat if they saw they were shooting too high or too low, but we usually wasted a couple of rings determining how far off we were.  The DIAGNOSIS:    Shooter accuracy appears to have been affected by at least two different factors.   1) The mechanism for feeding rings into the shooter wheel did did not consistently deliver the rings the same way every time. Sometimes rings would be tipped at a slight angle when hitting the wheel or hit the wheel at a different speed.   2) The speed that the motor itself is spinning seemed highly dependent on the battery power. During one match, we used a battery that seemed overcharged and had a higher voltage than the previous ma...
Read more