User avatar
By ImperialWalker
#4954318
Hello All,

I am nearing the end of my CD Ghost trap build and while the physical modifications are going well, I am struggling with the functionality.

I am pretty new to coding so it is taking me a lot of time to learn the basics. Things are coming slowly, but I've hit a few walls. I've tried posting them on various groups and forums, but while a few people have said they will eventually get time to look it over, I've not really found anyone with the vested interest in the project.

I was hoping that there may be a few around here that might be well versed enough in code to help me sort out the last bits.

I am working on files created by Sean Charlesworth and Jeremy Williams, further modified by EctoLabs/Dave Tremaine. Below are links to my modified sketches as well as the issues / goals I've been working.

_______________________________________________

My Modified Files:

Trap Sketch
https://drive.google.com/file/d/178IvcB ... sp=sharing

Pedal Sketch
https://drive.google.com/file/d/1ibNVv7 ... sp=sharing
_______________________________________________

Background

Since starting this trap my goals have been to both increase the functionality and the accuracy to the original movie. The steps people have taken have been excellent starts, but there are still a few things that I would like to nail down to make it a great trap in my eyes.

For example, one of my top priorities has been having a library of capture sounds that would play randomly. The capture sounds that people use for their traps are great, but I wanted to have it feel like every capture was a unique experience.

After a few days of messing about I was finally able to attain that goal and now my trap plays one of nine random capture SFX that contain a different "ghost" that I've made. Details can be found in my build thread.

I've also solved a few other issues like a green LED that would randomly come on as well as the blinking "trap full" light to blink more in time with the movie / SFX.

Those successes have been great, but I still have few things I would like to accomplish.

_______________________________________________

Issue 1: Coding and Delays

Granted I am not a professional programmer and I've only started learning, but in my short time I've noticed that while the code in its current state works, it does seem like the mashup of different programmers and skill levels has resulted in a sketch that seems to not use best practices.

For example, there are a lot of "delay" statements in the code in order to deal with timing. Millis() is also used in places as well, but the combination of both seems to be limiting the ability to expand the code.

For example, there are times in the code when a Millis() could have been used, but a delay was used instead meaning there are times when the pedal functionality can be sluggish as it waits for code. Another example is that there are times when blinking lights and other functionality bumps up against other loops running. The blinking light for example can sometimes lose timing as the code cycles through the Loops, hitting delays.

I am wondering if anyone is well versed enough to look over the code and assure that best practices are being used for delays and functions that are running at the same time. It isn't a big deal, but I think it would help make this code easier for others to implement in the future.

_______________________________________________

Goal 1: Blinking / Fading Red LED

In the movie the blinking red light on the rear box does not turn off and on. It has a slight fade in/out effect.

Originally I couldn't get this working at all even using the most basic code. Turned out that CD recommended the LED be connected to a pin that didn't seem to allow for PWM. After switching it to Pin 3, I was able to get the fade/pulse functionality.

Partial success.

The issue seems to be now that when implemented in the trap sketch, it runs up against delay functions in the code and won't allow the fade/pulse to run through correctly. I've tried three different methods and the result is that the LED fades in slowly or in an inconsistent way.

I suspect there is a way to make it a Millis() function to the timing can run independent of the rest of the code, but I can't seem to figure out how.

_______________________________________________

Goal 2: Greater LED control

My trap uses Neopixels that were a modification by EctoLabs giving much greater control over the CD version which uses three white LEDs strobing through a pink filter.

Currently the NeoPixels fire three times during the capture sequence.

A. When the trap is first opened. There is a pink/white cycling of the lights.
B. A strobe effect when a ghost is being captured
C. Blue sparks a few seconds after the doors close

What I would like to do is have more control over the Neopixels during these sequences.


Opening Trap

In the movie when the trap is first opened, it is surrounded by sparks with a bright pink/purple/blue/white flair in the centre of the trap.

Image

The current sketch seems to open the trap with white light and then randomly pop in a few pink hues which will cycle until the pedal is triggered for the capture sequence.

There are three Neopixels in this trap with a 21 LEDs. It would be sweet if the initial opening could burst a huge, blinding, pink centre burst with blues, whites and purples randomly on the others. Then perhaps settle down and do as it currently does where it cycles through the colors randomly as it waits for input.

Capturing Ghosts

During the capture sequence it seems to go very bright pink/white with swirling pink/blue sparks/beams.

Image

Currently the trap seems to just strobe white progressively more until it closes. I think this is an underuse of of the Neopixels as the original design from CD just strobed as well.

It would be great if this was more dynamic with more colors and such.

Trap Full / Sparks

Image

The program waits a few moments and then flashes the LEDs randomly with a pure blue color. It looks cool, but again I feel it isn't taking advantage of the Neopixels. You can see in the movie the sparks are brighter and dimer in spots. They're also not all pure blue as there is some purples and such in there as well.

It would be cool if the LEDs had a wider range of blues and purples and brightnesses.

_______________________________________________

Goal 3: LED blink on pedal

This is where I would like to veer of course a bit. There is a red light on the pedal, but in the movie and in the current design it doesn't do anything.

The original plans did not allow for the red LED to blink on the pedal. Because the hose that connects the trap and the pedal contains 2 wires for the micro switch, there is no way to run any additional wires to control the LED. This is why I purchased an Itsy Bitsy hoping it would allow me to use the switch to control the LED to make it appear like they are functioning as one.

Progress?

The pedal code above is a stripped down version of the main code. The idea is that when the pedal is pressed, the micro switch would trigger the Itsy Bitsy (this is just a smaller micro controller), which in turn would trigger timers to line up with the main trap.

I cannot make this work for two reasons:

A. The trap code has delays which can cause it to not register pedal presses. For example, as the code loops through the sparks after capture, it seems to miss pedal presses to reset the trap. However, because the the pedal sketch doesn't have as many loops, it triggers perfectly.

This means that the trap can be on the capture sequence while the pedal is on the reset sequence. Then if the pedal is pressed again, the pedal goes while the trap resets. They are now out of sync and nothing can be done to align them.

Secondly, once the trap is powered off, it seems to create a short which starts to trigger the pedal code. This will run over and over until the battery dies meaning there is no way to shut it off or stop it.

I don't know how to fix this.

_______________________________________________

Goal 4: Startup Sequence

One of my goals was to have the red LED light up with the bar graph LED. I've solved this, but I would like to expand it a bit.

The original CD design seems to play a startup sound from the game. EctoLabs plays a GB sound from one of the songs I believe.

I would like the trap to be more like the Proton Pack where it powers up and there is immediately a sound that plays that then goes into an electrical hum SFX. I think it would feel much more real and cool if the trap started up and hummed until it was opened. The movie didn't really seem to have a sound, but it might be cool to have it sound like something.

_______________________________________________

Goal 5: Smoke Machine Integration

The smoke machine effect is pretty cool, but it is also the part I dislike the most. You can see on my build post that I've tried to minimize the "buzzing" sound as the pump kicks in.

Currently, the code starts the air pump at the start of the capture sequence and runs it for about seven seconds. This creates a long, obvious and distracting buzz that is obviously a pump.

I would like to find a way to get more control over the pump. My thought is that instead of a sustained draw on the pump, there might be a way to pulse it at appropriate times that are hidden by the SFX. I am wondering if a few short "puffs" will get the smoke flowing well enough.

Also, I realize that the smoke is released during the capture sequence even though this doesn't happen in the movie. The smoke show really happens when Ray exits the ballroom where the trap is smoking. It would be nice to have the option to have this smoke come out after the capture either automatically (maybe during the sparks) or a double pedal press or something.

_______________________________________________

Goal 6: Volume and Additional Functions

The rotary switch on the left side of the trap currently has no functionality.

Currently the only way to adjust the volume on the trap is to adjust it manually in the code. This is impractical when wanting to show people.What would be cool is if this rotary dial/switch could be used to adjust the overall volume of the trap in case I want to show it in different environments (with a beep feedback for volume). Additionally, there is a press function on the knob (like the other side) it would be cool if this could turn on/off the smoke machine temporarily. That way it could be shown, but not have to always use the smoke feature.

I've seen this functionality on Proton Packs where smoke can be tested/triggered and volume adjusted using a rotary knob. I've been trying to make this work for about a week, but unfortunately I think it needs to be scrapped.

The rotary requires interrupts to work, but the only two on the UNO board are pins 2 - 3.

I moved the LED to another PWM pin, but there is a jumper on Pin 2 for a reason I am unaware of. I assume it has something to do with the Music Maker Shield.

Either way, this means there are no interrupts available for the rotary knob. I could still do some static push button action, like perhaps 5 presses for volume, but that seems silly. The only option is if jumper on Pin 2 can be switched to another pin or whether it needs the interrupt pin.

I simply can't figure out how to make this work.


_______________________________________________
User avatar
By CountDeMonet
#4954841
yeah there are some issues with the code. It's utilizing blocking delays in areas that could be optimized with timer functions. Things like this will cause all kinds of issues

strip.fill(strip.Color(strobeUp,strobeUp,strobeUp,strobeUp));
strip.show();
delay(20);
strip.fill(strip.Color(strobeDown,strobeDown,strobeDown,strobeDown));
strip.show();
delay(20);

Instead you already have the millisDelay.h library which can obscure some of the complexity of using timer functions. The big thing is each delay makes each loop take longer to complete as they are blocking. Anywhere you see a delay in the main Loop or related function like above should be reworked to use the millisDelay library since you already have it in there. Note that the delays in the startup function are ok. During the startup we sometimes have to wait for hardware to initialize so using a delay there is ok. It's in the main loop where you run into problems.
User avatar
By ImperialWalker
#4955530
CountDeMonet wrote: August 31st, 2021, 1:00 pm yeah there are some issues with the code. It's utilizing blocking delays in areas that could be optimized with timer functions. Things like this will cause all kinds of issues

strip.fill(strip.Color(strobeUp,strobeUp,strobeUp,strobeUp));
strip.show();
delay(20);
strip.fill(strip.Color(strobeDown,strobeDown,strobeDown,strobeDown));
strip.show();
delay(20);

Instead you already have the millisDelay.h library which can obscure some of the complexity of using timer functions. The big thing is each delay makes each loop take longer to complete as they are blocking. Anywhere you see a delay in the main Loop or related function like above should be reworked to use the millisDelay library since you already have it in there. Note that the delays in the startup function are ok. During the startup we sometimes have to wait for hardware to initialize so using a delay there is ok. It's in the main loop where you run into problems.
Sorry, I didn't see this. Didn't get a notification.

That is what I first thought when I started understanding what this code was doing. The millisDelay seems to be interrupted by all the delays. My understanding is that this entire program should basically work without delays, but allow each section to be conditionally run with millisDelay.

If I am understanding it correctly, this would mean that they could run without stepping on other parts of the program.

Not entirely sure how to do this though. I may have to strip the code down and slowly plug away from scratch to see if I can remove the delays.
    Hasbro Ghostbusters

    While you're 100% correct about the function[…]

    Uniform Tips

    It does rain frequently here in London, but not to[…]

    The yellow parts are raw 3D prints, unsanded and u[…]

    Sorry, I hadn't seen any of these replies. Either […]