---
title: 'Fire SSD: Efficient Edge Object Detector'
url: https://www.emergentmind.com/topics/fire-ssd
type: topic
---

# Fire SSD: Efficient Edge Object Detector

Fire SSD is an efficient deep convolutional neural network object detector that adapts the Single Shot Detector (SSD) framework for edge and embedded devices with strict constraints on compute, memory, and power. It employs a modified SqueezeNet backbone with augmented "Wide Fire Modules" (WFM), dynamic residual detection branches (DRMD), and a systematic normalization and dropout strategy (NDM), achieving high mean average precision (mAP) under tight resource budgets on benchmarks such as Pascal VOC 2007 [1806.05363].

## 1. Architectural Foundations and Motivation

Fire SSD is designed explicitly for real-time object detection on resource-constrained platforms, where standard SSD architectures (most notably those using VGG16 backbones) are impractical due to their substantial memory, parameter, and multiply-accumulate (MAC) costs. For example, SSD300 with VGG16 demands 26.3M parameters (103 MB weights) and 31.38G MACs per frame, limiting deployment on low-power CPUs or edge accelerators [1806.05363].

Central to Fire SSD is the replacement of the VGG16 feature extractor with an enhanced variant of SqueezeNet, leveraging "Fire Modules"—blocks that combine a parameter-efficient squeeze layer (1×1 convolution) with parallel expand layers (1×1 and 3×3 convolutions). However, accuracy degradation in naive SqueezeNet-based SSDs motivates architectural enhancements to regain performance while maintaining compactness [1806.05363].

## 2. Wide Fire Module: High-Cardinality, Efficient Feature Extraction

The Wide Fire Module (WFM) generalizes the basic Fire Module by:

- Retaining the initial "squeeze" 1×1 convolution to project input channels to a compact intermediate representation.
- Replacing the 1×1 and 3×3 expand convolutions with group convolutions, inspired by ResNeXt and ShuffleNet, to increase feature cardinality and simultaneously reduce computational burden.

For input $X$ with $C_{\mathrm{in}}$ channels and $C_{\mathrm{out}}$ output channels, the WFM proceeds as follows:
- Squeeze: $\text{ReLU}(\mathrm{Conv}_{1\times1}(X, \text{out}=C_{\mathrm{out}}/4))$
- Expand-1×1: $\text{ReLU}(\mathrm{GroupConv}_{1\times1}(\cdot,~ \text{out}=C_{\mathrm{out}}/2,~ \text{groups}=g_1))$
- Expand-3×3: $\text{ReLU}(\mathrm{GroupConv}_{3\times3}(\cdot,~ \text{out}=C_{\mathrm{out}}/2,~ \text{groups}=g_3,~ \text{padding}=1))$
- Outputs from expand branches are concatenated along the channel axis.

In Fire SSD, the designers select $g_1 = 2$ (1×1) and $g_3 = 16$ (3×3), setting the number of filters per group to preserve representational balance ($C_{1 \times 1}K_{1 \times 1} \simeq C_{3 \times 3}K_{3 \times 3}$) [1806.05363].

## 3. Detection Branches: DRMD and Multi-Scale Heads

Standard SSD applies a shallow, two-conv head per detection scale, which is insufficient to capture small-object semantics. Fire SSD introduces Dynamic Residual Mbox Detection (DRMD), which deepens prediction branches:

- For the highest-resolution feature maps ($38 \times 38$ and $19 \times 19$), two stacked WFMs with a ResNet-style shortcut precede the box/classification predictors.
- For intermediate scales ($10 \times 10$, $5 \times 5$), a single WFM is inserted before detection.
- For the smallest scales ($3 \times 3$, $1 \times 1$), detection heads are applied directly.

Each branch predicts bounding box offsets and class confidences via parallel $3 \times 3$ convolutions, as in standard SSD [1806.05363].

## 4. Normalization & Dropout Module for Regularization

To manage gradient scaling disparities that arise from six detection branches of different spatial size, Fire SSD applies systematic normalization and regularization via the Normalization & Dropout Module (NDM):

- Batch normalization and dropout (dropout rate tuned per spatial size) are applied after every detection branch’s last convolutional feature map, followed by a ReLU activation.
- This method equalizes gradient magnitudes, injects stochastic feature-level regularization, and according to ablation analysis, yields a net mAP improvement of $+1.4$ [1806.05363].

Fire SSD replaces SSD's ad hoc $L_2$-norm (historically applied to $conv4\_3$) with this branch-specific normalization.

## 5. Layerwise Configuration and Network Summary

The Fire SSD feature extractor comprises a residual SqueezeNet front end (up through Fire8) and ten extra Wide Fire Modules cascading into a $1\times1$ convolution. This backbone produces six output feature maps of spatial sizes $38\times38$, $19\times19$, $10\times10$, $5\times5$, $3\times3$, $1\times1$, each used by multi-scale detection heads.

The appended layers are as follows:

| Layer      | Output Size | Stride | Channels |
|------------|-------------|--------|----------|
| Input      | $38\times38$| —      | 512      |
| Pool8      | $19\times19$|   2    | 512      |
| Fire9      | $19\times19$|   1    | 512      |
| ...        | ...         |  ...   | ...      |
| Fire16     | $3\times3$  |   1    | 512      |
| Conv17     | $1\times1$  |   1    | 512      |

Each detection branch comprises a selection of WFMs and $3 \times 3$ convolutions per mbox head (box and class), regularized by NDM [1806.05363].

## 6. Training Recipe and Performance Metrics

Fire SSD training employs the union of PASCAL VOC 2007 trainval and VOC 2012 trainval (20 classes), using standard SSD-style data augmentation: random cropping, flipping, color jitter, resizing to $300 \times 300$, and mean subtraction. The loss is a sum of smooth L1 for localization and softmax for classification, balanced 1:1.

The staged learning schedule is as follows:
- Stage 1: Freeze backbone, linearly warmup learning rate to 0.001, batch 64, 50K iter.
- Stage 2: Unfreeze, LR 0.01, batch 128, 50K iter.
- Stage 3: Batch 256, LR 0.01, 25K iter.
- Stage 4: LR 0.001, batch 256, 30K iter.

The final Fire SSD model comprises 7.13M parameters (28MB for FP32 weights) and requires 2.67G MACs per input, achieving $70.5$ mAP on VOC 2007. It attains $31.7$ FPS on a low-power quad-core Intel CPU (i7, OpenVINO), $39.8$ FPS (GPU, FP16), and $2.9$ FPS on a Myriad Neural Compute Stick VPU [1806.05363].

A summary table for contemporary compact detectors:

| Model             | Params (M) | MACs (G) | mAP  | FPS (CPU, OpenVINO) |
|-------------------|------------|----------|------|---------------------|
| Fire SSD          | 7.13       | 2.67     | 70.5 |       31.7          |
| SSD+SqueezeNet    | 5.5        | 1.18     | 64.3 |       80.0          |
| SSD+MobileNet     | 5.8        | 1.15     | 68.0 |       91.7          |
| Tiny YOLO v2      | 15.9       | 3.49     | 57.1 |       49.5          |
| SSD300 (VGG16)    | 26.3       | 31.38    | 77.2 |       5.2           |

## 7. Deployment and Edge Considerations

Fire SSD’s model footprint (7.13M weights $\approx$ 28MB in FP32) permits rapid transmission to endpoints or storage in sub-10MB eDRAM after quantization. Real-time performance is achieved on commodity CPUs—without custom ASICs, FPGAs, or discrete GPUs—and the model sustains >30 FPS on integrated GPUs using FP16. Group convolutions remain an optimization bottleneck in many inference libraries, suggesting further deploy-time acceleration as framework support matures [1806.05363].

Relative to SSD300, Fire SSD trades approximately 7 mAP for a $\sim$5$\times$ MAC reduction and 4$\times$ parameter reduction, a compromise considered beneficial under aggressive edge-computing power constraints.

## References

- "Fire SSD: Wide Fire Modules based Single Shot Detector on Edge Device" [1806.05363].

Source: https://www.emergentmind.com/topics/fire-ssd