Presentation is loading. Please wait.

Presentation is loading. Please wait.

FTC Programming Goals for Good Hardware Management

Similar presentations


Presentation on theme: "FTC Programming Goals for Good Hardware Management"— Presentation transcript:

1 FTC Programming Goals for Good Hardware Management
Season Kickoff Vince Westin, Dell – Georgia Lead FTA

2 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 to complete autonomous goals Software can make driving much easier for tele-op goals

3 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.

4 Coding fundamentals Hardware mapping Drive train Manipulation
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

5 Autonomous Without sensors, you are floating blind
Orientation on the field (really critical, often missed – use an 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 are 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 X) Now I am looking for a blue line Now I am turning right 90 degrees Now….

6 Tele-op Joysticks to drive train Manipulation control Sensors
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)

7 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)

8 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!

9 Other challenges You will write bugs Things do not always work
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

10 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

11 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? Can you built a test of a launch system that checks the distance? Maybe force a checklist to be completed to start autonomous?

12 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) If you have multiple programmers, have an easy way to share/merge updates Check for updates from FIRST on code repositories regularly

13 Preparing with Android Studio
Download Android Studio Download FTC code from GitHub (zipped folder) Place under the AndroidDev folder, renamed for your team Doc folder can be very useful Your code will live in the TeamCode folder within the GitHub data 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

14 Files on the phones Only one app per phone (USB control conflict)
Use the Android Studio terminal window for manual ADB commads. Driver app to driver phone Updated app in docs/apk/ folder in GitHub download Adb install doc/apps/FtcDriverStation-release.apk Robot control app is the one you will build Best to skip the default robot app from GitHub download Read robot config XML from the robot control phone Adb pull /sdcard/FIRST/myConfigName.xml . Adb push myConfigName.xml /sdcard/FIRST/

15 Extending classes Build a base class for your robot Extend the core
Core class to map hardware, common drive code, etc. Extend the core Test code (each motor, servo, sensor, etc.) TeleOp Autonomous Consider extending autonomous for each option (red/blue, …) Use to include version numbers

16 FTC Programming Goals for Good Hardware Management
Season Kickoff Vince Westin, Dell – Georgia Lead FTA


Download ppt "FTC Programming Goals for Good Hardware Management"

Similar presentations


Ads by Google