8mm Machine - Software Frameworks

Software
1

I have started working on a prototype for the 8mm machine and am using a Raspberry Pi. I chose the Pi because of its embedded Linux filesystem for storing images and the affordability of its camera module.

Now that I have chosen it, I’m looking a the advantages/disadvantages of different language frameworks for development and thought I’d post my thoughts here in case anyone had some insights/comments/suggestions.

Functionality overview
Hardware
camera
motors
sensor

Software
Save images
Display images
adjust camera settings
render movie file from images
play movie file
move files, post online, etc.

User Experience
To avoid having to develop software for multiple platforms, I imagine the browser being the best way to interact with the machine and its processes. Since the Pi is capable of handling everything on its CPU and GPU systems, the computer connected to the machine is really just to monitor the machine’s status, preview the images, and see the final movie file output.

The experience would go something like this:
Unbox machine
Plug machine into power
Plug machine into computer via ethernet
Open browser
Navigate to local host URL (an application server running on the Pi)
Load film into machine with an image in the gate
Preview frames with software
Adjust camera settings
Rewind (if necessary)
Run machine for full reel capture
View result at end of process
Post files to sharing sites online (using computer’s internet connection)
Download files from Pi if you want to keep them locally

Python
The Pi plays very well with Python and there is a library written for the camera module. File I/O is easily handled. Not sure how great it handles events and these might be necessary in hardware. As for using the browser, I’d use something like Flask to build the server. Language is highly documented in Pi community and used widely in other areas.

Node (JavaScript)
Interested in Node because it runs asynchronously, allowing for keyboard interrupts and hardware events to happen simultaneous to other processes like file writes. It is also built to work with browsers easily. Includes file I/O modules. Would be a language open to others beyond the Pi/Python worlds.

Open Frameworks (C++)
Includes event handlers, file I/O and ability to include server stuff but it isn’t exactly oF’s strong suit. Probably would result in more code.

I’m learning Node now to see how it works. Will report back. Any feedback is welcome!

1 Like
2

Just some ideas…

Because this is an open source project (that could be improved by contributions from other developers), my suggestion would be to make a RESTful API that controls the machine. It could just be a simple webserver that listens on port 80. I’m not sure if this project would really benefit from Node’s asynchronicity, although you could certainly write it in that, or you could use Python+Flask (which would probably be easier), or anything else you want (Ruby, PHP, etc.). The idea here is that the API would provide a set of endpoints/commands for controlling the machine, and that’s it. So let’s say you had a very simple object called “motor” with two properties:

reverse: true if the motor’s direction is set to reverse (for rewind), false otherwise
running: true if the motor is running, false otherwise

Then you could make a GET request to the /motor endpoint and get back something like:
{“reverse”:false,“running”:true}

Then, to change the state, you could make a POST or PUT request to /motor with the new object, e.g. {“reverse”:false,“running”:false}

Which would stop the motor.

You could create similar endpoints and objects for every other piece of hardware that the API would need to control. For example, you could have a “light” object:

{“brightness”:.75,“on”:true}

And an “image” object (which would probably just return a raw image from the camera).

Once the API is complete, you – or anyone – could build the actual software application that controls the machine simply by making requests to the API. The software application could be written in any language - it wouldn’t care (or even know) what language the API was written in. So the end user would interact with the software application, and the software application would control the machine through API requests. The software would not necessarily need to run on the Raspberry Pi itself (although you could certainly ship with a version that does). Or anyone could just as easily write a desktop or mobile app. Or all of the above. Furthermore, you could use a compatible API for each version of your machine (8mm, 16/35mm, etc.) so that the same unmodified software application would work with each version. You (or anyone) could even make a “Multi-Kinograph” version of the software for users with large film collections that need scanning, which would work by controlling multiple Kinograph machines simultaneously.

3

Thanks for the advice, @dave. I think I will take your advice and head in the direction of a RESTful application. I was intitially interested in Node’s asynchronous abilities to allow the machine to keep moving while the image was being saved - but I suppose that isn’t a huge issue at slower speed (which is what I’d be using).

I’ve been wanting to learn Node for a while so I’m probably going to head in that direction for now but will keep Python/Flask in mind as I have used that before (albeit a couple years ago).

If you can think of any projects that have created a similar RESTful API to control a hardware device, I’d love to see their code base so I can learn from their overall design.

Are you a developer too?

matt

4

@dave I remembered why I went with Node - and I think I need some clarification so I’m hoping you can help me.

I imagined an interface that would respond in real-ish time to the state of the machine, updating the UI in the browser as things happened. To my understanding, Sockets.io is a great way to get back and forth updating between server and client without updating the whole page.

Do RESTful APIs require a full refresh of the page every time a request is made? In my n00b mind, pointing to a URL means reloading html on the page…but that is probably (and most likely) wrong.

Matt

5

So the idea of an API is that it receives and responds to commands from other software. So my suggestion would be to have an API running on the Raspberry Pi that would accept commands to do low-level operations like advancing the film, adjusting motor speed, take a picture, etc.

Once you’ve got that, you can build a software application that works by talking directly to the API. The important part is that the software application works by sending commands to the API and receiving data back from it.

You could build the software application as a web app if you want. That would probably be the easiest place to start. If you go that route, you will want to use Ajax calls so that it can update in real time without refreshing the whole page.

Take a look at this failed Kickstarter campaign from a couple years ago. They were using a RESTful web API to control the motors, so that applications could easily be written to control them from any device (smartphones, etc.). It’s too bad that this project never made it off the ground - it looks super cool.

Here’s another project you might want to take a look at. It’s a good example of a REST API (running on node.js) which controls four motors. Starting at around 3:10 in the video, you can see the web interface (running on the tablet) making REST calls to an API (running on the laptop) which controls the Arduino which controls the motors. That’s the framework that I’m suggesting you use for Kinograph – the user interacts with a web or mobile or desktop app, which sends commands to a REST API, which controls the actual machine.

If you feel like digging further, Arduino provides a similar REST API for the Yun, and here is a project that aims to do the same for all Arduino boards.

6

Awesome. Thanks for all this info, @dave. I’ll dive into those links immediately!

7

There’s a really great GPU-accelerated oF camera add-on for the Pi 2:

8

@n1ckfg AHH! This is just what I was looking for…only in Node. I’ve been developing the 8mm version on the RPi using Node. The choice was based on the following:

  • development of GUI for browsers to make software platform agnostic
  • use of sockets and asynchronous functionality for quick 2-way communication between RPi and interface
  • ease of use for other developers to contribute

If this OoF add-on works the way I want it to, how do you recommend I proceed?

M

9

I should clarify - I’m interested in any library that will get my fps rate up. I have found a solution for stabilizing frames mechanically so CV is not a priority for now.

10

Couple months ago I made a little native blob tracker app combining the Pi Noir camera, ofxCvPiCam, and OSC…seems like you’d need something similar, but using websockets so it can talk to Node?

Btw I think ofxCvPiCam is only better overall if you’re doing CV–if you’re just grabbing images and passing them to Node, Jason’s ofxRPiCameraVideoGrabber might be faster.

Also, seen this?
http://thejackalofjavascript.com/rpi-live-streaming/

11

Thanks @n1ckfg. Yes, I’d seen the jackal link. He was very helpful in getting me started running Node and the raspicam on the Pi. I’ll def. look into these other ones. Thanks for lookin out!

M