FTC Programming Goals for Good Hardware Management FTC

FTC Programming Goals for Good Hardware Management

FTC Programming – Android Studio Goals for good hardware management 2019 -2020 season kickoff class presented by: Vince Westin, Technical Evangelist, Dell Georgia FTC Lead FTA vincewestin@gmail. com

Building winning robots • Hardware without software – May look good, but won’t do much • Software without hardware – Nice code flow, but can’t do anything • Together, they make a winning robot – Good hardware to be able to achieve all goals – Motors for moving and lifting – Sensors for robot awareness – Software can make driving much easier for Tele. Op – Software to complete autonomous goals

Android Studio coding overview • Code written in C/C++/java or a derivative – A basic understanding of code flow is OK to start – Really knowing at least one language well is a big help • Driver station – Joysticks/controllers for remote robot operation – Fixed program (not modified) • With options for robot feedback display • Robot control – Custom for each team/robot – Understands the hardware installed – Code to manage wheels, other motors, servos, sensors, lights, etc. – Sample code for the tank robot is a great start

Preparing with Android Studio • Download Android Studio – https: //developer. android. com/studio/index. html • Download FTC code from Git. Hub (zipped folder) – https: //github. com/ftctechnh/ftc_app • Be sure you get this year’s 5. 0 code base (big changes) – Place under the Android. Dev folder, renamed for your team – Doc folder can be very useful – Your code will live in the Team. Code folder • DO NOT make changes anywhere else in the code tree • Set your phones in developer mode (see docs) • Create robot config to map software names to hardware – Stored as an XML on the phone, easier to edit on PC – Update for device serial numbers and such

Files on the phones • Only one app per phone (USB control conflict) • Use the Android Studio terminal window – Manual ADB commands • Driver app to driver phone – Updated app in docs/apk/ folder in Git. Hub download – Adb install doc/apps/Ftc. Driver. Station-release. apk • Robot control app is the one you will build – Best to skip the default robot app from Git. Hub download • Read robot config XML from the robot control phone – Adb pull /sdcard/FIRST/my. Config. Name. xml. – Adb push my. Config. Name. xml /sdcard/FIRST/ • Use the self inspection to verify everything is right!

Coding fundamentals • Hardware mapping – Definitions to create software ‘instances’ (handles) to control hardware – Motors and servos have speed/power, direction, and often position – Sensors can detect distance, color, weight, magnetics, etc. • Orientation sensing makes autonomous MUCH easier to program • IMUs are great! • Drive train – Motors to move the robot usually need to work together – Common drive train code creates a ‘virtual’ robot in software that is easy to move • Manipulation – Motors and servos can grab, lift, etc – often coordinated in groups

General Code Ideas • Use a core class to define your robot hardware (once) – Also include shared functions you will use – Extension of the Op. Mode class – Extend the others from this class • With versions in the names using @Tele. Op, @Autonomous • Build a test Op. Mode – Be able to check each motor, servo, sensor, etc. • Of course you need Tele. Op • And you need autonomous • Consider extending autonomous for each option (red/blue, …)

Sample tank class hierarchy • Rev. Tank. Core – hardware mapping… – Test – individual hardware control – Tele. OP – driver controlled robot – Auto – meat of autonomous code • Auto. Blue. Ground – set blue and no drop • Auto. Red. Drop – set red and drop • Auto. Red. Drop. Delay, same, but wait to start

Expansion Hub Inertial Motion Unit • Shows up as Sensor BNO 055 IMU – Provides heading, roll, pitch, gravity, … • Sample code for calibration and use – Included in the ‘external. samples’ folder of the repository – Calibration likely not needed • Sample tank code with class materials – Includes IMU-guided autonomous

Battery Power Sensor • Useful link to the battery sensor – https: //www. reddit. com/r/FTC/comments/3 odx 26/is_it _possible_to_get_the_battery_voltage/ – Link is in the sample code… battery. Volt. Sensor = hardware. Map. voltage. Sensor. get("Expansion Hub 1"); • Part of every Rev hub

Autonomous • Without sensors, you are floating blind – Orientation on the field (really critical, often missed – use IMU) – Distance traveled while moving – Color/distance sensing, etc. • Much harder to code than Tele. Op – Code for every situation the robot can encounter • And there a lot! – Sad to watch a robot wander off when it gets ‘fooled’ • Pre-set items like alliance color, field position, start delay, etc. • Usually based on a ‘state machine’ (working on goal YYY) – Now I am looking for a blue line – Now I am turning right 90 degrees – Now….

Tele. Op • Joysticks to drive train – Make it easy for the drive team – Things like slow/fine movement speed – Reversible ‘front’ • Manipulation control – Grab something – Tip/throw – angle and speed settings • Sensors – Detect line/color/weight and signal the drive team – Stop lift at certain target height(s)

Robot feedback • How will the team knows what the robot sees/thinks? – Feedback is critical to robot operation • Consider hardware feedback options – Raise arm/flag – Turn on a light (or a string of LEDs), change color – Will the team really notice under stress of competition? • Consider what the team needs to do – Feedback needs to inform/remind them easily (not blinking codes)

Managing complex situations • You are NOT the first person/team to solve this (in general) – What code have others shared that can guide you? – If not code, are there designs you can use to help speed things up? – ALWAYS document (code comments) ANY source that helps you along • Break big problems into smaller parts – Make the wheels move, then coordinate the drive train – Display a sensor reading, then combine with a motor/servo • Consider the control/software side while exploring hardware ideas – Hardware you cannot control reliably will not score points • Ask mentors for guidance – They may have others to ask as well – use the help!

Other challenges • You will write bugs – Finding them early can lessen the pain • Things do not always work – Hardware can fail – can the code adapt? – Sensors can give bad readings – can you skip one (or more) bad data points? • The season is short, but the challenges keep coming – Writing the perfect solution can take a lot longer than you think – Writing really complex code means it may be difficult to adjust as needed • You can share things across seasons – Need CLEAR documentation on what is old and what is new

Building the code • Code needs to be ready for practice EARLY – Drive teams need time to get comfortable – Look for ways to automate/simplify so driving is simpler/reflexive – A great robot without proper driving will lose badly • Add functions/classes to manage processes – Group hardware together to manage as a group (drive train, lift, etc. ) – Make them easy to add/remove for debugging • Hardware and software build can work in parallel – Software refining/debugging will be needed once hardware is done • Plan for programmer time with a dedicated robot • Plan for drive team time with working code • Plan to make LOTS of versions

Testing and automation • Things will break in competition (or transit or …) • Software can make hardware issues easier to find – Be able to control every motor/servo separately – Be able to control systems together (drive train, …) – Be able to verify/test each sensor (orientation, power, distance, …) • Do you need to test for things that shift? – Check belt tension/skipping – Check for slippage in drive train, gear set, chain gear, … • What can be automated? – Maybe force a checklist to be completed to start autonomous? – Can you built a test of a launch system that checks the distance?

Documentation and backups • Did you come up with a great piece of code? – Who wrote it/when? – What inspired it? – Use code comments to be able to remember • Is there something really not obvious about your code? – How can you explain it so another programmer can jump in and help? – How can you comment it so that a judge can easily understand? • Keep lots of backups – Weekly at least, plus after each breakthrough, plus others because you can – Copies on one system are NOT backups! • Spread them around (or cloud share) – For multiple programmers, have an easy way to share/merge updates • Check for updates from FIRST on code repositories regularly – Code updates can happen WEEKLY – Some of the issues they find/fix may be things driving you nuts….

Join in the Discussion on Slack • GA FTC Coaches & Mentors – Team organization, fundraising, recruiting, hosting, etc. • GA FTC Resources – Everyone and everything team related! • Send an email to vincewestin@gmail. com

FTC Programming – Android Studio Goals for good hardware management 2019 -2020 season kickoff class presented by: Vince Westin, Technical Evangelist, Dell Georgia FTC Lead FTA vincewestin@gmail. com k n a h T ! u Yo