Introduction
These specs detail all hardware, timing, and data requirements for advanced 360 cameras that offer high-speed, high-accuracy Street View capture and publishing capabilities. (Please note that this program does not apply to any operational or mechanical functions).
Recommended components: The accelerometer should satisfy the following specifications: The gyroscope should satisfy the following specifications: Recommended components Requirements Antenna design Physically small products, such as cameras that contain both the GPS receiver system and numerous complex electronic systems, are prone to problems with radio receiver performance caused by RF emissions from the included electronics systems. This interference is often in-band to the radio receiver and as such, cannot be filtered out. Given this, we have specified a set of tests to verify the device is working properly in the GPS Testing section below. The six degrees of freedom (6-DOF) transformation (relative position and orientation) between each sensor’s and each camera’s frame of reference (FOR) must be specified with respect to the accelerometer FOR. The sensor FOR must be as defined in the sensor’s data sheet and aligned with the sensor’s physical placement in the device. The FOR for each camera has the positive z-axis pointing away from the device into the FOV of the camera along the optical axis, the x-axis points to the right, the y-axis points down from top to bottom, and the origin of the FOR is at the camera’s optical center. The GPS FOR is located at the antenna. The 6-DOF transformation (3-DOF for position and 3-DOF for orientation) of each sensor or camera is represented as a 3x4 transformation matrix T = [R p], where R is the 3x3 rotation matrix representing the orientation of the sensor or camera FOR in the accelerometer FOR, and p is the 3x1 position vector (x, y, z) in meters representing the origin of the sensor or camera FOR in the accelerometer FOR. The requested transformations can be from a computer-aided design (CAD) model of the device and do not need to be device-specific to account for manufacturing variations. Power (either or both of the following models should be employed): Mechanical, Environmental All sensor measurements must be accurately timestamped with respect to the same stable system clock. The measurements must be timestamped when the sensor measured the quantity, not when the processor received the message from the sensor chip. The timestamp jitter between the different sensor readings should be <1 ms. All timestamps recorded in the same sensor data log must be continuous with no discontinuities. If the hardware reboots or resets and the system clock resets, then a new log must be created to store the new incoming data. GPS The GPS sensor should support an output of a time pulse and an associated message with the GPS time corresponding with the time pulse. This can be used to timestamp other GPS data packets with the same GPS epoch timestamp. The device should have an input to receive these time pulses, and when it receives a leading or trailing edge (whichever is appropriate), it should record the timestamp from the stable system clock. When the corresponding message packet is received that contains the GPS time, the device can now calculate the timestamp with respect to the stable system clock when it receives the navigation message from the GPS sensor, which contains the GPS time. Video / images The image sensor must support hardware timing to determine the precise time with respect to the stable system clock. In the event of dropped frames, subsequent frames must still reflect accurate timestamps. The timestamp must be with respect to the first active photon in the image. The manufacturer must specify which pixel this corresponds to. IMU The IMU (accelerometer and gyroscope) measurements must be timestamped with respect to when the measurement was taken, not when received. Street View optimized cameras and systems must collect multiple, per-sensor data measurements per second. The following details the data for each individual measurement. IMU data requirements IMU (accelerometer and gyroscope) measurement data: GPS data requirements Video requirements Video must be recorded at a frame rate of 5 Hz or greater. The camera should also record metadata associated with each image frame. For each image, You must also fill in the following user-data atoms in your MP4 360 video:
Imagery
IMU
GPS
Camera architecture
Camera configuration
Miscellaneous
Timing specifications
Data specifications
int64 time_accel; // The time in nanoseconds when the accelerometer
// measurement was taken. This is from the same stable
// system clock that is used to timestamp the GPS and
// image measurements.
// The accelerometer readings in meters/sec^2. The x, y, z refer to axes of
// the sensor.
float accel_x;
float accel_y;
float accel_z;
int64 time_gyro; // The time in nanoseconds when the gyroscope
// measurement was taken. This is from the same stable
// system clock that is used to timestamp the GPS and
// image measurements.
// The gyro readings in radians/sec. The x, y, z refer to axes of the sensor.
float gyro_x;
float gyro_y;
float gyro_z;
int64 time; // Time in nanoseconds, representing when the GPS
// measurement was taken, based on the same stable
// system clock that issues timestamps to the IMU
// and image measurements
double time_gps_epoch; // Seconds from GPS epoch when measurement was taken
int gps_fix_type; // The GPS fix type
// 0: no fix
// 2: 2D fix
// 3: 3D fix
double latitude; // Latitude in degrees
double longitude; // Longitude in degrees
float altitude; // Height above the WGS-84 ellipsoid in meters
float horizontal_accuracy; // Horizontal (lat/long) accuracy in meters
float vertical_accuracy; // Vertical (altitude) accuracy in meters
float velocity_east; // Velocity in the east direction represented in
// meters/second
float velocity_north; // Velocity in the north direction represented in
// meters/second
float velocity_up; // Velocity in the up direction represented in
// meters/second
float speed_accuracy; // Speed accuracy represented in meters/second
int64 time; // The time in nanoseconds when the image was taken.
// This is from the same stable system clock that is used to
// timestamp the IMU and GPS measurements.
// The corresponding frame in the video.
int32 frame_num;
You can verify your video with ffprobe command:
moov/udta/manu: Camera manufacturer (make) as a stringmoov/udta/modl: Camera model as a stringmoov/udta/meta/ilst/FIRM: Firmware version as a string
$ ffprobe your_video.mp4
...
Metadata:
make : my.camera.make
model : my.camera.model
firmware : v_1234.4321
...
GPS testing
It’s very easy to have performance limitations due to noise, antenna selection, antenna implementation, LNA, filter, and transmission line implementation. This section defines a test process to ensure that your final product (as a whole) meets the performance requirements needed to ensure accurate data output and qualify as Street View ready.
Qualification service
To simplify the testing of the devices, we have worked with Taoglas Antenna Solutions to provide a Google Street View Qualification GPS RF Service. Taoglas Antenna Solutions are leading experts in GPS technology with 5 Anechoic Test Chambers and all necessary equipment to perform the following tests. However, any comparable service provider can be engaged to perform the following tests.
Test setup
Testing must be done in a 3D anechoic chamber. This chamber shall conform to the range requirements and test site characteristics of the CTIA Over-the-Air Wireless Device Test Plan [1] sections 3 and 4 for the GPS L1/CA frequency, 1575.42 MHz except when in conflict with other requirements below.
The device shall provide a means to report NMEA GPS result strings [2] to an external computer for evaluation of the GPS status. This is required and testing is not possible otherwise.
The measurement/transmit antenna in the chamber shall be right-hand circular polarization (RHCP) with an axial ratio of 1 dB or better.
The GPS signal generator shall replicate one GPS satellite L1/CA signal.
Signal strengths mentioned in the following test processes are defined to have an accuracy of +/- 1 dB with an offset of 3 dB as measured at the device-under-test (DUT) position with a dipole centered on the measurement frequency. For example, when the test calls for -120 dBm, the chamber calibration shall show the measured power at the DUT location to be -117 dBm +/-1 dB. The 3 dB offset is to account for the calibration antenna being a linearly polarized dipole.
Test data points shall cover a hemisphere most representative of the device’s typical use-case. Manufacturers should try to maximize the coverage of the antenna to support a wide range of users’ usage.
Pass/fail determination
The following Acquisition and Tracking Conformance tests are required for a pass/fail determination. These tests are run only for the GPS L1/CA signal.
After values that do not change for a given sample of DUT—such as Data Point Dwell Time (DPDT) or Required Acquisition Signal Quality (RASQ)—are determined, these values can be re-used for a specific DUT sample in later tests to save test time as long as the DUT sample is not modified in any way.
Acquisition conformance test procedure
This is a single point offset test to provide a quick pass/fail answer. The DUT is positioned with the measurement perpendicular to the base plane of the measurement hemisphere, that is, at theta = 0° or zenith.
An incident signal equivalent to -120 dBm shall be presented and the DUT triggered to begin a cold start.
After the DUT has acquired the test signal, as seen by examining the GPGSV message [2], the test signal shall be turned off and the duration required for the GPGSV signal to reflect the loss of signal recorded. This duration, plus 3 seconds, shall be defined as the Data Point Dwell Time or DPDT.
The test signal power shall be set to the DUT’s conducted acquisition sensitivity level. When in doubt, use the level stated in the receiver datasheet. {The DUT shall be commanded to cold start, and after 45 seconds the GPGSV string is evaluated to determine if the receiver has acquired the test signal. If the signal is not acquired, the test signal shall be increased 1 dB.} The previous section in brackets {} shall be repeated until the test signal is acquired.
After the test signal level that allows the DUT to acquire is determined, the GPGSV string shall be evaluated over 10 seconds and the satellite signal quality value as reported by the DUT recorded. These 10 values are then averaged and defined as the Required Acquisition Signal Quality or RASQ.
The test signal strength shall then be set to -138dBm and the DUT allowed to acquire. The test signal strength is then held constant for the remainder of the test.
At each 15° increment over the selected hemisphere, the receiver shall be held stationary for the DPDT duration. At the end of this period, the GPS NMEA string GPGSV shall be examined. For the data point to pass, the satellite signal quality value as reported by the DUT must be equal or higher than the previously recorded RASQ value.
All data points must pass to pass the test.
Tracking conformance test procedure
This is a single point offset test to provide a quick pass/fail answer. The DUT is positioned with the measurement perpendicular to the base plane of the measurement hemisphere, that is, at theta = 0° (zenith).
An incident signal equivalent to -120 dBm shall be presented and the DUT triggered to begin a cold start.
After the DUT has acquired the test signal as seen by examining the GPGSV message [2], the test signal shall be turned off and the duration required for the GPGSV signal to reflect the loss of signal recorded. This duration plus 3 seconds shall be defined as the Data Point Dwell Time or DPDT.
The test signal shall be restored and the DUT allowed to acquire the satellite.
The incident test signal shall be lowered to -151 dBm.
At each 15° increment over the selected hemisphere, the receiver shall be held stationary for the DPDT duration. At the end of this period, the GPS NMEA string GPGSV shall be examined to determine if the test signal is still being seen by the receiver and the results recorded for that data point.
All data points must pass to pass the test.
References
[1] CTIA, "www.ctia.org," June 2016: http://www.ctia.org/initiatives/certification/certification-test-plans
[2] National Marine Electronics Association, "NMEA Standard 0183," 2008
Software implementation
Support for upload via the Street View Publish API is required. Please note that all requests to the API must be authenticated as described here.
For all imagery uploaded to Street View:
- imagery creation time (i.e. when the imagery was captured) must be specified.
- product’s make, model, and firmware version must be reported.
- motion stabilization must be turned off.
- raw GPS and IMU data must be shared (measurements must be accurately timestamped with respect to when the measurement was taken, not when received).
For all 360 videos uploaded to Street View:
- telemetry data must be communicated using Camera Motion Metadata Camera Motion Metadata.
- the photo sequence must be encoded with the correct frame rate at which the video was captured.
Please also include the following language and line within your application prior to the user publishing (at least the first time):
“This content will be public on Google Maps and may also appear in other Google products. You can learn more about the Maps User Contributed Content Policy here.”Exceptions
Exceptions may be granted for specific hardware and software solutions that do not match individual requirements but meet the overall end-to-end performance metrics stipulated in this document.
Product evaluation
If you are interested in, or have questions about getting your product evaluated, please contact us here. Note that access to methods and documentation for 360 video support in the Street View Publish API is currently (May 2018) by invitation only. Please use the form linked above to request access.
Our review is comprised of the following stages: your testing, our testing, beta user testing, and approval. In each stage, we will evaluate your product’s image quality, telemetry data, metadata, and workflow using the respective test data sets: data that you share, that we create, or that your beta users submit (please see below for example test set, subject to change).
- Still photos
- Five 360 photos, indoors
- Five 360 photos, outdoors (sunny, if possible)
- Five 360 photos, outdoors (shaded or overcast, if possible)
- In motion (approx. 30 mph or 45 kph)
- Five 60-minute videos (at 5fps) in a rural setting
- Five 60-minute videos (at 5fps) in a suburban setting
- Five 60-minute videos (at 5fps) in an urban setting
Your testing
As a first step, please share with us the Google Maps-published links to your test imagery, and please remember to test across a reasonable spectrum of devices and operating systems that your product supports as well as on various network conditions (e.g. home, office, outdoors).
Our testing
Following the successful completion of your testing, Google will commence their tests, in close communication with your team. To help us get started, please provide instructions for how to capture and/or upload imagery to Street View.
User testing
Once both your and our tests have been successfully completed, please engage at least 5 beta users for a testing period of 1-2 weeks to cover a minimum set of tests. If you need help connecting with testers, please let us know, as we may be able to put you in touch with interested users. Note that you will be responsible for coordination (including, but not limited to, logistics and support) with the testers.
Approval
Following positive results from testing, you will be requested to share your launch plan, including any Street View-specific support and promotional content (web-based or otherwise). We will review your materials and share our feedback promptly.
As you develop these materials, please remember to adhere to our branding guidelines.
Upon approval, you will be welcome to use our Street View ready badge and market your product as compatible with Street View, subject to the above guidelines. Please note, for each approved camera, we may feature your camera and/or surface imagery from your product in our marketing materials as representative of the camera’s capabilities.