Our first ever Engineering Notebook was built in our 2015-2016 Nothing But Net Competition.
The notebook artist and documentor is team member Andrew Wang.
Here is the link: https://goo.gl/pwvtXv
He has really spent a long time making this notebook and he is an amazing artist.
Full Team:
Andrew Wang - Primary Documentor, Information Speaker For Other Teams, and Decoration Artist.
Andrew Archer - Secondary Information Speaker, Secondary Driver, Secondary Builder, 3D Modeler, Video maker, and Music Creator
Connor White - Primary Builder, Primary Programmer, Quality Manager, Idea Maker, and Online Post Manager
Haley White - Primary Scout, Secondary Artist, Secondary Decoration Artist, Team Informer/Suggester
(Haley White is a new teammate of our 2016-2017 Competition now)
We will be limiting our posts so we could focus on our build.
Suggestions from what we’ve learned:
-1.0 Keys is better for our robot, about 1/4th the wait time for pairing, longer distance and less accidental impairing, and more reliable.
-Quality matters, so Delta II will be focusing on quality.
-Autonomous is worth it, not just auton bonus, but also the points your robot makes for a head-start.
-Always check the batteries and to not overcharge them (Accidentally overcharged our batteries at regionals and lost, so we didn’t make it to worlds)
-Check ALL connections (Flywheels stopped working at a competition, lost 3-4 matches due to it)
You could’ve just edited the original post. But thank you for taking time away from your build to unveil your engineering book to us. It’s pretty sick.
I attempted to edit the post, but it wouldn’t allow me to…
And you are welcome. Andrew Wang spent a lot of work drawing and creating the slides, and he deserves all the credit. Thanks for the compliment
1.0 keys working better? I understand the faster pairing, but 2.0s don’t disconnect unless they lose power or unless they are completely covered up. Mine on my worlds robot only disconnected maybe 4-5 times and that was due to low voltage and smacking into a wall.
Yeah, for some reason, it does work better with our robot, and is more reliable. It can handle bumps and crashes, and works well even with metal over it.
Another thing to bring up, if you know about VEX Open, you would know that you turn your robot on when the match starts… This means that if you were using 1.0 Keys, you would have faster pairing and have more time to make points, while the other robots are still getting connected. It takes around 5-10 seconds for a 2.0 connection to work with our robot, so this means that it’s free time to score while the other robots can’t… But sadly, we’re in normal VEX.
I have never heard of a vex competition doing that. It would be unfair to teams whose cortexes have issues syncing in heavy radio trafficked areas (any VA competition has like 40 teams all testing at once, so 2.0 is a must due to the allowing of all 11 channels in wifi instead of 1 for competition one 1.0). How do they do autonomous then? I had to sync, wait about 3 seconds for calibrations, then select auton before I could even plug into the towers or my robot wouldn’t even run the flywheel.
Everybody has the option to try using 1.0 keys… Most probably they’ll still work for your robot, we once switched our cortex and yet it still worked. Try doing 1.0 keys on your robot, and you could realize that they have a better reliability compared to the 2.0 keys.
I remember them fondly. Back in toss-up when 2.0 first came out, we hated the white keys because they had horrible firmware. Now I just hate them because they take 30-40 seconds to sync up sometimes. They also have limited debug and stream bandwidth, so my reading of sensor values is always delayed. Luckily I know how to graph the data. I might try the black keys just for debugging next year.
This is an interesting idea. I don’t have access to the old 1.0 keys but I know for sure our club still has them for demo robots. We’ll have to test them both locally and at competition to be sure (too risk-averse :P), but if this is true, the quick startup time could be very useful during autonomous programming and sensor value debugging.
