3D printed Data Slate props

For a long while I've been using old Nexus 9 tablets to act as 'cyberdecks' in our Cyberpunk LARP, but I was recently asked to dress them for a 40K themed one this summer.

The old 3D printed cases were getting long in the tooth and were clearly just unpainted poor quality 3D prints. So I started completely from scratch for this, only re-using my CAD model of what I needed to hold the tablet securely and operate the power and volume buttons on the side.

One of the major things I wanted to get away from was the obviously rectangular shape of the tablet screen. It's a common sci-fi trope for screens to be weird shapes and to emulate this I modelled a surround with truncated corners and cutouts for the cameras and speakers.

This looks great so long as the tablet is asleep, but once it wakes up the real shape of the screen is obvious. There's only so much I can do here and while I could have covered some of the usable area Android apps tend to quite rightly assume the whole screen is accessible.

On the old tablet holders I had added some old bag carrying straps, which are very practical but untidy looking so I added a very chonky carrying handle as part of the case.

This makes the whole thing physically large, which has the added advantage of making these hard to hide or just stuff in a bag. It's a not uncommon problem in LARP that acquisitive players will squirrel something away in their bag and it's never seen again unless they want to leverage it somehow. These were to have PDFs on them that were plot-relevant and we wanted that information very clearly available.

Annoyingly there's no open source 'kiosk mode' application for Android that I could find but to make sure the PDFs were visible whenever somebody woke the tablet I used the "Librera FD" viewer and the basic screen pinning functionality in Android to keep it maximised.

When asked to make these I wasn't sure how long the documents would be so I decided to add physical controls for paging through and searching documents. There's a scroll wheel, two buttons to page up and down plus a keyboard for text entry. This re-uses an X-Box 360 chatpad as making your own small keyboard keycaps that don't look terrible is very awkward and fiddly. There's also a piezo sounder to do keyboard/button bleeps.

This section is the part I'm least pleased with: the chatpad is too small and the buttons I ordered were too long to allow me to inset it like I did with the tablet section.

The design is ugly because I was rushing and I will most likely re-do this part before they are used again. I may even go as far as making a custom keyboard using tactile switches that fills more of the area.

These physical controls are driven by ESP32-S2 dev boards acting as USB OTG HID devices. I ran into a bit of a struggle with the code for this. Every time the tablet went to sleep, it would disconnect the USB devices and refuse to reconnect. I think this is related to this reported bug but was in a hurry to get this done so just made the ESP32-S2 restart whenever the tablet went to sleep. There is a little latency on waking it up but not a great deal. I would like to add more functionality to this setup, including my LoRa mesh network messaging stuff, so I need to overcome this problem. The 'cheat' would be to connect the ESP32 over BLE but given I have a direct physical connection to the tablet this sort of offends me and I'd need to swap to an ESP32-S3.

In the end though, this all worked out well, I got four of these made in different colours so they could be told apart and the paint weathering on the main body looks good. I didn't have time to weather the control sections so they just got some scratches but if I'm going to re-do them that's fine. I may also try to make some left handed variants and some without the big handle.

These will definitely be getting a load of use. Put Termux on them and they are almost 'real computers' and while the performance is poor in modern web applications we always curate what we let our players access. I've got a drawer full of Nexus 9s so printing and painting a few more of these over the next few months will get me a nice stash of usable props.

3D printing Lasertag lens units

For over a year I've been faffing with my own Lasertag PCB design but keep dropping the project when something else needs doing.

The PCB design seems OK but with a couple of poor decisions I'd fix were I to order more. The 'beta' software works so I fitted them in two of my own Lasertag weapons and one worked great but the other not so much. I think it's got two current limiting resistors because I didn't realise there was one in the existing lens unit already.

What I don't know was what the real potential of the board was with the component choices I'd made.

Having a board design sort of goes hand in hand with needing lens units to match and I want to do what Phil from UKLTA has done: design a re-usable 3D printed lens unit that can be included in larger things, or printed out to attach directly to conversions. This is especially true if I want to maybe make some 3D printed 40K themed weapons for our upcoming 40K LARP. 

I ordered some 25mm acrylic lenses a few weeks back and I've had a go at designing an adjustable 3D printed lens unit that uses them but what I really needed was a way to range test away from Lasertag events that didn't involve the Police being called on me. Being based in the UK this is a real concern. So last week I made up a 'gun on a stick' which looks nothing like a weapon apart from the attached sight.

Today I've done some testing at the Hackspace on the field and it's "good enough for The Grange" with no trouble hitting a target across the width field at ~140m.

Unfortunately this isn't really a good test as I arrived later than planned and the photos don't really show how much the light was going. I need to test again on a bright sunny day. Home is just a short walk from Wanstead Flats which is a huge area of common ground so I'll have to make a trip there when the sun is shining.

Good progress though.

eBike battery mount

Way back at EMFCamp I bought an eBike battery to use in a Rover. It came bare without a connector or mount. It took me a long time to get around to searching for a connector and ordered something from AliExpress.

When it arrived it was a disappointment. The connector was just about OK but the mount was rubbish and unusable.

Yesterday I finally got around to designing a 3D printed block to go on the supplied rail and hold the connector firmly in place, unlike the awful flimsy plastic pieces supplied.

I also had to drill the rail to make the locking mechanism work, but that came out OK.

Now I need to get on with the rest of the Rover.

GalactiNet GT420 terminal

Back in May I was part of a team running a short LARP in our High Frontier universe.

The game plot called for the existence of a prototype communication device through which 'second contact' with an advanced extra-terrestrial species was being attempted.

In practical terms the intention was there would be a short exchange of messages between the players and these extra-terrestrials while very human chaos raged around them.

We like to do things with 'practical effects' at High Frontier and avoid whispered messages from GMs and the led me to somewhat overcomplicate the prop involved. A lot of this was because we intended to have an multi-user in-game messaging system at our previous event and I flamed out trying to deliver it in time, resulting in a big disappointment.

So this game I very much wanted to make that happen even if the actual amount of messaging would be trivial.

Every player was provided with a personal printed RFID card and inserting the card into a reader in the external unit logged them in.

The physical prop was made in two large chunks: a 'terminal' and the actual 'communicator' itself. Making these physically imposing yet still portable props was deliberate as the players would be faced with carrying them while under fire or abandoning them.

The 'terminal' is an old laptop motherboard and screen carefully fitted into a medium sized flight case with 3D printed and painted fascia. The flight case was interestingly laid out with a padded compartment on one side and I retained that for storage of a compact keyboard, mouse, cables and the power supply enabling it all to be packed down for moving.

Building this took a fair amount of iteration and improvisation. The original laptop battery pack was beyond use so I built one out of new 18650 cells with double the original capacity to ensure it would last the entire game.

Making an aged laptop bearably usable is an increasing struggle and the Raspberry Pi desktop for x86 is my go-to for this. By removing the Office software before updating you can still squeeze it onto 8GB SSDs and so long as you don't want to use Chrome with super-bloated sites performance is as zippy as it can be.

All it needed to do was run PuTTY as like my previous work on off-grid multi-user messaging this was a 'microcontroller first' design, implemented on ESP32-S2.

I took my previous, frankly unmanageable, project for messaging and created a new back end for it this time based around the port of sqlite available for ESP32. My goals were far more modest than the original project in UI terms but the back end still has most of the features to now resurrect it in what I hope is an actually manageable fashion.

Inside the communicator itself is a custom PCB I made a small batch for as long term I want to develop and use this messaging system for future games. It uses the ubiquitous MRC522 RFID reader and has a GPS attached for getting an accurate time signal, which is necessary for the system to work. There's also a uSD socket for storage (although it could use LittleFS), a sounder and some indicator LEDs.

By the time I was actually coding things for the game I realised I'd made some omissions on the PCBs but broadly they worked.

While the players interacted using a retroterm UI on the physical terminal, GMs could connect over WiFi and use a hacked together web interface to view previous messages and send new ones.

I did start by writing a fully featured web interface but the framework I used meant the ESP32 began to run out of memory once there was a non-trivial number of things in the database. Moving things into PSRAM helped, but not enough realistically.

The sqlite cache also caused me grief as it would rapidly eat all the heap memory of the ESP32, despite nominally being able to manage that itself. Tweaking compile time constants helped but in the end I found I had to aggressively clear the cache using the sqlite API after every interaction. By this point I was very close to the game, stressed about the deadline again and as messy as this solution was it worked well.

Using GPS for time, even indoors, worked well in testing but was another cause of stress on the day even though we're nominally an outdoor LARP system.

A cold GPS start, metal roof on the building used and need for it to work quickly ended up with us having to leave the communicator outside the building on a long USB lead for it to work at all.

I will not wholly rely on GPS for time again and look to fit a dedicated RTC that is set then updated by the GPS only if necessary. Even outdoors the time signal seemed unreliable but it was impossible for me to troubleshoot at the game. This meant weird slow performance and trouble logging on that I simply hadn't seen in testing.

In the end though, messages were exchanged and this massively overcomplicated setup delivered even though it gave me and the rest of the game team huge amounts of stress.

What I need to do now is work on it in the in-between times so that the back end approaches plug and play for other applications and my 'microcontroller first' plan actually means it can be used across a range of lightweight devices.

There was a whole PC doing almost nothing in this setup that could have done the messaging instead but my plan is this 'backwards' approach would allow cheap ESP32-based props to interact with the system.

You can buy something that could in principle be turned into a pocket touchscreen communicator for <£10 and I plan to pick up a couple. It's just the tip of the iceberg of what you can do with little ESP32 based gadgets. Previously I was thinking to use M5Stack/M5Paper products as well.

The messaging back end I've christened backslang and is on GitHub but I would say it is very much an unfinished mess not fit for anybody else to use. Maybe I'll find time to fix this before our next event. I'd love other people to dive in to the repo and fix my naïve mistakes but it seems unlikely anybody will have the inclination and time.

Donut

Unusually, I've made a piece of costume for an upcoming game. This is the Star Wars Endor Trooper 'donut' helmet. It's not a 100% perfect piece of cosplay apparel but it works pretty well. I took a 3D printable model from Thingiverse, a surplus Austrian Army cold winter cap (which has suitable ear flaps), added a couple of big rubber washers for the earpieces with some 3D printed surrounds/caps and threw it together.

I don't often do 3D printed costume pieces (mostly because I hate sanding and painting 3D prints) but I'm really happy with how this came out.

Hoverboard motor powered rover: Part 6

Things seem to have slowed down with work on my rover as I keep disappearing on 'side quests' and one of those was to make a better controller for this and any other projects that need a remote controller.

So I cooked up a 3D printed design with some 3-axis sticks and as many buttons as I could manage on an ESP32. It's partly inspired by the 3D printed controllers James Bruton and Keegan Neave have made but ESP32 based.

With a screen I happened to have fitted and the encrypted 2-device ESP-Now library I'm working on being bidirectional (another side quest) it should be able to give lots of info on the rover while it's in use like battery voltage, location and so on.

This might be of use to others (although the design's quite specific to that screen) so I've made it available on GitHub and christened it Sticky.

Quick cyberdeck build: Part 3

Did I say quick build? I was obviously mistaken.

I have spent far, far too long messing about trying to get the 3D printed mounts for the trackball and keyboard, well mostly the keyboard, working to my satisfaction.

The keyboard has a kind of rounded kidney shape to it and I don't have the modelling skills to model it exactly so I've done a lot of tweak, print, repeat today.

Also, I did a little more messing with the Arduino library I wrote yesterday and submitted it for inclusion in the Library Manager.

Also, I seemed to kill the cheap clone Leonardo board I was testing with so had to dig out and solder up the headers on another. Obviously not before I wasted time wondering what was wrong. They're tough and 5V tolerant so no idea how I killed it.

Also I faffed with the idea of using a different Android phone than originally planned as it's much smaller but it only runs Android 6, which is frankly way too old and won't handle Termux.

Note to self: Do not get involved in trying to install LineageOS on the Moto G4+, it needs to stay working.

I'm gonna need a bigger bench

Ever since I got my cheap Ender-2 I've been a fan of Creality 3D printers. That got partnered with an Ender-3 when a cheap Black Friday deal appeared and I can almost treat this one like an appliance. So long as the removable bed plate is cleaned and degreased occasionally it just prints.

I know some people struggle with their Creality printers, build quality can be variable, but both mine have been excellent and an Ender-3 of some flavour is my default recommendation to somebody new to 3D printing.

This is not because they're the best, they're far from it, it's because they're adequate and cheap. If you find you're using an Ender-3 lots, great now start modding it or buy something better. If it gathers dust after the novelty wears off you've only wasted £150-200 or thereabouts.

My Ender-3 gets used lots and short of an Octoprint setup, webcam and lighting isn't actually functionally modified at all. I'm into practical structural prints that will probably get some refinishing, not beauty prints. The Ender-2 is mostly idle but I sometimes run both at the same time if I'm working hard on a project.

Now I've scored a used CR-10 Max, which is at the other end of the spectrum of Creality printers. It's their biggest at a build volume of 450x450x470 and on account of that, by far their most expensive model. The huge heated bed has its own PSU.

For a long time I've wanted the facility to print larger items and I've got some costume parts I had literally been wondering about how to create in the days running up to seeing this for sale. Now I need to up my 3D modelling skills to being able to produce armour pieces.

Recycling an old laptop into a Command Centre: Part 3

Having decided that Raspberry Pi Zeroes running the PiGFX bare metal kernel was the way forward with the small displays, I created some 3D printed 'backpacks' for the unit.

With the addition of some BNC to Phono adapters it works very nicely.

In order to talk to PiGFX you need to use the UART on the Pi Zeroes and I was going to homebrew something from cheap FTDI boards but then ordered some USB CDC boards from 8086.net. They're cheap and do the job perfectly and tidier than I'd have managed.

The 'backpack' mounts directly on the BNC socket and I think has come out quite tidily. In the very unlikely event somebody wants to do something similar, I've stuck the design on Thingiverse.

Anglepoise repair

I found this lamp dumped in the street a couple of weeks ago and picked it up because it looked good quality. The last couple of days I decided to make a little project of repairing it, as I later spotted it was a genuine Anglepoise 1228.

There were a whole bunch of things wrong with the business end, including damage to the shade, but I 3D printed a new brim for it, fixed the bulb holder and electrics and gave it a general tidy.

The main damage seemed to all stem from the bulb holder plastic being made brittle over time, perhaps with heat from an incandescent bulb. I know they're much less common nowadays but you do still see them in use. I have some stored I swap in when the strobing of LED or fluorescent bulbs causes a problem and I like the light they make.

All the parts of the bulb holder were there but the fixing points had crumbled or snapped. It could be held together but none of the screws had purchase any more. Careful use of epoxy glue allowed me to (quite permanently) get it into one solid piece again. I had to pull the socket terminals out and carefully feed the wires through from the rear then push the terminals back in as it could no longer be unscrewed to get the necessary access.

With this done, I looked at repairing the shade. It's really tough laminated plastic, white inside, coloured outside and I've no idea how somebody snapped a section of the rim. It feels like it would need a full adult weight standing on it to break. I considered trimming the rest of the brim but I know my limitations and it would never have been a neat job. So I designed a pair of rings with a lip that 'sandwich' the original rim and 3D printed them in a contrasting black. The odd coral pink colour of the shade wasn't to my taste so I gave it a little red paint and once dry epoxied the new rim in place.

Now it's all fixed up. I'm not short of lamps, but I hate waste and I'll find a place in my home for it as it's quite attractive.

Tasmota temperature sensors

I've been doing a little home automation with Home Assistant recently and this involved putting temperature sensors in every room. I started out with some ugly stripboard SHT11 based things but they were unreliable and inaccurate.

During a Banggood sale I managed to pick up some Wemos 'shields' with an SHT30 temperature/humidity sensor so I converted all my sensors over to these. Tidier but still a bare circuit board with power LEDs lighting the room at night.

I fiddled around in OpenSCAD and came up with a fairly decent 3D printed enclosure and now have eight sensors dotted around my house, including the shed. This design leaves the SHT30 sticking out in free air with a 'baffle' to separate it from the rest of the device. Even so the temperature readings are massively effected by heat soak from the ESP8266 and quite inefficient LDO on the board. I've now put this on Thingiverse.

To fix the heat soak you need to connect D0 to RST on the D1 mini with a short piece of wire and enable deep sleep so they draw (and waste) much less power. In Tasmota this needs two console commands...

TelePeriod 10

DeepSleepTime 300

...the 'TelePeriod' means it sends data 10s after connecting to WiFi and 'DeepSleepTime' means it sleeps until the next five minute interval on the clock. If you're copying this example don't issue the commands until you're happy with the Tasmota configuration. The short wake time makes it a pain to issue changes later.

Now they send decent sensor readings, reliably.

ESP32-CAM helmet camera, prototype 3

 

While working with the ESP32-CAM board I've realised that the AMS1117 LDO fitted to it is a bit of a problem due to a 1V dropout value. This means that if you power it from an 18650 cell it starts to brown out far sooner than needed.

Coincidentally somebody from the LARP community asked me to see if I can make a design that takes four AA batteries and I put this new version together. The 6V from the battery pack works much better than the single 18650 and means they can be swapped easily but sadly makes the camera really quite bulky. Nonetheless I've sent them the files so they can have a go at building some units.

Going forward I've seen that the LDL1117 LDO only has a 0.3-0.6v dropout and is pin compatible. I think carefully desoldering the AMS117 and replacing it with one of these would solve my brownout problems.

An alternative would be a small 'daughterboard' that connects to the headers and has a buck convertor. This would be the more elegant option, especially if I managed to include the power switch and lamp button onboard. I've still not found time to see if I can make an I2S microphone work with the board, but that could also go on a 'daughterboard' if it did.

ESP32-CAM helmet camera, prototype 2

 

I did a little more work on the design and added an external antenna, as it's a known fact the board works better with one.

Then I put quite a lot of effort into painting it up in a basic camouflage pattern. I am very pleased with how this worked out.

No other real changes to the project but it shows you can make something decent looking at a low cost.

Creality automatic spotlights

A while back I wired both my Creality 3D printers so that they are powered on and off through Octoprint. This is useful because I work two floors away from the printers and perhaps more importantly because it switches the printer off after a long print.

This has been working perfectly but I often have the light in my cellar switched off making the camera monitor pretty useless unless I go and switch the light on.

I figured it stood to reason that switching some lighting on with the printers was a good idea and I made up a couple of little spotlights attached to the printer frames and connected them to the same SSRs that switch the printer power.

The spotlights are made from some ceramic GU10 bulb holders I had, 20mm electrical conduit and some 3D printed parts I quickly knocked up in OpenSCAD. I knew from my work with making fittings for GU5.3 12v bulbs that heat from the bulb wouldn't be an issue with the printed parts, they barely get warm to the touch even after several hours.

I only did this yesterday but it's already meant I haven't been leaving the cellar light on as much while working on projects.

ESP32-CAM helmet camera, prototype 1

It's been a while since I've blogged. Back in March I was working very hard indeed on making props for our upcoming LARP. With the pandemic we suddenly had to postpone until some indeterminate time in the future.

This killed my enthusiasm for a bit and when I picked up projects again I needed a change.

Over the last couple of weeks I've been fiddling with the ESP32-CAM board again and turned the pile of components in the first photo into a working helmet camera prototype.

With the standard camera example code loaded it works really quite solidly and the battery life with a 18650 cell recovered from an old laptop battery pack seems good.

I started out with the selfie lens for aesthetic reasons but it does a good job of taking in a whole room as you move around, something the default lens these boards ship with doesn't do.

The tactile button on the side switches on the onboard 'flash' LED and there's an acrylic light pipe bringing the light out of the shadow of the lens. It's not a proper long throw torch but it just about manages to light a dark room so you can see and the camera will generate a very grainy picture with the gain up full.

Onboard charging is nice but currently getting the cell in/out in the field is impractically fiddly and the holder is stuck in with tape. The indicator LEDs on the TP4056 board are brought out on the side with another couple of light pipes and these work great. The idea is if these were issued on a multi-day game it would be the player responsibility to keep them charged and a USB charging socket makes that practical. For a short game they probably won't need charging.

Overall this has worked out really nicely and the design I've done in OpenSCAD is modular enough it's easy to swap out the rail mount and add something different. These could easily double as 'CCTV' cameras with a ball socket mount.

The design does need a little more work to make it easy to assemble but broadly it's there. I've also had it suggested that an external antenna would be acceptable, when I thought it would be too ugly. So I'll work on a version with that over the next few weeks, the boards have a uFL connector and it'll really help increase range.

I've got enough camera boards and recovered batteries in good condition to build a set for a whole team of 'marines' and a few static CCTV units. Doing this while keeping the cost down for 10+ units has been a major requirement of this project and I've definitely succeeded at that. The bill of materials using the recovered 18650s comes in at about £7 plus printer filament at the moment.

Ender 2 magnetic bed upgrade

I'm still down the prop mines so can't post much without spoilers, but as alluded to I've been doing a lot of  3D printing again recently. The Ender 2 is great but the bed material was getting nasty and it's always been a pain to get things off as it's not removable.

My Ender 3 has a basic removable, flexible bed which is so much nicer. You can't get Ender 2 removable beds easily but you can for the Ender 3, very cheaply. This is a magnetic one which avoids any clips and as I have a second I may upgrade the Ender 3.

I assumed the bed would cut down easily to go on the Ender 2. Which has a tiny bed compared to almost any modern printer. I popped the bed off the printer, which is dead easy, marked it out with some tape and it cut easily with a nice sharp craft knife.

You can see how small the Ender 2 bed is compared to the not huge Ender 3. I wandered a tiny bit with the craft knife despite running it against as steel edge, but once on the printer it's not a problem as you'd never deliberately print that close to the edge of the bed.

Just running off my first test print now but after some faff re-levelling the bed, which is tiresome on an Ender 2, things look very promising.

Update: The small surface area makes for quite weak attraction with the base. Tall prints, especially, seem to cause the bed to slip and kill the print. I've fixed this with a couple of clips. So I've still got a removable bed it's just not an instant off one. Which is not exactly a hardship.

Creality Ender spool holder upgrade

I've been using my 3D printers a lot recently and as is the case with pretty much any tool, heavy use shows up flaws.

The spool holder that ships with the Ender models is a simple large diameter plastic tube. Which kind of works but I've realised this has a couple of problems.


The standard spool holder simply doesn't hold the 0.5Kg reels I have, the diameter is too large. More importantly there's a lot of friction that means it pulls the filament tight and I think on a couple of occasions has caused it to snap. I tried adding some shiny tape but it didn't really help.

A long time back I made a freestanding spool holder for my old Ormerod and I was using that for the 0.5Kg reels but the filament snapping is very annoying on a long print as the Enders have no filament sensor.

To fix this I spent a little time today knocking up a similar arrangement to the standalone holder for the Enders that goes in place of the tube. It's some 3D printed parts, 608-RS bearings, M8 studding and nuts. Now the spool moves completely freely and filament falls off the spool nicely rather than being pulled tight.

Job done.

OctoPrint PSU control

I've been using my Creality printers with OctoPrint running on Raspberry Pis for a little while now and it's made them really seamless to drive. One last thing has been bugging me, I want the printers to switch off at the end of a long print. A very quick look online shows there's a plug-in for this so I ordered a couple of cheap SSRs and today spent a little while setting this up.


The plug-in can be configured with a GPIO pin it then uses to turn power on/off and I selected pin 8. This meant I could solder up a very simple straight three pin header with 5V, GND and pin 8 next to each other.

There is a tiny gotcha with this choice in that pin 8 is GPIO14 which is used for the serial console on the Pi by default. So you have to use raspi-config and disable both the console and serial hardware in the 'Interfacing options' menu.

With that done, it was simple to configure the pin in PSU control and check it would turn the SSR on/off. This worked immediately but I found that the action was 'inverted' and the plug-in has a convenient tick-box that fixes that.

To manage the printer power I took the existing IEC mains lead and carefully stripped the outer sheath, exposing the individual wires. That made it easy to break the live connection and have it switched by the SSR without having joins in the earth and neutral.

So this was safe to have floating around on my bench, I designed a 3D printable enclosure and have published it on Thingiverse. This enclosure will obviously work for any use of these little SSRs and I'm tempted to buy a few more to have in stock for future projects. The cable channel is the right diameter for typical IEC leads and grips it when you tighten the cover down.

Creality Ender 3 camera mount

I've been using my Ender 3 a lot and am very impressed with it. Teamed up with Octoprint it's just great. Better 3D printers are legion but this will do me for the foreseeable future.

Octoprint supports a USB webcam for remote print monitoring and I've been using one of my stash of old Xbox LiveCams for this.

However I got tired of having it gaffa taped to a jar nearby as I kept knocking it out of alignment. To stop this I made a little mount which works quite nicely, so I stuck it on Thingiverse.

All it needs is some double sided tape to hold it on the printer and a sticky pad for the camera. Should work with any old webcam with a flat base.

I started out designing something to fix with the bolts that secure the Y stepper motor but realised they're too short to use and have any meat to the print. This version fits reasonably snugly so the tape doesn't really take much load.

ESP32-CAM case, selfie lens and mount - part 1

Poundland (the major UK 'dollar store') had selfie lenses for 50p so I picked up a few to play with on my stash of ESP32-CAM modules.

I've 3D printed a mount that protects the board and lines up the lens perfectly with the existing camera. The lens is an interference fit, at least on my printer, and screws in firmly.

Initial testing seems positive as it really expands the field of view. It's never going to rival a GoPro but makes the module much more versatile. You can buy a wide angle cameras for the ESP32-CAM but typically you have to buy that separately, almost doubling the cost so this was a cheaper way to get similar effect.

It also gives it a 'big lens' look rather than the pinhole camera of the usual module. Which is the aesthetic I want.

I still need to design a back to the case but this should give me a robust housing for these things. Different backs could have different options including a battery holder and switch.

The flash LED is exposed close to the lens but this would work better with a bit of acrylic rod acting as a light pipe and make it possible to make the whole thing passably waterproof with some thought.

The nasty thing with the LED is it shares a pin with the SD card interface so if you access the card it flashes. This is a problem. I have no idea who would have thought that was a good idea, it's not like there aren't any free pins. Fine if you use the camera over the network but makes the flash useless in situations you want to write to SD and if it's battery powered will chew power. Just why?