We presented S.A.M. to the public a little over a year and a half ago now as part of La Nuit Blanche d'Amiens. It was still a prototype, yet was received with huge applause from the crowd. We had set up a simple installation in which visitors were invited to have their photo taken in a custom-made photo booth, presented proudly at our school's main entrance. Tucked away in another part of the school building Team Spam greeted the festival peeps. We had stored the photos on a web server and grabbed them manually to send to S.A.M. for drawing. Although there was a certain fascination with the machine's quirky movements, and perhaps the added phenomenon of the selfie culture that kept the eyes transfixed on S.A.M.'s antics, we knew that this was far from a decent set up. We knew that the machine had much more to give, the possibilities for creative scenarios and graphical output were only limited by our imagination. So, the time has come to get back to that little corner of wondrous matters; the creative mind.

SAM drawing N°_002 - Team SPAM - 2016

First things first, there is a certain urgency to work on the cognitive side of the machine, that is to say the software. How S.A.M. receives instructions is of vital importance. What it does with them also but we'll leave a part of serendipity for this. To begin with, the heart of the software is based on Arduino for the electrical part and Processing for the data management part. We want to keep the Arduino part simple and it can be. Basically we have three variables for Arduino to suss out and deal with : the coordinate values for X and Y and a simple up and down variable for drawing to the surface. There will be an added variable for pressure at some point too. Ok, you got us, that makes four. In our initial program, Arduino was receiving character data for these, a char in programming parlance. Working with characters however is problematic as you need to convert floating and integer point data to byte information and for clarity this way of communicating between Processing and Arduino was an overly fastidious procedure. Ideally, what we were looking for was a means of sending variables as is to Arduino - a continuous list of coordinate data. Enter the serendipitous process of web surfing and click clucking.

It comes as no surprise that answers and solutions have a somewhat magical way of presenting themselves. For us, it came at around t minus two minutes from throwing in the towel and selling S.A.M. at our next car boot sale. We had adamantly been searching for a library that could relieve what we should call Serious Serial Syndrome. Communication protocols between softwares is an utterly unforgiving specialization, for which we have the greatest of sympathy for those who find themselves working in this field. They call it 'handshaking', but to be quite honest it's more akin to running blind with the plague or worse, enduring a cryptic form of segregation. Frustration sums up the general sentiment. Getting Processing and Arduino to communicate on the Serial port is presented as some fool hardy procedure. Sure, basic stuff works fine, like for flicking on and off a LED. Taking that a little further though becomes very quickly a rather thumping headache. To resume, you are in for a String party where everyone must talk the same language, talk only one syllable at a time and most importantly talk ONLY once one is asked to talk. So yeah, we wanted to get around that somehow and be able to send verbose messages of love to our dear S.A.M. without hindrance. T-minus two minutes and searching to install a library in Arduino, a certain VSync scrolled by. Hey wait there, what's that ? This is the VSync library for the Arduino platform. It can 'magically' synchronize variables on your Arduino with variables on other Arduinos or in your Processing sketch"

Nice find there. Time for a cig and a coffee. Now, it must be said that there was another solution out there called Buffered Serial which has more possibilities in terms of data types you can send. VSync can only manage integer type variables. It would be nice to implement that library at some point but Java ByteBuffer is a little beyond the mind bending necessities for the mo. After all, we only really need to communicate Integers for what we want to do. VSync is really a simple library to get running and communication is two way. It's pretty fast compared to our attempts in sending data the traditional way. So, that is that for now.

Organic 'Ard Artwork - Team SPAM - 2016

Another major change in S.A.M.'s little headspace is more to do with how we were sending data to our motors. Again, this seemed such a strange and unnatural procedure to send a series of HIGHs and LOWs to the motors within a loop and with delays all over to manage speed. It just seemed such a barbaric way to go about working with a motor. Sure, low level and great for the tech-savvy gurus but come on, we want methods like; move, moveTo, accelerate, speed, and other more friendly greetings. Adrien from the local FabLab slipped into one of those off-topic conversations one has on a daily basis, "and I'm sure you'll be looking into this little library for that drawing machine of yours…". After a little clicking through a series of websites from the early nineties, "…ah yes, the wonderful AccelStepper." "By 'eck son, that looks just the biz", we thought.

And so, the fantastic open source community once again comes to the rescue and we are highly indebted to all those out there that strive to share their knowledge with such great tools. Thank you. Now, with these two golden nugget finds, the communication and motor protocols were in place. The next big step in updating our little fellow lies ahead. Notably, how best to design our software in a flexible manner ? What we are looking for is a lightweight program that is extensible by others. That is to say, the essentials in place for calculating coordinate datas, how can we design a system that can incorporate other ideas from the crowd ? That is one of the main goals to pursue in the coming days, weeks, months ahead.

As a starting point, we picked out from our humble library a rare and wonderful read, "Drawing With Computers. The Artist's Guide to Computer Graphics" by Mark Wilson (Perigee Books. 1985). This book is a real treat to read and even if it deals with BASIC as the main programming language, it introduces and explains a plethora of insights for people like us looking to understand the principals of drawing with the computer. Moreover, the plotter as a technique is clearly explained in this little treasure. It may read like a relatively primitive approach compared with the technology of today, surprisingly though the fundamentals are all there, albeit without the Arduino. Team Spam look forward to divulging our progress and insights as we read on with this gem of a book which can be consulted and downloaded for your pleasure at the following address. (We do however advise you to buy the book if possible, just for the smell of it :-) )

SAM drawing n°_001 - Team SPAM - 2016

What have we learned ?

S.A.M. is not so dusty after all. After a short install we got everything up and running in no time at all. The lobotomy procedure was a little tricky coz we had to work out a few software issues to make AccelStepper work with the Pololu shield. Basically, this was a PIN configuration problem that required some calm thinking. Throwing in the towel is not a solution. Often, pure stubborn persistence is the only means for carrying on with what may seem a rather obscure and unessential objective in life. Thankfully not all things are pre-written in the scenario and some magic can play out.