EECE 5554
Robotics Sensing and Navigation

Lecture 14: Sensing with Cameras:
Calibration, Mosaicing

Dr. Xian Li
Assistant Teaching Professor
Department of Electrical and Computer Engineering

Inspiration

Photos from a turning camera stitched into one panorama

Photos from a turning camera, stitched together

A roof camera drives one loop of a parking lot. Each image is placed on the map with its RTK pose.

2

Left image: OpenCV homography tutorial. Right: simulated, the course rig 1.7 m up

Today

Intrinsics and lens distortion
Zhang's method: calibrating with a flat target
Extrinsics and time
Mosaicing: panoramas and ground maps

3

Intrinsics: why the spec sheet is not enough

Part 1 of 4

If this is off	by this much	you get, 10 m away
Focal length f	1% (11 px)	depth off by 1%: 10 cm
Principal point c_x	10 px	every bearing off by 0.5°: 9 cm sideways
Lens distortion, ignored	0.5%, our “low distortion” lens	5 px at the image corners

A spec sheet gets you within a few percent. Stereo needs a quarter of a pixel (Lecture 13). Every robot camera needs calibrating.

4

Part one: intrinsics. From the spec sheet, our focal length is 5 millimeters over 4.5 micron pixels: 1111 pixels. The principal point should be the image center. Why not just use that?

Because real lenses and sensors are made with tolerances. If f is off by one percent, every depth from stereo is off by one percent: 10 centimeters at 10 meters.

If the principal point is off by 10 pixels, which is common because the sensor is never glued in exactly the center, every bearing is off by half a degree. That is 9 centimeters sideways at 10 meters.

And even our low distortion lens bends straight lines by up to half a percent. At the image corners, that is 5 pixels.

Compare that with the quarter pixel that stereo needs, from last time. The spec sheet gets you within a few percent. That is why every robot camera gets calibrated.

Lens distortion

x_d = x (1 + k₁r² + k₂r⁴ + k₃r⁶) + [2t₁xy + t₂(r² + 2x²)], and the same for y

x, y: normalized coordinates (pixels times K⁻¹); r: distance from the center. Radial terms k bend lines; tangential terms t come from a lens not quite parallel to the sensor.

In CameraInfo this is distortion_model: plumb_bob, and d = [k1, k2, t1, t2, k3]. Calibration finds them; image_proc removes them.

5

Read more: Camera Calibration (OpenCV). A real example

Wide lenses: the fisheye model

A ray at angle θ from the axis lands at distance r from the center:

pinhole: r = f tan θ

fisheye (equidistant): r = f θ

θ	30°	60°	80°	89°
tan θ	0.58	1.73	5.67	57.3
θ (rad)	0.52	1.05	1.40	1.55

r / f for each model

plumb_bob

The model above. Fine up to about 100° across. Our 72° lens and the C920 webcams use it.

rational_polynomial

8 coefficients, for stronger distortion near the edges.

equidistant (fisheye)

For 150° to 200° lenses. OpenCV has a cv.fisheye module for it.

6

Very wide lenses need a different model. In a pinhole, a ray at angle theta from the axis lands at f times tan theta from the center. A fisheye lens is built so that the distance grows with the angle itself: f times theta.

Look at the numbers. At 30 degrees the two models agree. But tan theta blows up near 90 degrees: at 89 degrees it is 57. A pinhole model would need an image wider than a parking lot. A fisheye stays at about one and a half. So no polynomial correction can save the pinhole model for a 180 degree lens.

In ROS 2 you pick the model by name. Plumb bob, from the last slide, is fine up to about 100 degrees across. Our 72 degree lens and the C920 webcams use it.

Rational polynomial has eight coefficients for stronger distortion. And equidistant is the fisheye model, for lenses from 150 to 200 degrees, with its own module in OpenCV.

Zhang's method: a flat target

Part 2 of 4

The board is a plane, Z = 0. So each photo of it is a homography, exactly as in Lecture 12:

H_i = λ K [ r₁ r₂ t ]_i

Find the corners (cv.findChessboardCorners, then cv.cornerSubPix to a tenth of a pixel), and the DLT gives one H for each view. The same K is inside all of them.

7

From homographies to K

r₁ and r₂ are columns of a rotation: at right angles, and the same length. With h₁, h₂ the columns of H and ω = K^−TK⁻¹:

h₁^T ω h₂ = 0

h₁^T ω h₁ = h₂^T ω h₂

Why tilt matters: if every view faces the camera straight on, the equations repeat each other, and f cannot be found.

1Stack the equations

ω is symmetric: 6 numbers. Each view gives 2 equations, so 3 or more views are needed.

2Solve V b = 0 with the SVD

The same trick as the DLT. Then K comes out of ω, and each view's R and t out of K⁻¹H.

3Refine everything

Nonlinear least squares on K, distortion, and every R and t, to make the reprojection error small: the regression lecture again.

8

Zhang, A Flexible New Technique for Camera Calibration, 2000 (free)

How do homographies give K? The first two columns of a rotation are at right angles and have the same length. Write that with the columns of H, and you get two equations in one unknown matrix, omega, which is K inverse transposed times K inverse.

Omega is symmetric, so it has six numbers. Each view gives two equations, so three views are the minimum. In practice we use twenty or more.

Stack all the equations as V times b equals zero, and solve with the SVD, exactly like the DLT. Then K comes out of omega, and each view's R and t come out of K inverse times H.

That closed form is only the starting guess. The last step refines everything at once, K, the distortion, and every view's R and t, by nonlinear least squares. It is the regression lecture again, with a camera model in place of a line.

One warning. If every photo faces the camera straight on, the two equations from each view say the same thing, and the focal length cannot be found. Tilt is not optional.

Judging a calibration: reprojection error

Push every board corner through the calibrated model, and measure how far it lands from where it was found:

RMS = √ mean ‖ x_found − x_model ‖²

Check (the bonus targets)	Target	Must pass
Intrinsics, each camera	0.3 px	0.5 px
Stereo calibration	0.5 px	0.8 px
Rectified rows line up	0.3 px	0.5 px

Small error is needed, not enough: 10 views all in the middle can fit well and still be wrong at the edges.

9

How do you know a calibration is good? Take every corner you found, push its board position through the calibrated camera model, and see where it lands. The distance between where you found it and where the model puts it is the reprojection error. The root mean square over all corners is the number every tool reports.

Here are the targets for the bonus, based on common practice in driving research: 0.3 pixels for each camera's intrinsics, with 0.5 as the must pass. A little more for the stereo pair, and 0.3 pixels for how well the rectified rows line up.

But a small error is necessary, not sufficient. If all ten of your photos have the board in the middle of the image, the model can fit those corners well and still be wrong at the edges, where the distortion is largest. Coverage matters as much as the number.

Try it: calibrate a virtual camera

Photos of the board

Views Tilt Corner noise

A virtual camera whose true K differs from the spec sheet, as real ones do. Board: 8 × 6 corners, 108 mm squares, 1.2 to 3 m away. Closed form only, no distortion.

Python demo and notebook

10

Try it. Here is a virtual camera whose true K is a little different from the spec sheet, as real cameras are. Each color on the image is one photo of the board. The table compares the spec sheet, the truth, and what Zhang's method finds.

With twelve views tilted up to 30 degrees and a third of a pixel of corner noise, the answer lands within a few pixels of the truth. Notice that it finds the principal point the spec sheet got wrong.

Now drag the tilt down to 5 degrees. Look at the reprojection error: still under half a pixel, it looks fine. But f is now off by about 25 pixels. That is the warning from the reprojection slide, live. At zero tilt it cannot be found at all: flat views repeat the same equations. Then try three views with two pixels of noise, and see how much more data helps. This demo stops at the closed form. The real tool then refines everything with least squares, and models the distortion too.

Good practice for calibration images

Cover the image

Corners in every part of the frame, most of all the corners of the image, where distortion is largest.

Tilt it

Up to about 45°, left and right, up and down. Flat-on views add little.

Near and far

Across the distances you will use. 20 to 40 good views.

Lock the lens

Focus and zoom fixed, taped or set-screwed. Refocusing changes K.

Flat and rigid target

A print on foam board bends. Measure the squares with calipers.

Sharp images

Hold still, and use even light. Blur and glare move the corners.

The ROS calibrator shows four bars, X, Y, Size, and Skew: move the board until all four are full. A ChArUco board (a checkerboard with markers) still works when part of it is out of view.

11

So here is how to take good calibration images. First, three rules about where the board goes.

Cover the whole image, especially its corners, where distortion is largest. Tilt the board up to about 45 degrees in every direction. And use distances near and far, across the range you will use. Twenty to forty good views is plenty.

Then three rules about the setup. Lock the lens. Tape the focus ring. If you refocus after calibrating, K changes and you start over.

Use a flat, rigid target. A paper print on foam board bends, and the method assumes a perfect plane. Measure the squares with calipers, because printers scale. And keep images sharp: hold still, and use even light.

The ROS calibrator helps you with coverage. It shows four bars, X, Y, size, and skew, and you keep moving the board until all four are full. A ChArUco board, a checkerboard with markers in the white squares, still works when part of it is out of view.

Calibrating in ROS 2: camera_calibration

calibrate (ROS 2 Jazzy)

# one camera: the classroom webcam
ros2 run v4l2_camera v4l2_camera_node
ros2 run camera_calibration cameracalibrator \
    --size 9x6 --square 0.025 --no-service-check \
    --ros-args -r image:=/image_raw

# the stereo pair on the Mustang: large board,
# 8 x 6 inner corners, 108 mm squares
ros2 run camera_calibration cameracalibrator \
    --size 8x6 --square 0.108 --no-service-check \
    --ros-args -r left:=/stereo/left/image_raw \
    -r right:=/stereo/right/image_raw

--size counts inner corners, not squares: an 8 × 6 board has 9 × 7 squares.
CALIBRATE when the bars are full. Read the error it prints.
SAVE writes /tmp/calibrationdata.tar.gz: the images and a YAML file per camera.
The driver loads that YAML from its camera_info_url, and publishes it as CameraInfo with every image.

12

In ROS 2, the camera calibration package does all of this with a window you can see. For one camera, start the driver, then the calibrator. Tell it the board: its size and its square in meters. Then remap its image topic to your camera's.

One catch: size counts the inner corners, not the squares. An eight by six board has nine by seven squares. Getting this wrong is the most common reason the calibrator never sees the board.

Move the board until the bars are full, then press calibrate, and read the error it prints.

Save writes a file in slash tmp, with the images it used and a YAML file for each camera. Keep the images: you can rerun the calibration later without the board.

The driver loads that YAML file from its camera info URL parameter, and publishes it as CameraInfo next to every image. That closes the loop with Lecture 12: Team B writes the file, Team C loads it.

In the classroom: calibrate a webcam

1Start it

Webcam driver, then the calibrator, with your board's size and square.

2Fill the bars

One person moves the board, one watches the bars and the coverage.

3Calibrate and save

Write down the RMS error, the number of views, and f_x, c_x, c_y.

4Compare

Post your numbers on the board. Same webcam model: how close are the K's?

Then make it worse on purpose: calibrate again with only flat-on views in the middle. The error may look fine. Is K the same?

13

Break Time

5 Minutes

Extrinsics: every transform the rig needs

Part 3 of 4

Frame (shared names)	Parent	From
roof_bar	base_link	Team A CAD, tape check
stereo_left_optical_frame	roof_bar	CAD, then calibration
stereo_right_optical_frame	roof_bar	stereo calibration
gnss_antenna	roof_bar	CAD, tape check

Each row is one R and t. Together they let every pixel and every RTK fix be said in base_link.

15

Stereo extrinsics: left to right

With both K's known, photos of the board seen by both cameras at once give R and T from the left camera to the right (cv.stereoCalibrate). Check them:

|T| matches the bar: 0.500 m in CAD, to a millimeter or two.
R is close to identity: the cameras are nearly parallel.
After rectification, matches share a row to 0.3 px.

Bumps

A pothole, or a hand on the bar, can move a camera a fraction of a degree.

Refocusing

Changes K, and so the rectification.

Heat

Sun on a dark roof bends the bar and softens plastic.

Remounting

Every time the rig comes off, check again.

The quick check after any of these: match features in a rectified pair and look at their row difference. Over 0.5 px, recalibrate.

16

For the stereo pair we also need R and T from the left camera to the right. Fix both K's first, then take photos where both cameras see the board at the same moment. Stereo calibrate finds R and T.

Check the answer against what you know. The length of T should match the bar, half a meter in the CAD, to a millimeter or two. R should be close to the identity, because the cameras point nearly the same way. And after rectification, matches should share a row to a third of a pixel.

Then know what breaks it. Bumps, from a pothole or a hand on the bar. Refocusing. Heat: sun on a dark roof can bend a bar and soften plastic. And remounting the rig.

So keep one quick check: match some features in a rectified pair, and look at their row difference. If it is over half a pixel, recalibrate before you trust new data.

Camera to vehicle, and the lever arm

1CAD

Team A's model gives every position and angle on the bar.

2Measure

Tape and laser meter from the rear axle center, with a plumb line to the floor and a level on the bar.

3Check with a target

Put a target on the floor at a measured spot ahead. Does the camera put it there?

A small pitch error moves the ground a lot (camera 1.7 m up)

Pitch error	5 m ahead	10 m ahead	20 m ahead
0.2° (target)	6 cm	21 cm	83 cm
0.5°	14 cm	53 cm	2.1 m

Targets: camera to base_link within 1 cm and 0.2°; antenna within 1 cm.

RTK measures the antenna, not base_link. The lever arm between them is a fixed vector in the car, so its direction on the map turns with the car.

17

The camera to vehicle transform comes in three steps. First, CAD: Team A's model gives every position and angle.

Second, measure. Use a tape and a laser meter from the center of the rear axle, a plumb line down to the floor, and a level on the bar.

Third, check with a target. Put a target on the floor at a measured spot in front of the car, and see whether the camera puts it there.

Why so careful? Look at the angles. A camera 1.7 meters up, pitched just 0.2 degrees wrong, puts a point 10 meters ahead 21 centimeters off. At half a degree, it is half a meter. Ground distance is the weak direction we saw in Lecture 12, and a small angle stretches it.

Our targets are one centimeter and 0.2 degrees for the cameras, and one centimeter for the antenna. And remember that RTK measures the antenna, not base link. The vector between them is fixed in the car, so on the map it turns as the car turns. Forget it, and a forward pass and a return pass disagree by twice its length.

Publishing the transforms

quick test

# one static transform from the command line
ros2 run tf2_ros static_transform_publisher \
    --x X_BAR --y 0.0 --z Z_BAR \
    --frame-id base_link --child-frame-id roof_bar

# check the tree
ros2 run tf2_tools view_frames
ros2 run tf2_ros tf2_echo base_link gnss_antenna

stereo_rig.urdf.xacro (excerpt)

<joint name="bar_to_left" type="fixed">
  <parent link="roof_bar"/>
  <child link="stereo_left"/>
  <origin xyz="${xl} ${yl} ${zl}" rpy="0 ${pitch} 0"/>
</joint>
<!-- body (x forward, z up) to optical
     (z forward, x right, y down) -->
<joint name="left_to_optical" type="fixed">
  <parent link="stereo_left"/>
  <child link="stereo_left_optical_frame"/>
  <origin xyz="0 0 0" rpy="${-pi/2} 0 ${-pi/2}"/>
</joint>

For the rig, use a URDF: robot_state_publisher publishes all of it, and the numbers live in one file, next to the transforms table. The body to optical turn is the Lecture 12 rotation.

18

Time: when was each image taken?

Speed	10 ms off	50 ms off
2 m/s (walking pace in the lot)	2 cm	10 cm
10 m/s (36 km/h)	10 cm	50 cm

Position error = speed × time offset. RTK is good to about 2 cm.

Two clocks to line up: left with right (one trigger, Lecture 13), and camera with GNSS.

Where offsets come from

Stamping an image when it arrives, not when it was exposed. USB transfer, driver queues, and GNSS message delay.

How to shrink them

Stamp at exposure (the camera's own timestamp). Keep the laptop clock synced to GNSS time.

How to measure what is left

Drive slowly past a line on the ground, both ways. Camera and RTK should place it in the same spot.

19

Now time. If the image is stamped 50 milliseconds late, the map uses where the car was 50 milliseconds later. At walking pace in the lot, that is 10 centimeters. At 36 kilometers an hour, half a meter. RTK itself is good to 2 centimeters, so the clock can easily be the biggest error.

There are two clocks to line up. Left with right, which the shared trigger from Lecture 13 takes care of. And camera with GNSS, which is today's problem.

Offsets come from stamping an image when it arrives on the laptop rather than when it was exposed: USB transfer, driver queues, and the delay of the GNSS messages.

To shrink them, stamp at exposure, using the camera's own timestamp, and keep the laptop clock synced to GNSS time.

Then measure what is left. Drive slowly past a line on the ground, once in each direction. A time offset shifts the line forward on one pass and backward on the other. Half the gap, divided by the speed, is your offset.

Mosaicing: panoramas

Part 4 of 4

Why it works

A camera that only turns gives H = K R K⁻¹ for any scene (Lecture 12). Lectures 12 and 13 give every step.

Wide panoramas

Past about 120° a flat canvas stretches too much, so stitchers warp onto a cylinder or a sphere instead.

20

Read more: High level stitching API (OpenCV). A stitched example

Blending, seams, and ghosts

Feathering

Weight each image less toward its edges, so overlaps fade from one to the next.

Seams

Cut between images where they agree, not through a car or a face.

Exposure

Match the brightness of neighbors first, or the sky shows stripes.

Ghosts

A camera that moves, not just turns, sees near things shift: they show up twice.

Our car moves, so a roof camera is not a panorama camera. For the ground we need something else: the plane, and RTK.

21

A ground mosaic with RTK

p_map = p_base(t) + R(ψ(t)) · p_{ground, in base_link}

Where heading comes from

One antenna gives position, not heading. Take heading from the track (successive fixes, while moving), or from the IMU as in Lab 4.

Why it can be sharp

Ground points are exact under the homography, and RTK is good to 2 cm. Everything else is calibration and time.

22

Here is the ground mosaic pipeline. Take an image at time t, rectified with today's calibration.

Turn it into a bird's eye view with the ground homography from Lecture 12, built from K and the camera's pitch and height. Now each pixel is a ground point in base link, in meters.

Look up the car's pose at the same time t: the RTK fix from Lab 2, the heading, and the lever arm from the antenna to base link.

Turn and shift every ground point into the map with that pose, and blend it into a grid, say 5 centimeters per pixel. In one line: the point on the map is the base position, plus the heading rotation times the point in base link.

One catch: a single antenna gives position, not heading. Take the heading from the track, the direction between successive fixes while the car is moving, or from the IMU, as in Lab 4.

Why can this be sharp? Ground points are exact under the homography, and RTK is good to 2 centimeters. So whatever blur you see comes from calibration and timing. That makes the mosaic a very good test of the whole rig.

Where the map errors come from

Source	Example	A point 10 m ahead moves
RTK position	fixed solution	about 2 cm
Heading	0.5° off	about 10 cm sideways
Camera pitch	0.2° off, or the car braking	about 21 cm along the road
Time offset	50 ms at 4 m/s	20 cm along the track
Lever arm forgotten	antenna 1 m ahead of base_link	1 m, and the other way on the return pass
Not flat ground	curbs, ramps, parked cars	smeared, as in Lecture 12

Errors in one direction shift the map. Errors that flip with the driving direction double the lines. Look for doubles.

23

Here is the error budget for a point 10 meters ahead. RTK itself contributes about 2 centimeters. That is the floor.

Half a degree of heading error swings the point about 10 centimeters sideways.

Two tenths of a degree of camera pitch, from calibration or from the car nosing down when it brakes, moves it 21 centimeters along the road.

A 50 millisecond time offset at 4 meters a second moves it 20 centimeters along the track.

Forgetting the lever arm is the big one: a whole meter, and the other way on the return pass.

And anything that is not flat ground smears, as we saw in Lecture 12.

Here is the diagnostic trick. An error that stays the same in every direction just shifts the whole map. An error that flips with the driving direction makes the lines double where passes overlap. So look for doubles. Let's see them.

Try it: a map from a driving car

Errors

Heading Time offset Pitch

Drive

Speed

Python demo and notebook

24

Calibration day plan (M4)

#	Step	What to do	Pass when	Who
1	Mount the rig	Bolts checked, pull test by hand, cables clear of the doors	nothing moves when tapped	A
2	Intrinsics check	Load the classroom YAML files, take a few new views	< 0.5 px	B
3	Stereo calibration	Large board, near and far, both cameras on one trigger	< 0.8 px; rows < 0.5 px	B
4	Depth test	Targets at 3, 5, 10, 15 m in the garage, against a tape measure	within 2× theory	B, C
5	Vehicle and lever arm	CAD, then tape and plumb line, then a floor target	2 cm, 0.5°	A, B
6	Record	Bags with images, camera_info, TF, and GNSS, under open sky	verify script passes	C

The garage blocks the satellites, so RTK will not fix inside. Steps 1 to 5 happen in the garage of the 225 building; the lever arm check with RTK and the mosaic drive need open sky at [[ OPEN-SKY SPOT ]].

25

Here is the plan for calibration day on the Mustang, milestone M4. Six steps, in this order, each with a pass test. One: Team A mounts the rig, checks every bolt, pulls on it by hand, and keeps cables clear of the doors.

Two: Team B loads the YAML files from the classroom and checks them with a few new views. Three: the stereo calibration, with the large board, near and far, while both cameras run on one trigger.

Four: the depth test, with targets at 3, 5, 10, and 15 meters against a tape measure, compared with Lecture 13's table. Five: the vehicle transforms and the lever arm: CAD, then tape and plumb line, then a target on the floor.

Six: Team C records bags with everything: images, camera info, TF, and GNSS. The verify script has to pass.

One practical note. The garage of the 225 building blocks the satellites, so RTK will not get a fix inside. Steps one to five happen in the garage. The lever arm check with RTK, and the drive for the mosaic, need open sky.

Bonus: from the bench to the car

Team A: Mount

M3: printed parts fit the bar
CAD numbers into the transforms table: the starting point for every transform

Team B: Calibration

M3: intrinsics done in the classroom, YAML files in the repo
M4: run today's procedure on the mounted rig

Team C: ROS 2

M3: one launch file runs both cameras on a laptop
M4: load the YAML files, publish the TF tree from the URDF, record

The bags from M4 become the M5 showcase: live stereo depth, and a ground mosaic placed with RTK.

26

Readings (free)

OpenCV: Camera Calibration and the stitching API
ROS 2 Jazzy: camera_calibration, with the stereo calibration tutorial
Zhengyou Zhang, A Flexible New Technique for Camera Calibration, the original paper
Shree Nayar, First Principles of Computer Vision: the videos on camera calibration and image stitching. fpcv.cs.columbia.edu
Richard Szeliski, Computer Vision: Algorithms and Applications, 2nd ed.: Chapter 8 (alignment and stitching) and Section 11.1 (calibration). szeliski.org/Book
Robotics 101 interactive explainer: Homography and Image Mosaicking
The two demos and their notebooks on the course site: calib_zhang and ground_mosaic

27

Three takeaways

1Calibrate every camera, and judge it by more than one number. Zhang's method turns one homography per view into K and distortion. Tilt, coverage, and a flat target matter.

2Every transform needs a source and a check. CAD, then a measurement, then a target. Small angles become big errors on the ground.

3Mosaics show calibration and timing errors. Pose, lever arm, and time must all match, and doubled lines tell you which one is wrong.

28

Inspiration

Today

Intrinsics: why the spec sheet is not enough

Lens distortion

Wide lenses: the fisheye model

plumb_bob

rational_polynomial

equidistant (fisheye)

Zhang's method: a flat target

From homographies to K

1Stack the equations

2Solve V b = 0 with the SVD

3Refine everything

Judging a calibration: reprojection error

Try it: calibrate a virtual camera

Photos of the board

Good practice for calibration images

Cover the image

Tilt it

Near and far

Lock the lens

Flat and rigid target

Sharp images

Calibrating in ROS 2: camera_calibration

In the classroom: calibrate a webcam

1Start it

2Fill the bars

3Calibrate and save

4Compare

Extrinsics: every transform the rig needs

Stereo extrinsics: left to right

Bumps

Refocusing

Heat

Remounting

Camera to vehicle, and the lever arm

1CAD

2Measure

3Check with a target

Publishing the transforms

Time: when was each image taken?

Where offsets come from

How to shrink them

How to measure what is left

Mosaicing: panoramas

Why it works

Wide panoramas

Blending, seams, and ghosts

Feathering

Seams

Exposure

Ghosts

A ground mosaic with RTK

Where heading comes from

Why it can be sharp

Where the map errors come from

Try it: a map from a driving car

Errors

Drive

Calibration day plan (M4)

Bonus: from the bench to the car

Team A: Mount

Team B: Calibration

Team C: ROS 2

Readings (free)

Three takeaways

Next