Skip to content

swarren/logo-turtle

Repository files navigation

"LOGO" Turtle

When I was a kid, probably the first programming language I learned was LOGO. It was/is intended as a teaching language, with an emphasis on commands that draw shapes on screen, as a way to tie programming to the real world. Some lucky people had a device (a "turtle") connected to their computer which would move around with a pen attached and physically draw the on-screen shape on paper. My school did have a turtle for their BBC micro, but I don't recall it working, or perhaps us kids simply weren't allowed to use it! Since then, I've long wanted to have my own turtle. So around Christmas 2014, I hacked one together myself.

Components

  • 3D-printed chassis. Designed in OpenSCAD; see turtle.scad.
  • Arduino Pro (Uno) for motor/servo control. Code is in turtle.ino.
  • ESP8266 for WiFi to UART bridge, for communication to the Arduino. Code is in turtle-esp8266.ino; this uses the ESP8266 Arduino port for simplicity.
  • Custom Arduino shield to mount the ESP8266 and motor driver boards; see turtle.brd. I sent this to http://oshpark.com/ for fabrication.
  • A bunch of hardware for Pololu, Sparkfun, and Amazon.
  • Python code to send commands to the Turtle. See *.py in this directory.

Apologies

A lot of this project is rather hacked together and unclean. Everything works pretty well, but the code isn't that well written or organized. The OpenSCAD model in particular was only my third use of OpenSCAD and much larger than anything I'd done before, and I put little thought into code formatting, modularity, or cleanliness.

Hardware BOM

Here's a list of the hardware I used:

Hook-up Notes

The PCB has headers to which you can connect a USB to 3.3v TTL UART adapter. There are two sets of pins; "Arduino" for programming the Arduino directly, and "WiFi" for programming the ESP8266. Once everything is programmed, you can link the Arduino and ESP8266 by placing two jumpers between the Arduino serial pins and the other pins directly adjacent to that header.

The ESP-01 module plugs into the ESP8266 header. Make sure it sticks out over the edge of the board, not pointing at the middle of the board.

The motor driver boards plug into the DRV8834 headers.

The stepper motors plug directly into the DRV8834 boards themselves.

The servo plugs into the "Servo A" header, at least with the current code. The "Servo B" header isn't currently used.

Things to Improve or Add

The pen lift mechanism needs some improvement. The hole in the piece that attaches to the pen needs to re-designed for each type of pen I use; some kind of adjustment mechanism would be useful (set-screws?). The flanges on that piece should also be longer, and a tighter fit into the chassis, to counter the pen wobble when the turtle turns. The wobble produces noticeable issues in the drawn image at corners. Perhaps some kind of conic mount might help this?

The system does not move forward/backward in a perfectly straight line. I'm not sure if this is because the rubber tires on the wheels don't yield a perfectly equal and consistent radius, or whether there's some slippage. This means that closed polygons don't quite close correctly when drawn. Assuming slippage isn't the issue, some kind of angular calibration is needed so that the turtle can auto-correct its angle and counter-act this. Alternatively, ripping out the guts of an optical mouse might allow fully automatic calibration-less adjustments!

In order to put the ESP8266 into programming mode, a certain GPIO needs to be pulled down either during power-up or reset. I forgot to put a button onto my PCB for this pull-down, or ESP8266 reset. The ESP-01 board doesn't have these either. So, I dead-bugged and hot-glued a jumper onto the ESP-01 for the GPIO pull-down, and unplugged/plugged the battery to reset it. A future board revision should add buttons or jumpers to the Arduino shield for this, or switch to an ESP8266 board that already includes buttons for this purpose.

Since I built the turtle, various new ESP8266 boards have appeared that expose many more GPIOs. If I designed this again, I'd probably ditch the Arduino and connect the stepper drivers directly to the ESP8266. I particularly fancy the Adafruit Huzzah ESP8266 board for this purpose: https://www.adafruit.com/products/2471.

Did I mention that the OpenSCAD model's code quality is terrible? Still, it produces a very nice result, so perhaps not a terrible issue.

The ESP8266 and host-side Python software aren't terribly developed. For example, IP addresses are hard-coded. My original intention was for the ESP8266 to be configurable much like a Chromecast is, and use MDNS or similar to announce itself on the network, so that the Python code could find it automatically. I never got around to this. To do this properly requires IP multicast support; something that wasn't present in the EPS8266 SDK at least in January 2015.

Some kind of GUI app might be nice; some kind of special-purpose "IDE" that allows the user to edit and run their program. This should always draw turtle output on screen, and optionally also send commands to the turtle. This would allow testing user programs without wasting paper.

An Android application! I often demo this by manually typing commands into ConnectBot over telnet, but that can get annoying.

About

A custom "turtle", a la the LOGO programming language

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published