It’s not adjusted for our lenses*

Cardboard DXF on Github

The AlgoBot is a wheeled robot that draws an algorithmic pattern with dry erase markers. The prototype is based on the design of an industrial CNC machine. Using a gantry system for movement in the x-direction and custom cut wheels for movement in the y-direction, the robot is capable of drawing any generated pattern. The gantry system and wheels are both driven by NEMA 17 stepper motors and the algorithmic patterns were generated using Processing. The structure can easily be scaled up to act as a custom flatbed printer that can draw on any surface.

Objective: Make a wheeled robot that draws an algorithmic pattern.

Related Work

Exploratorium Drawbot

A flat bed suspended from its corners by wire so that it can smoothly swing, and a single arm that firmly presses a marker on a sheet of paper (drawing as the bed oscillates).

Three-Pendulum Rotary Harmonograph

https://www.youtube.com/watch?v=HJYvc-ISrf8

A mechanical artifact that varies the frequency and phase of three pendulums to create different patterns.

Drawing Machine II

https://www.youtube.com/watch?v=BG9e06IWAxE

A stepper motor driven machine that creates complex guilloche patterns.

Implementation

This prototype builds on a custom CNC machine that was designed last semester. The structure was made constructed laser-cut acrylic parts and threaded rods. The build uses three 12V Nema 17 motors for movement on the X and Y axis. For the Z axis, we used one 12V solenoid to lift and release a whiteboard marker. One modification we made to the CNC-style design is adding tank style treads as a replacement for the Y axis allowing the machine to move continuously in that axis.

The wheel assembly uses two idler wheels and belt pulleys to feed a belt around the main gear, driven by a stepper motor. The outside idler wheels balance the structure so that the belt is always in contact with the dry-erase table. Embedded in each of the two idler wheels there are bearings held in place with a screw. The screw slot can be adjusted to easily manipulated the tension on the wheel belt.

We came across many hurdles while designing the wheel assembly. At first, because the drive gear was too large, the torque ratio was disturbed and the wheels could not move forward.

Another issue we ran across was that the wheels had a tendency to skew inwards because they were only supported on one side. This caused the belt to catch and sometimes make the machine slide across the table. There was also a lot of friction between the pulleys and the side wall.

To generate algorithmic patterns, we used Processing to easily visualize the patterns. The pattern shown in the video generates a random sequence of points to draws in between, based on varying functions. Other experimental patterns were tested based on the fundamentals of harmonic motion. This code was then ported to javascript, so it could be generated by the server. When the wireless Photon board starts up it connects to an external server on the network. This server generates the GCode at each request based on the line that the controller is currently on.

EX

GET  http://192.168.1.100:7000/<current_line_number>

GET  http://192.168.1.100:7000/1

Returning

G0 X100 Y100

The photon then parses the packet which contains the motor control commands, and sends them over the TX/RX pins to an Arduino controlling the motors. Every time the Photon reads the “ok” from the motor controller, it passes the next command over serial then requests the next command. The reason we used both controllers was so we could delegate motor control to one board and wireless communication to the other. This structure allows the next line of motor controls to be primed before it’s required, which essentially makes the movements smooth.

Discussion

1. upload your code
2. wait for it to compile
3. download it
4. Flash it back to the photon
5. Sometimes… this makes me angry.

This post is a walks through the process to completely bypass those steps. After the walkthrough, you should be able to:

• Write / Develop Code on your machine
• Compile that code on your machine
• Flash the compiled code to your photon over usb

Use

• No need to use the particle dev editor
  • Alternatively, no need to copy and paste the files over and over
• At the end of the compilation, before the firmware is flashed, the code is validated
  • If you don’t have internet, you can still check your code
  • If your code breaks and your photon won’t boot, you can factory reset (sortof)
    • Run the make clean all command at the bottom
• There is a way to completely bypass the entire cloud api
  • Run the  rest api locally on a computer
    • Photon -> Router -> Telcom -> Some Server at the NSA -> Particle
    • Photon -> Router -> Your Laptop
    • This means no need for  outbound internet (particle rest api etc)
  • I might post a walkthrough if someone wants it
• You hate the man

I Have not tested this walkthrough…

Let me know if anything breaks or doesn’t work, and I can help you fix it.

Requirements

This assumes you have git as well as command line tools / xcode.

If you don’t know them, you can just ask me or something.

You can follow the confusing version here, or…

OS X users can install the toolchain with Homebrew:

• brew install cmake
• brew tap PX4/homebrew-px4
• brew update
• brew install gcc-arm-none-eabi-49
• arm-none-eabi-gcc --version  (should now say v4.9.x)
• brew install dfu-util

1. GCC
2. Make
3. Device Firmware Upgrade Utilities
4. Zatig (for windows users only)
5. Git

If you’re on Windows… may the odds be ever in your favor…
No Mercy :*(

Step 1: Get the firmware

The firmware contains the code that makes the photon operate, the libraries, routines, etc. You need to download the firmware so your computer has access to all the files necessary to compile the binaries that will be written to the photons memory.

• Open the Terminal app
• Enter the following

# working_dir is whatever directory you want to develop in

cd "<working_dir>"

git clone https://github.com/spark/firmware.git

cd firmware/modules

git checkout latest

The directories should look something like this

Step 2: Nice Environment Vars

This is one I found recently, if you add the following env variable, make will automatically put the photon in dfu mode.

# /dev/tty.usbmodem12345 is the usb connected photon port

export PARTICLE_SERIAL_DEV=/dev/tty.usbmodem12345

# Set the platform default 

export PLATFORM=photon

If you want them to stay after you close the terminal, ask someone how to add them to your bash profile.

Step 3: First Build

This will clean and build the file at  firmware/user/src/application.cpp which should contain the default tinker app. It will build the system firmware as well as the app.

PUT THE BOARD INTO DFU MODE

If you didn’t put in the env variables above, or it didn’t automatically put the board into dfu mode ( orange ish yellow ), or you just wanna do it manually because you’re a badass and nobody tells you what to do…

1. Press both buttons
2. let go of one
   1. Wait…  Should immediately turn purple… Wait…
3. Should blink orange-ish yellow

make clean all PLATFORM=photon -s program-dfu

# This will transfer the code to the photon

make program-dfu

# EXAMPLE OUTPUT

[snow@snow modules]$ make all PLATFORM=photon APP=test program-dfu
/Users/snow/Documents/dev/hardware/particle/firmware/modules/photon/system-part1/makefile /Users/snow/Documents/dev/hardware/particle/firmware/modules/photon/system-part2/makefile /Users/snow/Documents/dev/hardware/particle/firmware/modules/photon/user-part/makefile
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C /Users/snow/Documents/dev/hardware/particle/firmware/modules/photon/system-part1/ all program-dfu APP=test PLATFORM=photon

.....
..... Cut out the middle man
.....

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Suffix successfully added to file
Serial device PARTICLE_SERIAL_DEV : not available
Flashing using dfu:
dfu-util -d 0x2B04:0xD006 -a 0 -s 0x80A0000:leave -D ../../../build/target/user-part/platform-6-m/test.dfu
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080a0000, size = 6812
Download [ ] 0%
Download [ ] 0%
Download [=============== ] 60% 409
Download [=========================] 100% 6812 bytes
Download done.
File downloaded successfully

The Compiled Files

Step 4: Build Options

You can use any/all of these clean all of these

make

• clean                – will remove the compiled firmwares, for (re)compile system
• all                      – compile all the changed code
• program-dfu   – flash the firmware to a photon
• -s                      – stands for silent, if you’re having issues take it out
• APPDIR           – an external directory containing code to compile
  OR
• APP                 – an app stored in “firmware/user/applications/< app_name>“

make clean all program-dfu PLATFORM=photon -s APPDIR=~/app_name

DON’T TRY AT HOME

SUPER MEGA ADVANCED

To Escape the Hardware Abstraction Layer (enabling direct hardware calls)

make clean

make APPDIR=~/app_name SPARK_NO_PLATFORM=y

More

There are more detailed docs at:

github wiki It’s hard to navigate, and I imagine it’s a bit confusing.

gettingstarted Other potentially helpful github wiki

Exploratorium – San Francisco

Explained:

It’s structure is simple: a flat bed suspended from its corners by wire so that it can smoothly swing, and a single arm that firmly presses a marker on a sheet of paper (drawing as the bed oscillates).

Chosen:

The drawing machine at the Exploratorium was the coolest thing I had ever seen when I was a kid, but naturally the line was always too long for me to ever get to use it. All you have to do to create crazy algorithmic images was swing the table at a slant so it moved in a somewhat sinusoidal motion. Every so often (when a pattern got boring or ended) you could swap out the color and swing the table again layering different patterns with different colors.

Critiqued:

Although I think that the machine was perfect as it was, I think it could create more visually interesting designs. I think the system could easily incorporate more degrees of freedom that impact the drawn pattern as well as the quality of the stroke.

For instance:

• Limiting factor
  • Possible solution to increase variability

• There is only one arm and that arm is in a fixed position
  • Multiple simultaneously oscillating arms
• The arm that holds the pen creates a relatively uniform stroke
  • The pressure could oscillate as well
• Once the bed has been put into motion, its path cannot be modified (only started or stopped)
  • Add a nudge factor to alter the pattern mid draw
• Fixed cables supporting the table restrict the set of patterns that can be created
  • The ability to adjust the bed’s center of gravity

Related:

While researching this machine, I stumbled upon the concept of a “Harmonograph” and what I assume is the precursor to the Exploratorium’s machine, the “Three-Pendulum Rotary  Harmonograph Machine”

Wikipedia: Harmonograph

Also, This is pretty cool