docs: add Vision Sensors tutorial super-section

New `openmvcam/tutorial/vision/` walks the imaging stack from
optics to API: pinhole → lens → field of view → real-lens
effects; sensor grid → shutter types → exposure/gain →
calibration → data bus; Bayer CFA → debayering → ISP pipeline;
pixel formats; CSI basics → framebuffers → image preview →
sensor knobs; multi-sensor capture; memory pools; wrap up.

Also:
- Refresh hardware/wrap-up.rst to match the Python overview
  template (recap bullets, "Using this reference later",
  "Where to go from here").
- Delete obsolete script_structure.rst and system_architecture.rst
  (folded into the new vision section).
- Fix LCD shield backlight pin reference: P5 → P6.
- Enable sphinx.ext.mathjax so the math directives used in the
  optics pages render.
- CSS specificity fix for the homepage hero so the Shibuya
  section-margin defaults stop pushing the headline around.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: kwagyeman

docs/conf.py

@@ -284,6 +284,7 @@ def _render_landing_code(src):
     "sphinx.ext.autodoc",
     "sphinx.ext.doctest",
     "sphinx.ext.intersphinx",
+    "sphinx.ext.mathjax",
     "sphinx.ext.todo",
     "sphinx.ext.coverage",
     # Auto-generates /llms.txt + /llms-full.txt during the build so LLMs

docs/openmvcam/shields/lcd-shield.rst

@@ -34,15 +34,15 @@ Pin reference
    "P0",        "SPI MOSI — data out to the LCD"
    "P2",        "SPI clock"
    "P3",        "SPI chip select"
-   "P5",        "Backlight control"
+   "P6",        "Backlight control"
    "P7",        "LCD reset"
    "P8",        "SPI command (data / command select)"
    "3.3V rail", "Powers the LCD"
    "GND rail",  "Common ground"
 
 .. note::
 
-   Cut the solder trace on the back of the shield to disconnect P5
+   Cut the solder trace on the back of the shield to disconnect P6
    from the backlight; the backlight is then permanently on.
 
 Usage
@@ -99,7 +99,7 @@ whenever it needs to update the level::
     csi0.pixformat(csi.RGB565)
     csi0.framesize((128, 160))
 
-    lcd = display.SPIDisplay(backlight=PWMBacklight("P5"))
+    lcd = display.SPIDisplay(backlight=PWMBacklight("P6"))
     lcd.backlight(50)  # 0–100
     clock = time.clock()
 

docs/openmvcam/tutorial/hardware/wrap-up.rst

@@ -1,38 +1,66 @@
 Wrap up
 =======
 
-The :mod:`machine` module is now a familiar surface. The
-camera can talk to the physical world along several paths:
-
-* **GPIO output and input.** Drive an LED, switch a transistor,
-  read a button -- the building blocks of every hardware
-  project. Pull resistors and debouncing make those reads
-  reliable.
-* **Analog signals.** Read a sensor or a potentiometer with
-  the ADC; produce a controlled voltage with PWM and an RC
-  filter when no DAC is available.
-* **PWM applications.** Dim an LED, vary the speed of a DC
-  motor through an H-bridge, position a servo. Same waveform,
-  different averagers (the eye, the motor's inductance) and
-  different framing (duty cycle vs absolute pulse width).
-* **Serial buses.** UART for asynchronous point-to-point
-  links; SPI for fast on-board peripherals with one CS per
-  device; I2C for slow multi-device sensor buses on just two
-  wires; CAN for robust multi-master field buses between
+You have walked through the parts of the :mod:`machine`
+module that come up the moment a script talks to the
+physical world:
+
+* **GPIO output and input** -- driving an LED or a
+  transistor, reading a button or a limit switch. The
+  building blocks every hardware project rests on, with pull
+  resistors and software debouncing for reads that have to
+  be reliable.
+
+* **Analog signals** -- reading a sensor, a potentiometer, or
+  any other continuously-varying voltage with the ADC; and,
+  when no DAC is available, producing a controlled voltage
+  with PWM and a low-pass RC filter.
+
+* **PWM applications** -- dimming an LED, varying the speed
+  of a DC motor through an H-bridge, positioning a servo.
+  One waveform, different physical averagers (the eye, the
+  motor's inductance) and different framings (duty cycle
+  versus absolute pulse width).
+
+* **Serial buses** -- :mod:`UART` for asynchronous
+  point-to-point links; :mod:`SPI` for fast on-board
+  peripherals with one chip-select per device; :mod:`I2C`
+  for slow multi-device sensor buses on just two wires;
+  :mod:`CAN` for robust multi-master field buses between
   modules.
-* **Production patterns.** A watchdog timer to recover from
-  hangs; sleep modes to stretch a battery; both essential the
-  first time a camera leaves the bench.
 
-That coverage is enough to build the "sense, plan, act" loop
-of an embedded device: read sensors over I2C / SPI / ADC,
-make decisions in Python, drive actuators through PWM / GPIO,
+* **Production patterns** -- a watchdog timer to recover
+  from hangs, sleep modes to stretch a battery. Both become
+  essential the first time a camera leaves the bench.
+
+That is enough to build the *sense -- plan -- act* loop of
+an embedded device: read sensors over I2C / SPI / ADC, make
+decisions in Python, drive actuators through PWM / GPIO,
 report status over UART / CAN, sleep between events.
 
-What is *not* in this section is the camera's other half --
-its imaging pipeline. That is the subject of the next
-super-section, which picks up where the :mod:`machine` module
-leaves off and shows how the same Python loop drives an
-image sensor, runs computer-vision algorithms over the frames,
-and feeds the results back into the same actuators and buses
-covered here.
+Using this reference later
+--------------------------
+
+Treat the hardware chapters as reference material, not a
+one-pass read. The :mod:`machine` module reference page
+lists every class and method in one place when the question
+is just "what is the exact name of this call". The
+per-chapter pages here are where to come back for the
+"which knob does what, and why" view that the reference
+material does not give on its own.
+
+Where to go from here
+---------------------
+
+**Vision sensors** is the next major topic. Where this
+section taught the generic peripherals -- Pin, ADC, PWM,
+UART, SPI, I2C, CAN -- that show up on almost any MCU, the
+next section teaches the camera's *defining* peripheral
+very deeply: the image sensor, and the long chain of
+optics, silicon, and signal processing between photons
+hitting glass and a buffer of pixels in RAM. The toolkit
+shifts to the :mod:`csi` and :mod:`image` modules, but
+everything you have learned about driving GPIOs, talking
+over I2C, and using PWM carries forward unchanged --
+strobes, triggers, and sensor shields all use the same
+buses you have just covered.

docs/openmvcam/tutorial/index.rst

@@ -18,8 +18,7 @@ The OpenMV Cam tutorial covers how to use your OpenMV Cam and its accessories.
 
    hardware/index.rst
 
-   script_structure.rst
-   system_architecture.rst
+   vision/index.rst
 
    numpy/index.rst