Uncategorized

FRC 2019 – Camera Best Practices

To get the most out of your cameras for the FRC 2019, please consider following these recommendations. This document does not contain the theory for the recommendations. If the theory is desired or for any questions regarding these recommendations, please contact a MN CSA at firstmn.csa@gmail.com or http://firstmncsa.slack.com.

Desired goals that drive these recommendations

  • Low latency
    • Allows driver to react to the most current status with a minimal delay between driver input and robot action cycle time.
  • Low bandwidth usage
    • Reduced risk of driver input being delayed due to high bandwidth.
      • There is a Quality of Service mechanism that should prevent this, but to fully eliminate the risk, reduce bandwidth if possible.
    • Bandwidth target is below 3/Mbs
  • Ease of use

 

Possible Misconceptions

  • Higher FPS means lower latency.
    • While higher FPS can appear to reduce latency in a video game, that only occurs when the underlying infrastructure can support the desired FPS with minimal latency to begin with.
    • Low latency is a function of the infrastructure’s ability to get data from point a, the camera, to point b, the DS screen, with minimal delays. This can only occur if that infrastructure has available waiting capacity to process, transmit and display the video.
    • Higher FPS can easily overload the underlying infrastructure, which can cause delays at every stage of the point a to point b pipeline, thus increasing the overall latency.
    • Lowering FPS to a level which the infrastructure can handle the pipeline while still maintaining available waiting capacity, will assist in achieving the lowest possible latency.
  • High Resolution is better
    • High resolution is desirable if additional detail allows for a strategic advantage, but for most tasks, lower latency will offer a much better robot control experience.
    • 640×480 is not twice as much as 320×240. It is 4 times as much. The extra time required to process, transmit and display 4 times the data is most likely not going to offset the higher latency and reduce capacity required for its use.
  • This or that device is the right one for all tasks.
    • Not all devices work well in all situations, you should balance the total cost to implement, maintain and configure additional devices before making changes. Cost in this sense means monetary, time, expertise, weight, etc…

 

Driver Cam

  • Use FRCVision on Raspberry PI instead of cameras hosted on roboRIO
  • URL: https://wpilib.screenstepslive.com/s/currentCS/m/85074/l/1027241-using-the-raspberry-pi-for-frc
  • Benefits:
    • Potential for robot code to respond faster to driver input by offloading CPU intensive task from roboRIO.
    • Lower video latency and higher frame rates due to increased cpu cycles available on Pi.
    • Ability to handle more concurrent streams than a roboRIO.
    • Ability to control stream from FRC shuffleboard and LabView Dashboard.
    • Ability to control Resolution, FPS and compression per camera feed.
    • Ability to have a per camera vision processing pipeline.
    • Multiple language choices for vision processing pipeline.
    • No need to add code for basic camera streaming.
  • Recommended Usage:
    • Driver video streaming.
    • Video processing, target acquisition and tracking.
  • Recommended Equipment:
    • Raspberry Pi 3 B or B+, B+ preferred.
    • Microsoft Lifecam HD-3000
    • Logitech c920, c930, c270, c310
    • Any Linux UVC  supported USB camera that supports MJPEG and desired resolution and fps in camera hardware: http://www.ideasonboard.org/uvc/#devices
  • Optional Equipment:
  • Recommended hardware settings, per camera.
    • Format: MJPEG
    • Resolution: 320×240
    • FPS: 15-20, reduce as needed to reduce Pi cpu usage.
  • Recommended stream settings, per camera
    • Format: MJPEG
    • Resolution: 320×240
    • FPS: 10-15, reduce as needed to lower Pi cpu usage or bandwidth
    • Compression: 30, adjust as needed to get desired cpu usage, bandwidth and clarity.
  • Considerations:
    • Power:, ensure 2.5+ amps of power are available to the Pi, especially if using 3-4 cameras and / or vision processing pipeline is in use.
    • Actual FPS per video stream as listed in the DS view should match set FPS for the stream as configured for that camera, if it does not, lower FPS and / or Resolution or increase compression until actual FPS and set FPS match and video quality and latency is acceptable.
          • Rather than using driver mode, create a “driver” pipeline. Turn down the exposure to reduce stream bandwidth.
          • Using a USB camera? Use the “stream” NT key to enable picture-in-picture mode. This will dramatically reduce stream bandwidth.
          • Turn the stream rate to “low” in the settings page if streaming isn’t critical for driving.
        • Considerations:
          • Do NOT use for driver vision.
          • Use only for target acquisition and tracking.
          • Stream only output of vision pipeline to DS and only if bandwidth allows.

Chris Roadfeldt

 

Uncategorized

2019 Week 2 CSA Notes

Duluth Double DECCer

In Minnesota, the week 2 events were the Lake Superior Regional and the Northern Lights Regional, both held in the Duluth Entertainment Convention Center (the DECC).

Our observations include:

  • All roboRIOs had to be re-imaged to version FRC_roboRIO_2019_v14.  This update was released after stop-build day, so every bagged robot had to be updated.
    If you haven’t yet attended your first 2019 competition, you can prepare for this by updating your laptops with the FRC Update 2019.2.0.
    If you are helping teams at competition with this, it might be a little quicker to give them the FRC_roboRIO_2019_v14 file and reimage their RIO.
  • All Java and C++ projects had to be updated to GradleRIO version 2019.4.1.  GradleRIO version changes always require inital software downloads, so the first build after changing your version must be done while connected to the internet.  It’s far better to do this before the competition, while you have a good network connection.
    If you are helping teams at the competition, you can give them the latest WPILib update.  This update will install all the latest GradleRIO dependencies, minimizing download time.
  • We were expecting camera problems for LabView.  At Duluth, Brandon and Logon did extra duty for all the Labview teams.
  • Two teams who had programmed their robot in Eclipse with the 2018 version of WPILib.
    Fortunately, this was easy to fix.  We installed the latest WPILib to their laptops and then used the import wizard to convert their projects to GradleRIO.
  • As usual, plenty of teams suffered from loose electrical connections.
    Pull-test all your connections; nothing should come loose.  All the wires to your batteries, circuit breaker, and PDP should be completely immovable.
  • If using the Limelight camera, consider their bandwidth best practices.
  • If you are using a Limelight and / or frcvision on Raspberry PI, consider bringing an ethernet switch in order to assist troubleshooting.
  • Turn off the firewall on your laptops.
Uncategorized

Loop time override warnings

An important message from Omar Zrien from CTR Electronics came out this weekend.  It addresses some warning messages that teams have been reporting:

  • Watchdog not fed within 0.020000s (see warning below).
  • Loop time of 0.02s overrun.

Anyone who uses CTRE’s components should read all of Omar’s posting, but relevant takeaways are:

  • Install the latest Phoenix firmware and add the corresponding Phoenix.json to your project.
  • Keep an eye on the number of get*, set*, and config* calls you make, since each call might consume a little processor time.
  • Don’t worry too much about the overrun warnings as long as your robot is performing.

 

Uncategorized

Labiew Dashboard Camera Fixes

2019 Camera report

Lake Superior Regional and Northern Lights Regional (Duluth, Minnesota)

The following is a report from the Duluth CSA’s on cameras and the dashboard. As of Saturday Afternoon (Week 2) we have experienced 100% success rate of cameras performing between the 123 teams split between the 2 regionals. Our procedure to get this result will be outlined below.

If the team camera works, we let them go without any changes. This usually included the Limelight, Raspberry Pi, ShuffleBoard, and SmartDashboard. These presented very little problems with the FMS and NT.

For teams encountering issues, LabVIEW teams or teams using a LabVIEW dashboard, the following procedure was done in the pits. If the team was able to connect after any of these steps tethered to the robot we sent them out to the field.

In the Pits:

1. Download the 2019.2.1 LabVIEW Dashboard.

This would get passed on by a flash drive to the team’s driver station from a CSA. The folder would be placed on the desktop with the following path :

C:\Users\pcibam\Desktop\FRC_Dashboard\Dashboard.exe

2. If LabVIEW team, convert their code to a fresh 2019.2 Project as follows. All projects were named 2019 Duluth Cameras so we could determine which teams we applied this to. Always save when prompted to during this conversion.

a) Start a brand new project like normal

lv_cam_1_new

 

b) Delete the following from the begin VI. Once cleared it will look as follows. (Old Code)

lv_cam_2

Cleaned (Old Code)

lv_cam_3_cleaned

 

c) Copy everything except the following from begin. (Old Code) and paste in New Code

lv_cam_4_paste_in_new

 

d) Delete the following from Teleop. (New Code)

lv_cam_5_delete_from_teleop

Cleaned

lv_cam_6_cleaned

 

e) Copy everything except the following from Teleop (Old Code) and paste in New code

lv_cam_6a_cam_copy

 

 

f) Delete the following from Periodic Task (New Code)

lv_cam_7_delete_from_periodic

Cleaned

lv_cam_8_cleaned

 

g) Copy everything except the following from Periodic Task (Old Code) and paste in New code

lv_cam_8_copy_except

 

h) Delete the following from Autonomous Independent (New Code)

lv_cam_9_delete_from_auton

Cleaned

lv_cam_10_cleaned

 

i) Copy everything except the following from Autonomous Independent (Old Code) and paste in New code

lv_cam_11

We have not discovered what to do with robot global variables at this time. To be on the safe side teams should recreate these in the new project and link them to the appropriate locations manually.

 

On the field:

Check if NT Communication Light is on

lv_cam_12_dashboard

Once that light is green do the following:

  • If one camera, select the camera and wait. On average it would take about 7 seconds to connect.
  • If 2 cameras, select the second camera first. Let this camera boot up. Then select the first camera. It does not matter which side that cameras are on. Each camera on average would take 7 seconds.

If you have any question feel free to contact me at the information below. I hope this helps for future events! We will be doing the same procedure at the Great Northern Regional (North Dakota) and will report back with results from that regional.

 

Brandon A. Moe

University of Minnesota – Duluth, 2020 Minnesota CSA
FRC Team 7432 NOS Mentor

Personal: moexx399@d.umn.edu

Uncategorized

Preparing for Competition

Your robot is complete, so take a day or two to relax.  Soon you’ll need to start thinking about your next competition.   There are a few things you  should prepare for with respect to your control systems.

First things first:  A new version of the FRC 2019 Update Suite was released, so download it.  This is a mandatory update.   Also, take a look at the 2019 FRC Inspection Checklist. The robot inspectors will use this checklist to determine if your robot is legal.

Bring your code

Sometimes we see teams at competition without their robot software.  This can happen if a team only has one programmer who can’t make the trip, or maybe their programming laptop gets misplaced.  Don’t let this happen to you.  Back up your code to a flash drive or keep a recent copy on your driver’s station.  Or, keep your code online.

This will be especially important when you must re-image your roboRIO at the competition, since the re-imaging process will erase all software currently on your RIO.

Your driver’s laptop

The inspection checklist requires that you must use this year’s driver station software (currently version 19.0).   Use the FRC Update Suite to install all new software onto all the drivers laptops that you intend to bring to competition.  It will ask for your serial number.  You can leave the serial number blank and you will get a 30 day evaluation mode.  You should also do the FRC Update on all your programmer’s laptops.

You definitely don’t want your laptops to do Windows auto-updates while at a busy competition.   To avoid this, make sure all your laptops have the latest Windows updates and then put the auto-updates on a temporary pause.  To do this, open up the Windows Settings tool and select “Update & Security”:

prep_settings

From this window check for any updates.  When the updates are done, select “Advanced options” and then turn on “Pause Updates”.  This should prevent your laptop from doing system updates when you need it for driving.

prep_pause

 

New roboRIO image

Team update 14 requires that all roboRIOs use image FRC_roboRIO_2019_v14.  This image was in the latest FRC Update Suite, so you must use the roboRIO Imaging Tool to update your RIOs.  This update was released after Stop Build day, so every single robot will need to apply this image at their first competition.  After re-imaging, you must redeploy your robot code.

Wait… Before you re-image your roboRIO, make sure you have a copy of your robot source code.

If you do not have your source code, the CSAs may be able to make a copy of your current executable code.  The procedure for this is to connect directly to the roboRIO and retrieve relevant files from your /home/lvuser directory.  You can accomplish this with putty or WinScp.

If you are using TalonSRX or VictorSPX motor controllers controlled from the CAN bus, you install the native libraries.  Get a copy of the Phoenix Tuner and run “Install Phoenix Library/Diagnostics”.

Your codebase

You will also need to update your build.gradle file to work with the v14 RIO image.  Just change the GradleRIO version to “2019.4.1”.  The first few lines of your build.gradle file should look like this:

plugins {
    id "java"
    id "edu.wpi.first.GradleRIO" version "2019.4.1"
}

You are using GradeRIO and this year’s WPILib software for Java and C++ development, aren’t you?  It’s possible that one or more teams will show up to the competition with code written against last year’s development environment.  For those folks the CSAs (or some friendly teams) will help them covert it.  The procedure for this is to:

Programming at the competition

Gradle tries to make sure you have all the latest support code.  Once a day it will try to connect to central servers to see if you have the latest libraries cached.  This is fine if you always have an internet connection, but it can be a problem if you’re away from wifi.

The solution is to switch to “offline” mode while at a competition.

In Visual Studio Code, select the two options: “WPILib: Change Run Deploy/Debug Command in Offline Mode Setting” and “Change Run Commands Except Deploy/Debug in Offline Mode”.

prep_offline

Eclipse and IntelliJ have offline modes in their Gradle settings.  If you build from the command line, add the “–offline” argument.

Uncategorized

2019 Control Systems

Every year, FRC teams get updates to the hardware, robot library software, and support software.  FIRST and the folks at Worcester Polytechnic do a fine job publicizing the work, but you can never have too much documentation.  This site will publish tutorials and reports on the alpha, beta, and release control systems, including software, hardware, and networking.

Hopefully this will prove useful for FRC students, mentors, and volunteers everywhere.

Further Reading:

 

By the way, MnFirstCsa, the title of this site, is short for Minnesota FIRST, Control Systems Advisors.