Functional Pip-boy 3000 Mk IV from Fallout 4

Here is an idea.
There used to be a toy camcorder called the PXL2000. Used audio cassette tapes. Maybe get one to film a display…then loop that back to get a dirty, grainy combat feel.
 
Do you think it be possible to add the holotape games in the pip-boy? Do you think you will be able to sell holotapes separately to put your own music or videos in the holotape?
 
The game could be added, but would have to be re-written in Python. I have no plans for that.
The current plan is to have the holotapes will be able to hold data and transmit it, not sure yet how much bandwidth I will have.
 
This is awesome and I have been able to get everything running on my Pi! My only question is, if I am wanting to change to input functions from the keyboard to say a rotary encoder and/or a joystick and some buttons, what all would I need to adjust in the code to do so?
 
As I am still testing the GUI using a keyboard, I haven't started on the GPIO input. I am actually using my Radiation King Radio sub-project as a way to work out how that will work. The radiation king has Rotary Encoder, i2c ADC and i2C GPIOs inputs.

Alerting the code isn't straight forward, and you would do well to go watch a few primers on PyGame from YouTube as I am still learning it myself.

Basically PyGame has an event queue, and a set of actions that occur if a event occurs. Using an event queue is a way of having non-blocking code that just check if something happened and then reacts to that even later.

You need to code to check the input, and then post an event to the queue based on that input. And have an action handles that does something if that even pops up on the queue.

In the case of Volume Up:
In /pybboy/core.py there is "def handle_action(self, action):" and " def handle_event(self, event):" These same calls are found in other parts of the code depending on what is needed for a particular screen. In the case of core.py it handles the radio events that I want to work regardless of what screen you may be on. (Such as volume control)

Code:
elif event.key == pygame.K_PAGEUP:  # Volume up
                settings.radio.handle_radio_event(event)

This line basically watches for the event.key "pygame.K_PAGEUP", and then calls "/modules/radio/def handle_radio_event(self, event):"

Code:
if event.key == pygame.K_PAGEUP:
                if hasattr(self, 'active_station') and self.active_station:
                    self.active_station.volume_up()

One of the things I am trying to do is optimize the call code a bit to isn't reliant on so many sub-calls, but a certain amount of that is needed to allow for unique things to happen on screens such as as the map.

The code on GitHub is also still very much a work in progress.
If you look in the settings.py file you will find commented out:
Code:
# Using GPIO.BCM as mode
# GPIO 23 pin16 reboot
# GPIO 25 pin 22 blank screen do not use
GPIO_ACTIONS = {

This is some of the code that enables GPIO input on the Pi. But on my project I have no GPIO pins due to the screen so I have to use i2C input, which is part of the reason I am doing the Radiation King, as a prototype for the various input functions I need without working about the screen since it is just a radio.
 
So, nothing on the Pip-Boy, but I am about to post an update to the Radiation King Radio. A lot of the radio software and electronics that I put into the radio will go directly into the Pip-Boy. For example, I will definitely be using a RP2040 (Pi Pico or similar) alongside the Pi CM4 for all the analog.
 
Hey Zap. Not sure if you have seen this before:


It might be worth talking to the project creator to see if this tech can be applied to your project! It might end up being more compact than a traditional Geiger tube radiation detector.
 
I have not yet found a compact off the shelf crystal. Most of them are several inches in size.
I already have a working compact dosimeter, and the reality is that it is there for bragging rights, and not serious radiation detection.
 
Ahh, figures I comment that right before reading your thread on the dosimeter prop!

You've certainly earned those rights! What you've done in such a compact prop is nothing short of amazing. I've read that you are a product design engineer- as a fellow engineer do you have any tips for more complex form modeling in solid modeling programs? The integration of the mechanical components and more visual components is amazing.
 
A good CAD program really helps to let your idea loose. Since I switched to Solid Edge, not to be confused with Solid works (official title), I work much faster. I believe I have already sung its praises a few times in this 34 page, 7+ year project log.

The synchronous mode means I never worry about sketch constraints or the part history. In Solid Edge the sketches just become tools to use temporary, and the 3D CAD becomes the ground truth model. It also handle massive complex assemblies without bogging down too much.

As far as complex forms, it is much harder to do in history based CAD, as you can't tweak an earlier feature without possibly breaking a later one. For the most part I am just using sketches to make the profiles, and doing lots of cuts and adds to get the final shapes. For the Pip-Boy I did also have to use a lot more loft and surfacing operations to get the more organic shapes, and it probably is the most complex single part I have ever made.

When working on any product, I push as much into the CAD as I can. This allows me to get all the "how is this going part to work?" questions out of my head.

------------------------------

Radiation King, Motherboard.jpg


For example: Today I worked on the PCB design. I had an issue I needed to work out fully. The Pi Pico and the Pi Zero will talk over a USB connection. I could use a cable to connect the two, but why do that when they are both on the same PCB, and both have pogo-pin pads on the backside for the USB. But I had to find a pogo-pin that would work. The pads are just 1.5mm apart, and so I couldn't use any larger pogo pins. I mocked up various pogo pins I available on Digi-Key, but I ended up stacking a 1x2 1.27mm pitch pogo pin header, on top of another 1x2 socket to get the 10mm of height required. While doing that, I also selected all the headers for the rest of the board.

Also note that the motherboard design is all self-contained including the gauge. By using SMT stand-offs I can have everything needed for the joined to a single board, instead of having to be stacked inside radio. This should make any final tweaking easier.
 
I just found this thread, and started looking around for screens that would fit.

Based on your ideal display of 75x65mm active area with a MIPI interface, I was wondering if the AUO H381DLN01 would be a fit.
It has an active area of 67.6x78.95mm, a resolution of 1080x1200, with a MIPI interface, and I've seen prices around $40.00.
 
SpamTX

This issue is that the Raspberry foundation won't document their MIPI interface, reserving it for us only with their own LCD screens. And I can't write a low level LCD driver. The HDMI VR headset dev kit I thought I was going to use a while back uses very similar displays, but it turned out to require more than just a converter chip.

In the end I am quite happy with the HyperPixel 4.0 Square. The resolution is great, and it works.
 
I am currently working on a Pip-Boy and I have your code downloaded, but cannot get anything to work. I know I am missing something. I have all of the requirements downloaded. How do I go about getting the code started and working.
 

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.
Back
Top