Multiplexing Composite NTSC Video

This was one of those rare times where I had a hunch, followed it, and had a great result.

So for a project I’m working on for school, we have a robot with multiple composite video cameras onboard. We will be using those cameras seen on DIY drones or in simple security systems. We will be transmitting this video feed via a 5.8GHz video transmitter meant for a drone. We want the operator to be able to switch which feed they’re viewing at a given time, but we don’t want to have to use 3 transmitters and receivers. So to get around this, I thought we might just connect video feeds to a simple analog multiplexer I had laying around from a previous project and see if you could switch the feed that way. Turns out, you totally can. Here’s the eventual block diagram of this part of our project if you’re interested:

The following is the code running on the arduino. Remember, this isn’t doing anything special other than driving the mux:

RS485 Hardware Network 2 – Multi-Byte Communication

Edit: I don’t really make a point of saying it, but the common ground between the modules isn’t nesesarry.

Here’s a video of the software running on the boards.

So for this example,  there are 4 bytes being transmitted from the master to the slaves.

  1. Start of Transmission (0xDB)
  2. ID of the slave to talk to
  3. The type of command
  4. The data that is transmitted

A transmission to set the pwm value of the green led on the slave with the ID 1 to 100 would be:

This is the schematic of the circuit for this example:

This is the code running on the master Arduino:

This is the code running on the slave Arduinos:

RS485 Hardware Network 1 – Getting Started

For another project I’m currently working on, I need a way to control multiple microcontrollers in a multi-point, multi-drop network configuration. Luckily, we live in amazing times. As I write this, you you can buy a fully assembled breakout board for the MAX485 chip from Maxim Integrated for a mere $0.45 USD shipped from China.

I bought a 5 pack, here are some of the boards:

RS485 is an old protocol, but is the logical next step for devices I’m already communicating with via RS232. For this example, I’m using 4 Arduino boards of various types.

  • An Arduino Micro as the master
  • 2 Slave Arduino Leonardos
  • 1 Slave Arduino Pro Mini (5v)

Here is a video of the setup:

The schematic is really straightforward as well. The only tricky bit is that I’m using a software serial port on each of the Arduinos for ease of debugging. Here’s a schematic:

The code to acomplish this is really intuitive as well.

Here is the code for the master Arduino:

This is the code for the slave Arduinos:

In subsequent posts, things will start getting more advanced. For now however this should be enough to start from scratch.

Thanks for reading.

Raspberry Pi Digital Hourglass

Trying to get the most out of a day has been big theme of my life lately, as I’m sure it is for many people. I’ve found that I always manage my time better when things are urgent; I’m considerably more productive when I have to be.

I want an ascetically pleasing way to be able to represent how much time is left in the day at a granular scale, like an hourglass. Watching individual seconds disappear will look cool and (hopefully) create that sense of urgency that I want to induce.

Technically, this is a really simple thing to accomplish thanks to python and pygame. Here’s a video of a proof of concept running on my laptop:

At the start of each day, the display is filled with squares at random locations, with a random color. As each second elapses, a square will vanish.

To make it easier to see for the video, I’ve made the squares much bigger than they will actually be for the final build. This is what the display looks like with the squares at their actual size:

The code really really simple, like less than 100 lines simple. Here’s how it works:

Here’s the version of the code running on my computer in the video:

Let’s walk through some of the design decisions of this code. The first thing that’s worth talking about is how the data for the squares is handled:

It’s just an object with no methods, and on initialization, all the parameters of the square (location and color) are generated randomly as opposed to just floating the raw numbers in arrays around (even though that’s basically what is happening). This let’s us fill the squares array very easily later on in the file here:

and here:

When it comes time to draw these squares, it also makes that pretty intuitive:

Again, very simple stuff, but worth it to talk about.

I’ll be back at my place that has the Raspberry Pi and display I would like to use for this project, so more on this then.

Thanks for reading!

UV Resin Curing Cabinet | Final Code, Schematic, Bill Of Materials and Demo

Here’s a demo of the finished system:

In the end, it all turned out really well. Painting it white and using a white print stand was a good insight, the light reflects around the box pretty well for how few LEDs are in use.

The software flow chart has changed slightly. I removed the speaker as it wasn’t loud enough and added software debouching for the pushbutton interrupt service routine. Here’s that most recent version:

 

The interesting parts of the code are the cookResin function as well as the main loop of the Arduino:

Again, this all should all be explained by the flow chart. The full source can be found at the bottom of this post.

The circuit schematic hasn’t changed at all since this post, here’s a fritzing of what’s going on:

Super simple, basically a screen and a button. The parts to make this are here:

Assembly is super straight forward, if you’re trying to build one and have any questions, let me know!

All of the files necessary to make this project can be found here.

Thanks for reading!

UV Resin Curing Cabinet | CAD Modeling And Physical Build and Installation

This past school year I too several classes related to 3D modeling. One class in particular, a class based around SolidWorks. I hadn’t really been able to use the software again, not having the tools to actually execute. MADE@MassChallenge really has the whole kit, 3D Printers, a 40W Laser Cutter etc. All the tools of a hackerspace as a part of my job. Here’s a “finished” model of the system:

Cure Cab Models

The frame is built out of:

  • .22in thick masonite painted black on one side
  • The frame is held together with a series of L brackets and machine screws from home depot
  • The front opening is secured with two metal hinges from home depot

There were a couple 3D modeled components as well:

  • The four feet

I ended up gluing these down with hot glue even though they have cuts for screws. In the end, it wasn’t worth it to use more screws and add more complexity.

  • The electronics enclosure

View post on imgur.com

There is a frosted acrylic sheet inserted in the top. One of the goals of this project was to show off the tech, and I think this does that quite nicely.

  • The knob assembly

View post on imgur.com

The knob has a stem that comes of the back and forces the hinge back, keeping the door closed. I wanted to try and keep things as simple as possible. The threads I modeled weren’t within tolerance. So I just glued the nut in place so the knob could rotate freely.

  • The print stand, for holding up the prints so they cure evenly

View post on imgur.com

It doesn’t make sense to have the prints just sit on the bottom of the frame. I also cut inserts that fit the inside of the print stand. This is so resin doesn’t cure to the print stand so it can be used many times while only needing to change the cardstock inserts.

Here are some more photos of the build process:

Cure Cab Build Photos

I’ll include the plans to build this whole assembly in the final post for this project once it’s all finalized.

UV Resin Curing Cabinet | Declaration and Software Flow

This project is the first of what I hope to be many in collaboration with the MADE@MassChallenge Hardware lab. The primary goal of this project is to speed up the time to delivery on prints coming out of the Formlabs Form 1+ SLA 3D printer using UV LEDS. Here’s a proof of concept of my circuit:

One of my tasks during my internship at MassChallenge was managing the queue of incoming models to be 3D printed on our 3D printers. Turnaround is often a pressing issue when doing this. It was often the case that teams had a deadlines or presentations that they needed parts for. Shaving even minutes off of the time from submission to receiving a fully processed part mattered quite a bit.

The Form 1+ is an amazing printer. If used correctly, the print quality can be much higher than the other 3D printer in MADE, a uPrint SE Plus by Stratysis; a printer almost 5 times the cost.

The post processing involved with the Formlabs has a steeper of a learning curve and leaves a lot of room for possibly destroying a part in the process.

The problem is not a fault of Formlabs, but rather a problem in the chemistry behind the resins used to create the parts. They are photopolymers, and need UV light to be cured. It is suggested that this be done through exposure to sunlight, but that takes quite a long time. I also have a sneaking suspicion that there are adverse effects of doing this, but I can’t prove any of that as of now but hopefully more on that later.

As this is a project that will be used by people other than myself, it is worth it to commit time and effort into the user experience. Atheistic should also be taken into account as this has to stand up next to the beautiful design of the Form1+. In short, a UV LED strand, a 3A switch, a power supply and a Light tight box could functionally do the trick, but in this case a polished design is as important as the functionality.

At this point, a push button switch, a rocker switch and a 16×2 Character LCD will be the UI. The software flow is as follows:

I’ll post the final code when I finish, but this chart is basically what the code running in the above video looks like.

Thanks for reading, more on the physical construction in the next post.

Creature Capture | Variable Video Capture Length Code & Testing, Frame Rate Issues

So I’ve been working a lot in the past day in ironing out part of the night side loop (loop 3 in this diagram). Basically, it starts recording based on an input from a sensor and continues to record until these inputs stop occurring.

My test code looks like this

The interesting functions at work here are the following:

FilmDurationTrigger() Takes the period of time that will be filmed, in this example, it’s 5 seconds just to conserve time, but in application it will be 20 seconds. This code will pause for the input time, and continue to be paused upon inputs from GetContinueTrigger(). This delay allows the code to continue filming until there are no inputs.

In this example, GetContinueTrigger() returns a Boolean if a random event occurs, but in application it will return a Boolean based on the status of a motion detector.

I ran two tests, both of them produced separate results. The first one created a 10 second long video:

And the second created a 15 second long video:

These two test shows that variable capture length functionality works! As a note, the actual times on the output video varies from the amount of time that it’s designed to record for. This is because the variable frame rate nature of the video coming out of the camera module, it causes the videos to come out a little short, but they still contain all the frames of the amount of time desired to record, just scaled slightly by frame rate error.

Creature Capture | Stopping Raspivid After a Non-Predetermined Time

One of the biggest problems with the built in commands for using the Raspberry Pi Camera module is that you can’t stop a recording after an unknown time. You can record for a given number of seconds and that’s it. I have attempted to solve this problem by backgrounding the initial record process with a time of 27777.8 hours (99999999 seconds) when it’s time to stop recording, the process is manually killed using pkill.

Here is a test of my code, which I’ve called CameraModulePlus (written in python) which takes two videos, one for five seconds, and one for ten seconds, with a 10 second delay in between.

Here is a result of the 5 second duration test:

Here is a result of the 10 second duration test:

As you can see, it works pretty good for how barbaric it is. The full class for CameraModuleVideo can be found here. In the future, I’d like to encode a lot more data into the CameraModuleVideo class, things about time etc. Also I would like to monitor available space on the device to make sure there is enough space to record.