The Makercast: a Video Livecasting Platform You Can Control

Power to the people!
Something out of frame? More interesting things going on in another direction? For the first time ever you will be able to directly control where the camera looks in a live video cast!

All of that control currently via this Twitter account.

A long long time ago I filled out a form here on Instructables and then, quite a while ago already, got a bunch of cool stuff from Intel. How can one feel something else than love for Instructables?

The stuff arrived, I was ecstatic and all (as seen in gif) and then it struck me - you have to deliver on the crazy idea you pitched to get this stuff!

With this in mind, I got to work. Well, actually I didn't get to work right away, I read some comments in the forums about Base shield not being included and ordered one from China right away, thanks for the tip!

Step 1: No Idea What I'm Doing

While I had some sketches for the platform and the plan for writing code laid out it soon became clear to me that I have no idea how to become friends with this new platform. It actually took me several days, more than 10 hours in total until I finally got the board connected to the computer and running the blink sketch with arduino. While I could transfer some fault of that to the all-in-one installer and Windows OS, mostly the fact was that PEBKAC, as shameful as it might be to admit that. Installing everything separately and manually flashing was what worked for me along with this old video.

Since the problems never really end this was only the first issue, the timeline of the project looked something like this (from what I can recall):

• August: Receive the board and goodies from Intel and Instructables (yay, much excitement and hope)
• August: Receive the Grove Base Shield along with some jumpers, then spend several days trying to connect Edison to PC, something off with drivers, Arduino client and all that. Mostly the PEBKAC.
• September: Everything connected, trying out interesting modules including the motor drivers which don't work.
• September: Motor drivers still don't work, even on Arduino.
• September: Kind colleagues hook the driver boards to an oscilloscope. No sign of life, MCUs on boards probably empty.
• September: Kind colleague helps with flashing things into the motor driver. It's now recognized by Arduino and Edison.
• September: I hook up an MPU6050 to the board because it seems like I will need it for position awareness.
• September-October: Unusual amount of work falls on my head, Edison collects dust. Bought some hardware parts for the dolly. Deadline extension gives me hope.
• October 11: Get back to things. Spend whole day trying to figure out how to get and filter IMU data. Only succeed in getting values and converting them to SI units. Decide to try playing with motor drivers instead for now.
• October 11: Motor driver shows no sign of life on either Edison or Arduino.
• October 12: Kind colleague suggests that I click the reset button on board. Arduino now sees the driver board on I2C. Feeling dumb means I just learned something.
• October 12: Decide, that there's no need for IMU in a system of clearly defined movement range.
• October 13: Edison doesn't see the board on I2C and hangs on Wire.endTransmission when scanning I2C.
• October 13: Decide that I will try using python for the motor driver instead. Have no python experience what so ever, but an Instructable by CarmelitoAndrade guides me quick. Thank you!
• October 14: Try things with python. Can't update libraries and am otherwise clueless as expected.
• October 15: Flash the newest image to Edison since I won't need to run arduino script on startup and try getting libmraa again. Success this time.
• October 16: Two clicks away from buying other motor driver, but decide to test the list of libraries one more time. There you go, apparently, to run the Grove motor driver you need the grovemd library, not l298 one double facepalm
• October 16: Managed to run the motor driver using Arduino script. Well, better now than never I guess.
• October 16: Try to SSH into the board, something's wrong again, unable to connect on both WiFi and serial.
• October 17: Flash the Edison again to fix the connection issues, fail to download libmraa and have to go to work.
• October 18: Manage to update libmraa, try the grovemd.py sample and it works, learn some python while on it. Such achievment. Much hope!
• October 18: Design the files for manual and laser cutting the plywood parts of the dolly.
• October 21: Cut the designed parts
• October 23: Assemble most of the dolly
• October 24: Spray rubber on the wheels
• October 26: The rubber I sprayed on fails to deliver. Welcome the rubber band!
• November 7: Made some hardware changes to the dolly and drilled holes for circuit boards
• November 8: Managed to turn on an LED with a tweet, finally. Then motors as well.
• November 9: Soldered some wires and put everything together for a test. Took pictures and hurried to write this instructable.

One thing I can tell for sure - I'll be taking Harvard's CS50x as soon as the new one appears online (new year or so). All of this frustration made me understand how clueless I am in these things and getting me deep in more cluelessness might just solve that. Or not.

What I can tell to those discouraged by similarly less explored/more complicated platforms - just keep going and digging for answers and you'll get where you want to be. Persistence never fails.

Step 2: Tools and Materials

Useful resources for those just starting out with Edison, Python and Linux (like I was):

• VI cheat sheet
• Basics to get you moving with Python on Edison
• libraries and examples for the Edison
• Grove motor driver software (if empty, like mine was)

Materials:

• Intel Edison with Arduino breakout
• Grove Base Shield
• Grove motor driver
• F280 motors (2)
• Towardpro MG996R Servo
• Some wires
• LM7805 and some capacitors for it
• Female USB connector
• USB to micro USB cable
• Two power supplies (12V 1.5A and 2A)
• Some tumblers (because turning them on is satisfying)
• LEDs
• Plywood (4mm, 6mm and 12mm thickness)
• Bolts, nuts and screws (too many to list)
• Plastic wheels with grooves
• Aluminum tube
• Aluminum profiles
• Cartridge ball bearings (12mm outer, 4mm inner)
• Threaded rod (2x1m)
• Probably something else I forgot

Tools:

• 20mm wood drill (frostner in my case)
• Electric jigsaw
• Drill
• Laser cutter (can be replaced with drill and saw)
• 3D printer (can be replaced with drill and dowel)
• Magic (something else I might have forgotten)

Also used in the whole structure:

• Cellphone which can run Persicope (again thank you to my kind colleague who lent me and iPhone since my own phone is too old for all of this)
• The allmighty internet!
• A tripod
• Zipties

Step 3: The Software

As it turned out in the end, my needs for code were pretty simple (went through the usual cycle of oh it should be simple to how do I do that to well, that's not that bad):

• Twitter communication (reading tweets, tweeting)
• Running the motors
• Determining position of the dolly

The first two were pretty well documented online therefore not a real issue. The last one was for me to figure out.

For Twitter communication you need to install tweepy on your Edison. It might be that there is a simpler way to do it, but I'll explain my workflow with links step by step, since I had to do a fair share of googling despite existing instructables and all that.

Install unofficial repositories
Install sudo
Install pip
Install tweepy - this was just sudo pip install tweepy

I honestly don't even know what is sudo or pip, but I know that I needed those. If I write something absolutely wrong - please leave a comment with an explanation and I will fix the instructable, thanks!

All of the code is attached. Comments are added to it for your convenience (probably mostly for my own convenience, because I won't remember anything by the time I decide to do a major overhaul of it).

Other resources you might want to look into when working with Tweepy/Twitter API:

API documentation
Tweepy documentation

Generally, the coding experience was enjoyable despite the fact that I used python and linux for the first time in my life. All the pin addressing is handled very well on Edison and it is good not having to write one piece of code in python for twitter and then another piece of code for the microcontroller things.

Oh, and by the way, in the code I run I've added a few extra commands the dolly will react to. Let's just say those are the easter eggs here and are for you to find out. :)

Step 4: Electronics

Nothing overly complicated here, or should I say it's almost too easy with shields like that?

Everything that one needs here is feeding two DC motors through a driver and servo with external power.

I soldered the voltage divider (is that the right term in this case?) on a simple piece of perfboard using various questionable methods (it works though). There is a jack for 12V DC plug, straight from it 12V DC out to motor driver and a split to a LM7805 voltage regulator circuit which is then split into a male header for servo ground, power and PWM (comes from D3 on Edison) and USB jack for future needs of having the phone on constant power.

What goes where is seen in the 3D picture of step.

As a note - if you are going to use that kind of 5V power to charge an iDevice - you will need some resistors on data pins to make it work. Do your own googling for this, but I think they were 33kOhm and 22kOhm.

Step 5: Part Making

Most of the parts were cut on a laser cutter - one of the perks of doing everything in a makerspace.

I attached the files used for cutting to this step just in case you want to make the same thing. Please note that the cuts where I needed accurate holes are sized according to the laser I was using and its amount of burn on the line (0.2mm on 4mm, 0.4mm on 6mm veneer). Your machine might burn out more or less material and that would create some unplanned consequences, so edit as needed. To measure things in a vector file, use something like Hotdoor Cadtools for Illustrator. If you want .ai files instead - just send me a message here.

The box template was made using the wonderful tool makercase.com provides and then edited for my own needs.

The couplers were made using 123D Design, so nothing fancy. Again, please note that the holes are not exactly the size of the shaft since I needed to account for printer tolerances and all that. The files for printing couplers are added to this step.

The first thing I'll fix here is making the top so the phone is horizontal. I wasn't aware of Periscope already being able to rotate video when I designed this. This shouldn't be too difficult and I will just update the instructable when I fix this.

Step 6: Assembly

Again, since many of the structural parts were machine cut - things came together rather well and it's a surprising new thing for me to be honest. Earlier so much of my time was spent inventing workarounds and now I actually got to just think and make stuff with something at least closely suitable (well, mostly).

Still, there are things I did and you shouldn't. First of those was being way too ecstatic about parts being cut to think before starting to assemble the upper rotating part with servo. That was pure luck that I was able to bend it just enough to fit one part into another and then glue together. Should've thought about the sequence here.

Another thing worth noting is that the printed couplers aren't exactly perfectly sized and they go on with a lot of pressure. These motors, or more exactly - their gearboxes don't really like this method of application. Therefore, after doing a press fit it is a good idea to take thin nose pliers and list the coupler a bit, that seems to fix the grinding in the gearbox at least partially.

Step 7: Other Considerations

As you might have seen in the part making step, the wheels have thin tubes between bearings to avoid pressing them together. The wheels themselves were ordered in such form, I did not turn them.

The tubes are attached to the vertical plywood pylons using screws, nothing fancy there, just had to improvise a jig for drilling them correctly. Used a few drilled wooden blocks for that.

Spray rubber should've in theory worked as a nice grippy surface for the drive wheel, but it did not, therefore trusty rubber band was applied instead. Trusty rubber band was applied on the phone holder as well.

A lot of zipties were used, but if you do have one and remember to put it on - use something like nylon sleeve for the cables to avoid any spots for potential catching.

Step 8: So How Does One Control It?

Figured that I forgot to write out the commands in the 'ible!

For most of you who didn't read the python code I added, here's the list:

• turn right
• turn left
• move right
• move right
• turn up
• turn down

The commands are case sensitive, but you can, and likely will have to write something after it because twitter doesn't allow tweeting the same thing to someone over and over again. The sample command looks like this:

@makrcast turn down
@makrcast turn down for what! will do the same thing as the previous one, feel free to write anything you want after the command.

There are also some commands I didn't mention here which will do some interesting things, look at them like Easter eggs you will be able to find. They are all single word commands.

Step 9: Updates!

The day of screw-ups!

Screw up #1: Dropped the dolly, afterwards the servo decided not to work anymore (something with the pot)
Screw up #2: After designing a new top part to hold a phone horizontally and deciding to fit a smaller servo (it's a balanced load) I most likely shorted the servo connecting it.
Screw up #3: Messed something up with the twitter control. It reads tweets, but doesn't move anything. Motor test code moves everything just fine. No idea, but probably something to do with the long sleep duration.

I attached the new files for cutting a horizontal case to this step.

Fixed everything up. Apparently grounding through a motor driver isn't common ground enough for servo.

Finally made a video of the thing in action and attached to the first step!

27th of November: Presented the Makercast platform at a local Hack&Tell event. All the mistakes and sketchy solutions were received with a healthy amount of laughter. :)

1st week of December: got a phone at work which is capable of Periscope streaming after the last one I had borrowed was sold. As soon as I have some time (read not until new year) I will design a new mount for the new phone and will get this to work again.

Step 10: Future Plans

While functional, this was done in a bit of a hurry to make it in time for contest and free up some working memory in my own head for other projects I'm absurdly late on. Therefore, it's no surprise that I would like to add more functionality to this as soon as I use the current setup long enough to understand the weak points some of which I already mentioned in the steps with code and assembly.

First major thing I would like to figure out is either reading Periscope comments for commands or using another platform to cast on so the comments for control and video are in a single screen. Twitch is currently a strong candidate, since they have an API for devs as well and I can cast in 720p.
Then will probably come beefing it up to allow the use of both cellphone and DSLR, maybe even at the same time. Would love to try out Actobotics, like Randy did.
Also, it would be smart to convert this to belt drive because that wheel with rubber bands is a bit sketchy.

The next livecasts planned with the platform:
Nov 26th starting 16:00UTC - Making a bunch of Google Cardboards during a workshop at a makerspace
Nov 27th starting 17:00UTC - a cast from a local Hack&Tell including my talk about this project

If you liked this project - please vote for me in the Intel Invitational contest, thanks!

See you on live casts!
Raitis

You can follow me on Twitter and see what's up as soon as I post it there.

Step 11: The End of Makercast V1

After trying to fit the use of this platform in my workflow I found out that it is rather inconvenient having to set up a relatively big camera dolly like this. It also tries to break my not overly bulky tripod every time the weight is towards the side. Another aspect of the size is that it gets in the way when doing something and can end up in a spectacular sight of me tripping over it and sawing some body part off on live stream (would probably hit some records before being taken off). Due to all of this mentioned previously, the plan is simple now:

• Makercast platform gets partially disassembled
• The parts will be used to create a DSLR dolly (will need to DIY a beefier dedicated tripod)
• The dolly will most likely run on a belt drive on a single stepper motor, might have another axis of movement too
• Edison will serve as a test platform for IoT things until it's required for Makercast v2
• Makercast v2 will be a robotic arm with, most likely, a webcam and streaming&control via Twitch

I have no clear timeline of everything mentioned, but the dolly thing should not take too long, since I need one in my video making endeavors. Makercast v2 might as well take more time since I don't have enough knowledge on the software side to integrate with Twitch API and make the robotic hand move as it should.

That's it for now. To see what I'm currently working on - head to my site makerraitis.com (patience please, will be live in a month, hopefully). :)