Tell us about yourself!
That's cool, glad my project could be of help to you!
Yes, that is possible, I would try to do it mostly in code. I would use a global bool to track whether the motor is currently running or not. Then when the beam breaks, check the state of the bool and decide whether to turn the motor on or off.
I don't mind at all! Just let me know what you need, and I'll try to answer it. Sounds like a cool project.
I think I was just messing around, and never did anything useful with that switch. I would suggest connecting your beam sensor to a digital (or analog, if necessary) input on the Arduino. Then you can use software to control how your motor responds.
The code is finished and available at this GitHub project. I've also updated Steps 17-26 of the Instructable to reflect these changes, so you should be good to use the new code.
I can't think of anything off the top of my head.By the way, the bug you discovered has motivated me (thank you!) to rewrite the code to be much better than the confusing mess it is now. So, before you start editing too much, you might want to check back in a few days and see if the new version clears things up for you.
You're right, only three of those pins are used. Originally the ShiftRegister class could also clear the shift register using the SRCLR pin, so I had to add a parameter for that. However, in the current version the clear pin is not used.The numbers, in order, are: data, clock, latch, and clear. You can ignore clear, or set it to some arbitrary number, it's not used.
The transmitter here doesn't trigger the launch system until the countdown is finished, so you can just flip the power switch off to stop the countdown.You're right, though, the countdown is pretty impractical. I just put it in for fun. I am working on a revised version that functions more like a traditional Estes launcher, just wireless.
Wiring it directly shouldn't be too bad. Just connect the sixteen column pins to sixteen GPIO pins of your choice (through resistors, of course) on the Raspberry Pi. You will have to edit the code, though, because it's designed for a shift register-style setup.Note that some GPIO pins on the Raspberry Pi have other functions besides simple I/O, so you may want to look at a chart to decide which pins to use.
Ah, good point. Maybe something like a momentary key switch would be in order.
You are absolutely right. The current code requires six bytes of pairing data (or whatever it's actually called) and one byte of informational data to launch. I haven't had any problems with misfiring since I added these requirements.If you like, you could edit the code to add more pairing bytes. It will take a bit longer to transmit, but there is a lower chance of a random ignition.
Yeah, not my best launch.
Remote Rocket IgniterView Instructable »
Great, it's cool that you got this to work as an 8x8x8 LED cube!
I had a problem similar to this when I was initially writing the code. I was clearing the shift registers slightly too late, so their contents were displayed on the cube for just a moment, resulting in a ghosting effect like what you describe. Maybe your shift register timing is off; after all, you have four times as much data to shift out, it likely takes more time to work.I'd suggest adding very short sleep() functions to the multiplex() function in various places and seeing what effect they have on the ghosting... maybe that will give you an idea of where the problem is. Other than that, I'm not really sure what the problem could be.
Okay, here are annotated versions of the LEDcubeCore.py and LEDcube.py files. I put my suggestions as comments in the files themselves.
Okay, here are annotated versions of the LEDCubeCore.py and LEDcube.py files. I put comments with my suggestions in the files themselves. Hopefully this helps!
Okay, here are annotated versions of the code files. I tried to link directly to them, but was forced to link to a zipped file instead. Hopefully this works, but if it doesn't, let me know.