Dredd 2012 Electronics 3D Model and Build


Just working on a few props to go with the Lawgiver. The Proximity mine is magnetic, and the gas grenade has a working pin that will throw the handle off when pulled. Not quite finished the gas grenade but here's the mine: https://www.thingiverse.com/thing:5473926

Here's a demo of the gas grenade in action:

Small update to share.

Chris and I were discussing the VR function for this project. It's such an awesome feature and one that we planned out from the very beginning. Of course, we all know how loud it can get when trooping, attending cons, etc. The voice recognition works pretty well but performs best under ideal conditions, low noise environments. So we wanted to add a feature that would allow the Judge to manually cycle the ammo mode.

A Judge can cycle the ammo mode by holding the trigger for 2 secs and releasing. On release, the ammo mode will cycle to the very next one. The ammo modes have assigned positions:
  1. Armor Piercing
  2. Incendiary
  3. Hotshot
  4. High Ex
  5. Stun
  6. Full Metal Jacket
  7. Rapid
No matter which ammo mode is selected, the manual function will cycle to the next one. A code update was pushed to Github earlier this week after we completed the testing. Download, recompile, and upload to the Arduino to get the new goodies!
Good Googly Moogly! You folks just keep rolling out the hits. I don't want to jinx it, but I dare say this will go down as one of if not THE perfect run(s) on the RPF. Seriously, thank you folks for working ALL of this.
Thanks for the shoutout Gee2!

It will soon be a year ago that Chris and I started talking about this project. I even have one of the LG resin casts from JOATRASH FX, and it's one of the nicest props I ever received from the RPF. I really wanted a functional version and so we got to work to see how far we could take it. It has been quite the journey but pretty satisfying so far. We'll share more as we make progress.
Finally done!

Videos coming soon, I have a lot more filming and editing to go but this is a huge milestone.

Here's the paint colors I used:

Base: Matte Black Primer
Underlayer: Tamiya Gun Metal
Primary: Tamiya Semi-Gloss Black
Top Coat: Satin

Base: Matte Black Primer
Primary: Tamiya Flat Black
Top Coat: Matte

Base: Matte Black Primer
Primary: Tamiya Semi-Gloss Black
Top Coat: Satin

Base: Matte Black Primer
Underlayer: Antique Brass (only bullets)
Primary: Brass
Primary: Copper (only rings)
Top Coat: Satin


Got a few messages asking for this so why not? Drop leg holster added to the download package. Just screws onto the universal drop leg platform you can buy for like 15 bucks on aliexpress or ebay using 3 M5 button screws and nuts.: https://www.thingiverse.com/thing:5199144 file is called Dredd 2012_HolsterDropLeg_V4 There's slots on there for a retention strap for cosplaying. Sorry the lawgiver looks like poo but all the good ones are in paint, I just screwed some early prototype parts together to give this a fit test.
This entire build is absolutely amazing! That the creators in this thread are doing it virtually for FREE is even more amazing! The shear amount of time that they have spent making each "part, perfect" is crazy! (In a good way!) It's been 9 years since DREDD came out, I wish they would make a "part 2" as even Karl Urban was pushing for it, but it seems like it isn't meant to be. (You would think with the comics movies doing so well they would consider it now?) Back then when Karl Urban was doing CONS still for DREDD and other projects a "prop maker" had made him a DREDD badge and had it framed and gave it to him during a meet and greet and he said, "This is fantastic! This is going in my office! I actually don't even have one!" (I know these are way more investment just in materials than a "custom DREDD" badge, but maybe you might want to have a "spare" ready to go if he shows up "locally"? You know he DOESN'T have anything like THIS in his office! Heck, he didn't have anything like this on the MOVIE SET! I would think he would sign anything you wanted with pics or whatever in "exchange"? Maybe "autographs" or things like that mean nothing to you, but I was just thinking about the "recognition" it'd mean to your work? I'm sure he's doing a bunch of them for The Boys. Which he really doesn't really have a single "prop" for...except maybe the C-word (The New Zealand vernacular not American one!) so something like this would rightly amaze him!

An absolute heartfelt thank you all for the amount of time and effort you all have put into this! It is absolute "creator" perfection IMO!
Thanks for the message Madmax95 , really nice to know it's appreciated :)


The youtube video tutorials are in progress, there's a massive amount of work to do with filming and doing a run at the same time, here's a pic to show you I haven't forgotten:


At least doing so many for the run has gotten this to a fine science, this is quite the 'wax on, wax off'
Hi all, taking longer than I thought with the run but I did manage a pictorial guide I added to the end of the page here: GitHub - Props3D/dredd-lawgiver

This should be everything you need to get through a build, it's not perfect but at least complete. If you need any help or more pics post here and I'll keep adding to the guide to make it more user friendly as we go.
Sorry I've been quiet for so long but I thought I'd share an update on the coding and electronics side of the project. It's been pretty interesting project so far and lots of lessons learned. So here's a rundown of the latest changes and why they are important.

The original publication on Github was a working and functioning version of the Lawgiver with all of the same components we are still using. It worked, and worked very well. A lot of what I learned and some changes recently posted all stem with experimenting with different features of the Arduino microcontroller, working with a larger OLED, reading from the voice recognition circuit, and the functionality we wanted to replicate the Lawgiver we saw on screen. We wanted the features to feel polished.

As far as the microcontroller was concerned, we knew the Nano was best based on the space we were working with. We also knew we'd be pushing it with the number of components needed, and the number of pin outs we had to work with on the Nano. The basic approach with these small Arduino boards is that they run in a continuous loop, and in every loop you check for signals from inputs, and create output signals that make components do something like play a sound or turn on an LED. Immediately I figured that we would have trouble performing all the necessary operations in the main loop, which turned out to be true actually.

Originally, I started with using Interrupt Service Routines (ISR) for handling the trigger and reload inputs. The thought was that it could reduce time to read those signals because they needed to be debounce the signal inputs to prevent false positives and ensure the button is actually pressed. This processing takes time and multiple (read previous) cycles to determine. This approach proved to not work well at all. With a little investigation I concluded that the ISR does exactly the same thing that the main loop does but with no debouncing. Another downside is the way the ISR works, it basically stops (interrupts) the main loop while it's processing so you must be very quick, you don't want to spend a lot of time in the ISR routine otherwise the performance of the main loop suffers. Easy decision, rip it out and use the standard solution.

The first pass of the main code was to check all the input signals every time, and always write to the components that need it. This worked okay, but certain operations could be found lagging under different conditions. For example, checking the state of the fire trigger or ammo reload inputs would take multiple cycles to detect an action, or checking the voice recognition would have to make a serial communication on every cycle. These operations affect the timing of every other operation in the loop. Another huge consideration was both the LEDs and the OLED. Initiating an LED sequence which is timed and takes many cycles to complete. The OLED turns out to be the most costly operation of all the components having to write strings and draw shapes on the screen, and it has to redraw the entire screen every time. The BIG point here is both time and speed of the main loop are very critical.

So the main changes that really made a huge difference were to focus the main loop on only performing actions that were necessary and in the right order. First, the OLED display is only updated when something has changed like ammo fired or mode change, and it only happens after the other components have been initiated, namely the audio and LED sequence. This saved a ton of time. Next, it didn't make sense to always check the voice recognition module for inputs if another action had taken place since audio would be playing back which interferes with detecting a human voice. This seemingly made reading the VR module more reliable. But one final adjustment was necessary.

As I was putting in the strobing effect for the Rapid fire mode, the LED sequence would NOT execute properly. The initial flash would pause momentarily, just long enough to notice with the eye. I tried playing with different timings, using different sequence of commands but I couldn't get it to run properly. It was so vexing! This is where I really noticed the OLED operation causing a long enough delay to mess up the timing sequence on the LED strobe. In the end, I changed the OLED operation to wait for the LED sequence to complete before changing the display. It's subtle but it worked out beautifully. I'm still researching other options to actually speed up the write operations for the OLED which have lead to learning about a few ideas I can experiment with in the future, but I'm saving that for when I have more time to write some alternate implementations.

This has been a dream project for me. Chris Props3D and I have been working on it literally for over a year now but it's been so worth it. We certainly appreciate all the feedback and excitement from everyone here on the RPF!
Last edited:

Your message may be considered spam for the following reasons:

If you wish to reply despite these issues, check the box below before replying.
Be aware that malicious compliance may result in more severe penalties.