Bosch MIC Problems

Bosch’s tilt convention isn’t quite ONVIF’s tilt convention

The first issue was that small tilt commands moved the camera by a different amount than I expected. I wrote a quick raw-ONVIF probe that sends AbsoluteMove(pan=0, tilt=89) and then checked the camera’s elevation, which was closer to 45° elevation. Not 89°.

A few more data points and a linear fit told the story:

The Bosch takes its actual 145° mechanical tilt range and stretches it across the full ONVIF range of ±180°. So ONVIF tilt is roughly 2.5× physical elevation. Nothing in the ONVIF spec requires this, but nothing forbids it either — SphericalPositionSpaceDegrees is allowed to advertise whatever YRange the device wants.

The fix was to add a two-point linear remap to the ONVIF backend:

CAMERA_ONVIF_TILT_PHYS_MIN=-55
CAMERA_ONVIF_TILT_PHYS_MAX=90

The backend translates physical elevation ⇄ raw ONVIF tilt on every read and write. The rest of the controller can keep speaking in elevation (0° = horizon, +90° = up) and not care.

Proportional speed is real, and it’s hidden in an AUX command

After all that, tracking should have worked. It mostly did, except the camera made small lurching motions at high zoom instead of smoothly following the plane. The PID’s commanded rate was around 0.2 deg/s — the camera was doing nothing for a while, then a 0.8 deg/s pulse, then nothing again.

It turns out PTZ cameras have a feature called Proportional Speed that auto-scales pan/tilt rate based on the current zoom level. At high zoom the camera moves much slower per unit of velocity input, so you can fine- tune the framing. For a human with a joystick this is great. For a PID loop trying to track a moving target, it means the gain changes by ~30× as you zoom in.

The MIC 7000i’s web UI doesn’t have a toggle for this. The setting is buried in a Bosch AUX command (AUX 88 ON/OFF) that you have to find by reading Bosch’s BICOM Absolute Positioning PDF. Once I knew the AUX number, the web UI’s Live > Aux section will send it.

The Bosch has exactly 15 speed buckets

With proportional speed off, tracking got better but still wasn’t smooth. I instrumented the rate scaler with a probe that sends a known velocity to the camera, waits, and measures how far it moved. The result was remarkable: the camera responds at only 15 distinct rates plus stop. That’s it. Send a commanded velocity of 0.3 deg/s, 0.7 deg/s, or 1.5 deg/s and the camera does exactly the same thing — bucket 1, about 0.77 deg/s. Anything in between is quantized away.

The BICOM doc confirmed this is the camera’s actual rate encoding: a 4-bit signed speed value per axis. 16 levels (15 + stop). Same on the wire, just hidden inside ONVIF’s normalized [-1, +1] velocity space.

This means the PID control has a step-function-shaped response, which is delightful for the integrator. The integrator winds up until it pushes the commanded velocity past bucket 1’s threshold, the camera lurches, then overshoots, then the integrator winds the other way. The control-loop plots looked like a square wave.

The four proportional speed modes are also buckets

There are four proportional speed modes (Super Slow / Slow / Medium / Fast) you cycle through via another AUX command (AUX 700). I wrote a sweep that walks through the four modes × three zoom levels, sends raw normalized velocities at evenly spaced points across the camera’s 0…1 input range, and fits the linear bucket model. At the tracking zoom of 0.95, the data came out:

So in Super Slow mode at 95% zoom, the PID can ask for a rate as small as 0.13°/s and the camera will actually do it. Eight times finer than the previous mode. The bucket structure still has a hard floor. The PID can ask for 0.05°/s of correction, but the camera will round that up to 0.13°/s. The controller is now stable, but at the high-zoom limit the image has visible micro-jitter because every correction is at least one bucket.