Design/feasibility approach for camera project

This is a very rough feedback-gathering question. I have a project in mind, and it would require a fair bit of technical testing. If I may I’ll put down a written sketch - do please suggest ideas or steering that comes to mind. 🏆

Intro

I am a keen cyclist, and I ride on streets in a fairly bike-hostile city in the UK. I can easily have a serious near-miss every fortnight; it’s worse in the winter months. I’ve been clean knocked off by car drivers twice (one stopped to help, one fled the scene). So I have started riding with a helmet cam. I tried a cheap one, and it broke after a few months. I am then started using a GoPro hand-me-down. I melted this with a battery cable (don’t ask 🙈) so I bought another.

In my view, the broad design of standard-fare helmet cams is in need of improvement. Camera units are too expensive, and they are too easily grabbed and stolen by a road-rage driver or mugger. With rare exceptions, cameras only point one way (usually forward) even though cyclists can easily be impacted or attacked from behind. Nearly all cameras use an on-board battery, which provides around an hour of shooting time (this can be improved to around 1.5 hours by reducing resolution and frame-rate).

I carry several batteries, but in the wet and the cold, it is no fun fumbling around with a battery replacement operation, especially late at night. So while it is sensible to carry spares, continuity of power is a problem.

Proposal

I’d like to build a helmet cam that can do this:

  • 2/3/4 cameras pointing around the cyclist
  • Clips into a standard GoPro mount
  • On-board battery for short-term power
  • USB power lead going to a meaty powerbank in a jacket pocket
  • Tough and shake-proof (admittedly challenging with hobby electronics)
  • Eye-line or handlebar indicator for low battery/storage warnings

I’d also like to move the expensive bits off the helmet section, so that if the camera is grabbed by an assailant, only a small part of the system needs replacing. Moreover, I’d like to move storage to a separate box in a backpack, and maybe also into the cloud - so if everything is stolen, footage can still be accessed.

To this end, one of these designs might be appropriate:

  1. The helmet enclosure is just 2+ cameras with HMDI/power leads going to a storage unit, which goes in a pocket, backpack, or chest-strap enclosure
  2. The helmet enclosure is 2+ cameras with a USB power lead, local card storage, and data is streamed continuously to a backpack box via WiFi
  3. As per (2), but the data is streamed to the cloud via a 4G/5G dongle (may be problematic in poor signal areas)
  4. A mix of (2) and (3) - data is streamed from the helmet to a local box via WiFi, and from there to the cloud via the mobile network. But that may be over-complicating it.

Challenges

The issue with introducing WiFi is whether data can be streamed off the helmet unit at least as fast as it is written, with some headroom for noisy radio environments. My ancient GoPro produces around 200MB for a minute of 1920x1080x60fps footage (though that res is almost certainly overkill). This would require a sustained transmission of around 35 Mbit/s (comfortably within the ability of a 802.11n personal-area network).

With more than one camera of course this gets trickier - one would reduce the res/framerate of course, but now each camera needs its own WiFi transmitter (probably a Pi Zero W). On the receiver end (something like a M5Stack Core2 or M5Stack Tough) the write rate would be reduced due to the increased contention from several sender devices.

Most WiFi devices can be put in a hotspot mode, but one would have to check that was actually possible for the product being selected.

The night footage performance needs to be reasonably good. Most night cycling is going to feature some light, if only the light from cars and the bike lights. In a city environment there are more street lights, but a moving camera being subject to patches of light and dark can produce over- and under-exposed footage (reducing its usefulness). Some RPi cameras have IR lighting, but I am not sure the current draw for those devices would make them practical for this project.

Finally, home-made stuff tends to be fragile, but this system would need to be built like a marble toilet. It may be that reliability is only available with custom manufacturing parts (particularly for soldering and electrical connections).

a few thoughts
I know there are a few multi camera boards for pi, I’m sure there are a few for arduino as well, keywords:Multi Cam. but if memory serves they are all switched mode (meaning they operate one camera at a time)

similarly there are some fairly cheap camera for pi an arduino. I’d actually aim for 2x of those with wid angles, over more with narrower angles. and you’d definitely want ones that are either no-IR or can have the IR filter removed. they’re decent in twilight conditions, and can be enhanced in low light with IR LED’s but the range will drop considerably.

for pi (not sure about arduino) there are cable converters that let you use hdmi to connect from the camera module to the device. That would be more robust, allow separation of the camera(s) from the bits recording, and make them easier to manage.

for mounting and protection 3D printing would probably be optimal, but you can go as simple as chopping up a foam rubber mat and laminating pieces of it together with rubber cement and still get a decent looking shell. Weather and knock proofing should probably be your main goal here, if you go for fully sealed any kind of cheap cheap plastic (blister pack plastic is very optically clear) can work as a window, and you can stuff one or two of those desiccant packs inside to prevent moisture buildup from temp changes.

18650 lithium cells would be my go to for powering it (either one one of the larger “power packs”, or custom so you could add/swap cells separately, but they are a bit pricey)

for memory, I would think either very high speed class micro SD, or an M2 SSD housed in a USB adapter case.

building something like this myself I’d probably look at the something like a Pi 3B, or PI 4B 4gb+ (assuming you have one on hand, or you can manage to get one at retail price), along with the M2 SSD, a muti cam hat, those hdmi passthroughs I mentioned, and a couple of wide angle no-ir cameras… maybe some IR LEDs connected to the passthroughs power lines. I don’t own a 3D printer, but I do have a good amount of scrap wood, plastic, glue, and silicone caulking so you can imagine. I find softer materials to actually be more rugged at least until you get to hard metals, but they aren’t great for stability unless you add some internal reinforcement.

side note: for space saving I’d target a rolling window, if possible, something like 30 mins with an auto cutoff of 10mins after the last motion detected (not visual motion, needs a proper motion sensing breakout) with manual start/stop switches. I’m’ not sure how feasible the rolling window is to program on a pi, but the rest is easily doable. Auto off protects the rolling window, giving 20min prior, and 10min post, and manual start stop prevents accidental overwrites.

I’d also definitely target a lower frame rate / resolution… FHD/60fps looks nice, but it’s a hog and much more than is needed to ID a license plate, or model/make of a vehicle. half the frame rate halves the size of the file, for resolution I’d go with whatever is the default, down to half HD as long as there is no conversion (native resolution = smoother video overall thanks to less processing needed)

Brill, thanks @Nox. A few initial thoughts:

I agree with reducing the framerate - 60fps is overkill. I probably wonder if 30fps is too much as well, but I don’t know if the framerate is fully customisable, or there would be a preset number of resolutions with pre-specified framerates. I can look into that.

Moving data from a helmet device will be interesting. It is conceivable that camera data could be kicked straight into the WiFi pipe going to the backpack device, but that might have to throw frames away if the channel becomes congested. So writing to helmet-based card(s) probably would be safer. Now, one cannot read data as it is being written - instead the camera driver would be instructed to save data in 5 second bursts, and then files can be moved as long as they are no longer being written by the driver. (So the backback would always lag some X seconds behind the helmet).

A Pi 3 or 4 would be worth considering for the backpack device, but I fear it would be too chunky and cumbersome for the helmet (I do have a spare Pi 3). I was thinking of one Pi Zero per camera - they both have an SD card slot and the WiFi module I would need. (Of course if I could have just one Pi Zero looking after multiple cameras that would be great, but I expect it is not possible - each Zero only has one camera ribbon connector).

The Arduino would be the right size for the helmet - I have an old one but I didn’t enjoy programming it. I would be surprised if they were powerful enough, but I should think the new ones are much better. The Adafruit Feather devices look good too!

It’s funny you mention 3D printing - I was looking at exactly that theme last night. I have a friend who has one, so if I can get some feasibility testing done, I would look into that.

I am unfamiliar with the camera technologies - I will refer to your remarks about IR when I purchase. I can see me buying a few camera types to see what works best from a lighting and current draw perspective.

Aside: I wonder if I could take the output of four cameras, merge them into a single 2x2 image, and then record that? I wonder if it would not be possible to do that in real-time on a small device, and I should just focus on recording and transmitting. Ponder ponder… 🤔

I haven’t had great luck using zero’s for wifi video, but that was 1.3 before the wifi version so YMMV.

for cameras I was thinking something like this with an add on fisheye lens, or something like this (if you’re going full nighttime). and connectted out to one of these so all that ls on the helmet are the camera modules, and you can route a couple of cheap hdmi cables out… letting you push all the other hardware / power supply off the helmet at the cost of tethering.

for the full wifi experience something like this or this might work better than zero’s (and batteries) on the helmet, but it’s arduino, and has resolution / frame rate that might be below acceptable for your use case, and I’m not sure if these are IR filtered or not.

for the camera tech, fortunately resolution isn’t tightly tied to frame rate, mainly just a maximum for a given resolution. Fish eye lens are the keyword for ultawide viewing angle, usually ~160 degrees. they do add distortion though, whereas the standard pi cam is only ~60 degrees. “wide” angle lens tend to be near 90, but they’re pricier tend to be bulkier, but no distortion. The No-IR is literally just a camera module that does not have a little filter that removes infrared (red light from the bottom of human visible red to around what most old tv remotes used). It’s possible to remove from some, but it’s delicate work. it’s the last frequency of light to fade as it gets dark so good for cheap night vision.

it’s definitely possible to composite multiple image streams into one, technically that’s what a pi would be doing to display multiple streams at once… how, or whether that’s feasible for on-the fly recording, is well outside my limited experience

side thought, while the multi-cam boards I mentioned before tend to be swith mode, There might be a few add in boards that support simultaneous streams aimed at stereoscopic vision for robotics that might be repurposable to instead face different directions? I have no experience in those though.

Good thoughts, thanks again. 🏅

I’ve been doing some thinking on this theme. An umbilical cord for the helmet isn’t out of the question, and indeed I am using one with my GoPro already, just to supply power. But this just goes to a powerbank in the cycling jacket - I wonder whether linking it to a rucksack module, to do recording, might be a bit fiddlier in practice. Plugging in and out needs to be straightforward.

But my main concern is how HDMI leads could make the umbilical rigid and an encumbrance in practice; the cable extension you link to looks fairly stiff - two or more of those, plus a power line, is going to make for an awkward head-movement experience 😛

I haven’t had great luck using zero’s for wifi video

What issues did you run into? I agree that the Arduino modules you linked probably don’t have the resolution, which is why I’m leaning to the Zero for now - it has the 8M+ camera feature, small size, and WiFi capability.

there are much thinner hdmi cables, bonus they tend to be cheaper, the ones I’ve used before can get a comfortable 15mm radius bend in them, I’d link them but I got them from amazon years ago. still though, you’re correct that it is unlikely to find anything as flexible as most power leads.

for zero’s when I was trying, it was a signal strength vs bandwidth issue, lots of cut outs, even at close range. I’m sure having a separate module for the wifi didn’t help. I can’t say with certainty what the root problem was, might have been software even. Never went back and tried with the zero-w or zero-2 as it was a rush trail cam project for someone else and we just went a different way (local saves to a bigger pi)