We are a bit behind, so we plan to post twice this week. Sorry about that!
Let’s talk robots.
This week was significantly easier than the previous weeks. We didn’t have any tech problems or weather anomalies to slow us down. The build team had to redesign the intake and the programming team worked on finding and perfecting values for servos and the shooter.
Build progress
The intake turned out to be less successful than we had hoped. Upon completion, we realized that it struggled to get the discs up on the ramp. We needed a small unobtrusive device that could ease the discs onto the ramp. We did this by having a set of small wheels that were in a cut we made in the ramp. With this new idea disks would easily begin their ascension up the ramp.
Along with that, we started testing prototypes of a wobble goal grab mechanism. We wanted something that we could maneuver easily, along with being modular and interswappable over time.
We originally tried a claw similar to a “Candy Crane”, but it didn’t have the type of contact we wanted. Because of this, we went to Inventor and made a simple claw that would function the way we wanted, and that we can improve upon.
Programming progress
The programming team had a relatively un-interesting week as compared to the innovation that the build team had this week. The programming team created simple testing files, to try the shooter at different power levels, and to test servos across the robot at different positions.
Nothing was really that new this week, but with our team being majority rookies, we wanted to go into some more advanced content. We had group discussions about vision, and how we wanted to implement that this year. The team talked about the differences between Tensorflow and Vuforia, and how they worked together in the base object detection files, provided in the FTC SDK.
Being similar to the previous year in terms of format, we watched videos of teams with their vision from Skystone, as inspiration for how we wanted to approach it, and to give the team a good sense of how it worked.
As the build team gets closer to finishing hardware, the programming team can go ahead and focus on the recalibration process with Roadrunner using Feedforward with dead wheels.
Skor
One weekend, Ritesh decided to see if he could make an app in a weekend. Two days. 48 hours. And he successfully did. In those two days, he made Skor.
Skor is a simple, intuitive FTC scoring app. Designed for the 2020 FIRST Tech Challenge Season: Ultimate Goal, Skor allows you to do everything. Just a little bit simpler.
It’s free, and has been used by dozens of teams, including our own, for quick, and efficient score keeping. He plans on updating it with timer support, FRC/VEX/FLL support, and adding more simplistic functionality.
Ritesh: With such a busy season, it’s been hard to find time to add updates, but once I get some downtime, I hope to get some more progress done upon it.
SCORE
With Skor, you can actively score your team and others, whether it is during practice, virtual competition, or scouting. Everything has been designed to be as simple and easy as possible, so you can focus on what really matters: making your robot the best it can be.
SAVE
Skor also lets you save your scores over time. This way, you can see your robot improve over time, as well as be able to plot different scores throughout any timeframe.
When looking at saved scores, you get a detailed score breakdown, explaining every single thing that your robot did and didn't do.
SHARE
Share your top scores with your team members, friends, etc. Be proud of your robot and share what you have made using the in-built share feature in Skor.
UPDATES
Over time, Skor will be getting more features and options to help your team make the best robot you possibly can. If you have any feature requests, feel free to contact us.
Conclusion
In conclusion, this week was fairly plain. We had no major mess-ups or mistakes to fix. We effortlessly addressed the problems that came our way and worked our hardest to get the robot ready for competition.
If there can be any takeaway from this week it has to be an adjustment in the design phase. In the design phase we should spend more time considering what could not work and have a solution in the case it does.
Once again, thanks for reading. If you have any questions, feel free to comment down below or shoot us an email.