I wanted to make sure my final project would hold my interest and keep me inspirerd through the whole Fab Academy 2017 cycle, while touching on the majority of the topics we cover.
The concept I landed on is a system of swarm robots that will use flocking and clustering algorithms to create generative art. Below are some examples I found in researching around the topic:
I love the speed, size and intuitive interface on these. Unfortunately, the location tracking is based on a high speed (3000hz) projector, which puts it out of reach for this project. The design will be a great resource for miniaturizing my robots.
Rice's low cost platform is an example of another control system that is working well, without the cost of a high speed projector.
This is a fantastic example of the type of collaborative output I would like to produce through this project. Systems that allow a computer to interpret input, and make decisions about how to contribute is really where the magic happens.
The complexity of swarm robotics typically comes from having them act autonomously, and their communication from robot to robot. I intend to simplify the system by controlling them centrally. Each will be aware of its current position and its goal position (transmitted wirelessly), but their relationships will be handled centrally. Each robot will be assigned a unique LED color so it can be located and corrected if its locations are not being matched.
I wrote a couple processing applications to do infrared blob tracking:
The tracking application (left) interprets input from a camera, and generates x,y coords between 0 and 1, then broadcasts it over OSC. Here, the second application is drawing a continuous bezier curve with that data. I built it modular so I could repurpose the tracking portion.
This clip shows a camera calibration routine, used to specify an area to track inside the camera's view. This helps correct for odd camera placement or parallax.
The bots themselves are intended to be as simple as possible. This makes the system easier and cheaper to scale as a swarm, and offloading some complex logic to software will enable fast iteration.
Since the initial planning phase, I've narrowed the project scope to a single creative robot, instead looking tofocus on developing the systems for high quality output. The video below is very close to what I'd like to acheive, maybe without the obscene drawings.
Typical "Turtle" style drawing robots are a common starting point for beginners in robotics. They're close to what I'm looking to make, except they're generally based on straight line output and hard coded paths (or following an existing path). I've been researching methods to produce smooth curved lines for the output.
The first solution is based on a standard 2 wheel robot design, but uses differential steering to accomplish curved paths. This is very good if you're hard coding specific curved shapes or arcs. Because my plan is to pass generative drawing paths over wireless, this becomes problematic.
Looking at the system as a whole, it will be much more straightforward to use existing GCode translation tools to send the robot instructions. These are generally built for x/y gantry type robots like CNC's or Laser cutters. For this project, I'd like to keep the robot as a standalone unit so it can draw at any size, rather than being limited to gantry lengths. It is possible to use x/y motion to move on a horizontal plane, though. Going this route will simplify the process of translating paths into instructions the robot can follow immensely.
This can be accomplished using omniwheels, which will not impede perpendicular motion, allowing 4 wheels oriented 90 degrees from each other. Another potential design uses a spherical wheel, interfacing with the motors much like an old ball mouse or trackball.
In my research, I found grbl, an Arduino compatible G-code translator firmware. It's intended to simplify DIY CNC produciton, but since we're intending to use X/Y axes (and a simple 2 position Z for the pen) this works perfectly.
I got a bit tripped up on selecting which motors to use for the project. Continuous Servos, Steppers and Gear Motors all seem to be recommended and applied well for similar projects. The video below explains the differences in working with each type, their advantages and disadvantages, and also shows the inner workings. Skip to 2:50 for the motor info.
Ultimately, grbl is built to work with steppers, and we had a few at the lab so they were my motor of choice. To raise and lower the pen I'll need a small stepper. Luckily there's a custom version of grbl that supports steppers as well: grbl-servo.
I spent a day at the lab getting grbl going, sending gcode out and getting a stepper to behave as expected. We initially tried smaller 5 pin steppers, but weren't able to get them working with the Easy Driver stepper control boards, so we changed to much larger 4 pin steppers that ended up working as described in the Easy Driver documentation. Somewhere in the process I managed to corrupt the signature registers of my Atmega328p, rendering it useless. I'll need to replace it before development can continue. Luckily, since my board behaves similarly to an arduino, I can continue with an arduino board in the mean time.