I was in an vintage collectables store and saw a beaten up old ‘Robie the Robot’ forgotten at the back of a shelf. It’s dome was cracked and it’s remote missing. Robot collectors are quite voracious in Canberra with most robots snapped up within days. However, it seems nobody relished this rough robotic remnant, so I got it cheap.

This robot was also known as: Tandy Robie, Radio Shack Robie, Robie the Robot, Talking Robie, RS 4061, Robocom 1000, Robie Parlant, Robocom Robot (Super). There is a good write up about the robot on theoldrobots.

Tear Down

Disassembling Robie I discovered a typical 80’s remote control toy. RC circuitry oozing with leaking capacitor electrolyte and decayed protective lacquer. Apparently the built in speaker could talk, but looking at the circuitry, my guess is it functioned as a wally talky, playing a voice signal from the remote. I didn’t have the remote so I can’t confirm.

The motors were the “old style”; power hungry and weak. The Achilles heel that made all 80’s moving toys kinda nerfed.

The front screen was fake, the heads and arms were not designed to move. I will need to fix all this.

A New Brain.

Decided to throw a pi in there, with a monitor that fits the front screen and a camera because that would be cool.

For the display, a generic five dollar 2.2″ SPI TFT LCD that sells for arduino projects works well (fits just behind the front monitor panel). The stock plastic used for Robies display is way to dark for the screen to be visible, so I used a Fresnel lens instead (you can get them from the two dollar shop, sold a book magnifiers).

A front assembly was 3d printed to hold the pi, monitor and camera (such that everything lined up, and the camera could see out of the hole previously used for the frontal on/off switch.

Motorising the Head

A turntable system was created in OpenSCAD, using the awesome parametric gear library by Dr Jörg Janssen. I didn’t have a 3d printer, so I printed via the ANU Makerspace.

The turntable is driven by a 28byj-48 stepper motor, with a ULN2003 Darlington transistor array driver.

I discovered the original broken dome was most likely not a custom mould, but a security camera dome. I had some difficulty justifying a proper replacement as Australian retailers wanted over $50 for a replacement security camera dome (just the one piece of plastic). So I just replaced the head with a plastic dome from a toy shop.

The result is not quite as fast as I would like, but it was unexpectedly charming.

Getting the arms to move.

A bracket was designed to get some cheap tower-pro servos to fit aligned with the arms. The brackets neatly affixes to old circuit mounting points in the plastic. A custom servo horn will friction fitted the arms to the servo. The existing arm bearing was sanded a bit to get it to slide freely. The result is a much more expressive robot.

Whats next.

I have made files for the progress thus far available via github, encase anyone has a Robie of their own and wants to try this. https://github.com/busyDuckman/robbie

Next up I will work on:

• Drive system so Robie can move around.
• Microphone array so voice interaction is possible.
• Control software.
• Personality and human interaction.

You can download it via: https://www.thingiverse.com/thing:4300602

Background

Some manufactures put the VESA mount at the bottom of the screen, others in the middle. This can cause an issue for many situations, especially if monitors need to be used on a shared mount or in portrait mode.

Lets compare the pro’s cons of the mounting styles:

The result for a shared mount was quite noticeable.

The plate which pokes out, should connect to the monitor. The other to the VESA mount (See below).

Customisation

The mount can be customised in OpenSCAD, or via the Thingverse customiser: https://www.thingiverse.com/apps/customizer/run?thing_id=4300602.

The following parameters should be altered to suit your need.

A friend who recently acquired a CO2 laser cutter for his school sent me a message. “What is the difference between a laser that will cut metals and one that won’t?”. I thought this is a good question, as the answer will help with understanding how to work with many materials.

But before the answer will make sense, we need to revisit the basics of how a laser cutter works in more detail.

How the laser cutter works: 101

The common C02 laser cutter can be thought of as “thick” beam of IR light that moves out of a laser tube, bounces of mirrors until to get to the head. In the head it passes through a lens that focuses the beam, such that it is strong enough to ablate certain material though heat. A jet of air clears debris, and if upgraded from the piddly inbuilt compressor, will minimise scorching on materials like wood. The fact the beam is wide means that it can be bounced around off mirrors wit out imparting too much energy to one spot, such that it burns though a mirror, or the lens.

How the laser cutter works: 102

Now think of a laser cut in slow motion and zoomed in massively.  The laser hits a material. The focal point is probably beneath the surface and the beam is still a bit wide (less hot).

The area at the surface vaporises and a little pilot hole forms. This hole is like the first domino, the material near it is now deformed. This deformed material (sub millimetre area) is like the plastic left in the sun, less robust and more sensitive to light. The cut now picks up momentum and deepens as a “pool of vaporising material eating into the ground”. The air stream is ejecting loose material and anything ‘molten’ that was not instantly vaporised.

The ability to cut well is a balance of many factors, primarily the right laser strength, air flow and movement speed – for a given material at a certain thickness.

Relevant to later discussions with metal, is getting a good movement speed.

• Slow enough that the pit will work all the way through, before the beam moves on.
• Fast enough that the material is not given too much heat (see diagram to right, not all the beam is vaporising goodness and its not all equal in strengths.
  • From the parts of the beam not near the focal point that are not hot enough .
  • From outer areas of the beam not as intense
• Different lenses will help with thicker materials, butt you first limitation is you will need more power for thicker materials. Otherwise you will need to move at a slow speed that brings many other problems of heat dissipation.

Reading the above may lead you to think you will need to get the most powerful laser cutter you can afford, for those times when you want to do a thick material. But… power is a two edged sword. The laser will only fire at a minimum of say 40%. So your 120W laser that will get you through 20mm acrylic, won’t be any good for etching designs on clothing (it will punch straight through at it minimum of 48W).

Problems that will affect metal

• Many metals are reflective of IR beams (C02 lasers), preventing even etching of the surface.
  • NB: other lasers, such as solid state lasers which work with a different wavelength will be several times more efficient than C02 lasers for most metals.
• Metal is a heat sink, it will draw heat away from the cut. Preventing the laser beam from melting any of the metal, or forming the initial pit.
• Many metals are not cool/safe in gaseous form. You may need venting.

Etching metal

Your enemy for etching, is not the heat conductivity of the metal, it’s the fact it reflects.
On cutters around your size it is often possible to etch certain metal. You will need to paint the surface with something (there are products that are sold for this purpose, but some people just use black $3 fiddly bit paint from buntings). The pit will form in the paint and you will get sufficient heat in to mark the metal. But then go no further down.

Cutting metal

Generally laser cut metal is not ablated/vaporised (turned to gas) like other materials. It is instead it is melted (turned to liquid), and blown out of the way by forced airflow. This is sometimes referred to as ‘melt and blow’ cutting. It is messy and provides issues that can damage a machine:

• Bits of molten metal can settle on the lens, this will absorb heat that the lens would otherwise transmit. The lens will now heat up and be damaged / burnt though.
• The metal / molten metal can reflect focused beam of light back at the lens. This can damage the lens, because the amount of IR radiation passing though it is now double.
  • The focused light can even propagate back along the mirrors and into the laser tube (damaging the very expensive parts of the machine).

Its worth mentioning that metal needs a lot more power to get the piloting pit going. And the pit is not a nice vaporised area with laser friendly material next to it. It’s a stubborn pool of liquid that sits in the way of your laser. This means cutting requires bigger lasers, or one or more assisting technologies to reduce the necessitated “bigness” of your laser.

Such assisting technologies, for CO2 lasers, may include.

• High pressure gas, to blow the molten metal out of the hole.
• Blowing Oxygen or Nitrogen into the cut to make things more efficient.
• Using a more focused beam to get the metal to melt before heat dissipation sets in.
• A lens that moves, so that the focal point travels with your pit as it goes down.

As some lasers can be coerced into cutting metal, why is it not more common?

Firstly, the risk to the machine means many operators don’t feel it is worth it.

But there are other issues:

• Solid state lasers are becoming more popular for cutting metal over the use of a large C02 Laser.
• The cut speed of lasers on metal can be slow, and the depth of cut limited.
• Tuning air/ laser/ lens /speed parameters is more difficult, and the results are not always a clean cut for inexperienced operators.

But more importantly there are many more attractive  alternatives for cutting of metal, including water jet cutting and CNC milling.

Further reading:

For clarity I simplified and glossed over some less important concepts in the above explanation.

The following industry articles explore things in more depth:

• Laser comparison – cutting speed and rate of feed. http://jmtusa.com/laser-comparison-cutting-speed-and-rate-of-feed/
• Lasing reflective metals http://www.fsmdirect.com/cutting/laser-cutting/326-lasing-reflective-metals
• Back to basics: The subtle science of burr-free laser cutting. https://www.thefabricator.com/article/lasercutting/back-to-basics-the-subtle-science-of-burr-free-laser-cutting

To speed things up, I wanted to auto translate these bundles, and then have others look over and refine the translations later.

Looking at what already existed, I was not excited.

• I did not want some heavy weight application.
• I found some simple auto translation tools, some free-ish, some pay-per-say. But they did not support java resource bundles.
• I did like translate shell a lot, but it needed integration into the java resource bundle ecosystem
• Very few tools supported maven
• Nothing “just worked”

So I created a maven plugin (SpeakingDuck) to translate resource bundles. SpeakingDuck will use whatever translation tool you configure it to run with.

Find it on github:   https://github.com/busyDuckman/speakingDuck

or install via the Maven Repository, or via reference in your pom.xml.

The following pom.xml will cause German, Chinese, Spanish and Russian resource bundles to be maintained (updated for new keys) every compile.

<build>
    <plugins>
        <plugin>
            <groupId>com.busyducks</groupId>
            <artifactId>speakingDuck-maven-plugin</artifactId>
            <version>0.9.7</version>
            <configuration>
                <call>trans -b :$CALL_LANG $TEXT_ESCAPED_QUOTED</call>
                <translations>
                    <translation>
                        <bundlePattern>./src/main/resources/generalText_$FILE_LANG.properties</bundlePattern>
                        <sourceLang>en:en</sourceLang>
                        <destLangs>de:de, zh:zh, es:es, ru:ru</destLangs>
                        <replaceExistingKeys>false</replaceExistingKeys>
                    </translation>
                </translations>
            </configuration>

            <executions>
            <execution><goals><goal>translate</goal></goals></execution>
            </executions>
        </plugin>
    </plugins>
</build>

The translations are generated via translate shell (because of the call “trans -b”), you will need to install translate shell yourself for this to work.

Recently I have been building a train set, I will blog the progress, in six parts, highlighting how I get certain things done.

• Part 1 – Design and Woodwork
• Part 2 – Electrical design.
• Part 3 – Mechanical servicing
• Part 4 – Construction
• Part 5 – Painting of buildings and natural elements.
• Part 6 – Embedded computing and setup of DCC controllers.

Base Setup

Firstly I am designing a track that is movable from a storage hook on a garage, to a pool table in my living. This requires a baseboard, which I constructed with three cross breams, an MDF sheet and Tasmanian oak edging.

Designing the layout.

I used  the Simple Computer Aided Railway Modeller (SCARM) to plan my layout.  A read over an old German railway construction guide gave me a lot of practical hints as to what made a good layout.

Layout as viewed from the front.

layout as viewed from the rear.

Setting up the levels for hills and track.

The frame work is wood and MDF. Before getting into some neat tricks, lets look at a time lapse.

Steps:

• The track plan is printed 1:1 on a standard printer using 40 pieces of paper, there is a trick to doing this in SCARM.
• The layout is placed on the board and a toy train is run over it, just to get a feel for what it will be like to interact with.
• Spacers are cut on a table saw, so that the MDF can be set to the correct height for the track.
• Contours are cut from MDF using a jigsaw and the track carver up and placed on top of the MDF.
• Everything is assembled, a brad gun and wood glue is a quick way to get this done. I screw down the MDF, without glue, so I can  run wires later.

Train storage Cabinet.

I built a cabinet to hold the trains and keep them dust free.

• It is build like a picture frame, but I used the table saw to create a ‘grove cut’ on the frame.
• The grove allows two pieces of acrylic to slide like doors in the frame.
• If your not 100% on table saws, this video is terrific. (10:20 explains grove cuts).
• Using acrylic instead of glass lets me insert the doors after assembly (acrylic bends)
• The wood is Tasmanian oak (to match the table) and the finish is Linseed oil followed by a glossy furniture polish.
  • Frame Cutting  in Tasmanian oak is fraught with random peril. If you cut the long edges first, you can reuse failed cuts for the short edges, saving timber.

Could we get street lights to start flashing 30 seconds before an ambulance is due to come through?

All traffic would have time to organise itself into one lane and emergency vehicles could proceed without obstruction. This seems easy to achieve using existing

Compiler errors should link through to concise explanations or solutions on  stackoverflow, or some error code explanation wiki.

Lats face it, this will speed up things a bit; especially when learning a new language.

Give random rich/powerfull people weird handshakes. See if you can pass for Illuminati.

Rule of thumb. If you would you would not be happy with this kind of material on the surface of whatever you are coating, remove your finger prints.

• So a very thin coat of paint is 0.02mm, but often thicker.  So wash your hands, then it’s probably OK to touch. But don’t “Pizza and Paint”.
• Thermal paste on your CPU is 0.07mm  to 0.12mm thick, So Pizza hands are a definite problem. A single normal finger print may well produce a small but noticeable effect to cooling. A well handled CPU with a few prints is probably not good, you would not leave scraps of plastic wrap on the CPU after all.
• Some glues may dilute your finger print and not care (super glue). While other (silicone adhesives) will probably bond poorly.
• Solder – The NASA soldering standards (NASA_STD_8739 .3) state: “When handling metal surfaces that are to be soldered is unavoidable, clean, lint-free gloves or finger cots shall be used. “. Many commercial soldering standards also follow this advise for handling of both solder and parts.
  • Whats interesting is that some manufactures are particularly concerned about what is on your hands (moisturisers and hand lotions cited as being particularly problematic to solder).
  • The finger print contamination of solder joints is often resolved by just keeping the joint hot until the solder takes. This extra heating burns of enough contaminate to allow solder to flow, but can damage components amongst other problems.
  • UPDATE: The new IPC standards (IPC-J-STD-001ES), which NASA, and many other companies, have adopted, don’t mention fingers or gloves specifically. They only broadly reference that handling mechanisms stall not contaminate the board or parts.

OpenXeen is a game engine rewrite I have been working on for Might and Magic III, IV and V . It’s opensource and still under development.

Currently it brings up monsters, objects, and most of the outdoor environment.

Resources:

• Git: here
• Wiki: here
• Development Blog: here
• State of openXeen features
• Interested in contributing
• Xeen development related links
• The xeen wiki (the groundwork reverse engineering project that OpenXeen stands on top of)

Status:

• Software is not ready for release.
• At the moment it can:
  • Parse the cc files and open some graphics and audio files
  • Parse some map info
  • Create proxies of all files in cc files.
  • Display a simple rendering of some xeen components. NB: First run will take some time, proxy files are being created.

Might and magic III (Isles of Terra) support.

I have got the MAMIII GUI up, and decoded some sprites. Not much more to show yet.

I am by no means a proficient at reverse engineering software, however I wrote up a quick primer on how I was using the cpu logs generated by the dosbox debugger, to recover some MM3 data.

Related Links

Tools:

• Xeen Utilities
• MM3 Dumper

Mods:

• respawn mod

Xeen Info Gneral:

• Xeen Wiki: http://xeen.wikia.com/wiki/Xeen_Wiki
• CC file format: http://rewiki.regengedanken.de/wiki/.CC
• MM3 CC file: http://rewiki.regengedanken.de/wiki/MM3.CC
• MM3 CC file LHZ compression: http://blog.rewolf.pl/blog/?p=1202

Xeen modding

• MM3 modding page: http://jeffludwig.com/mm3/resources.php

Xeen Cluebooks

• MM3: http://www.abandonia.com/files/extras/25850_game_extra_1.pdf
• WoX: http://www.abandonia.com/files/extras/26962_Extra%20document_Cluebooks.zip

MM3 Releases

• DOS: http://www.abandonia.com/en/games/1035/Might+and+Magic+III+-+Isles+of+Terra.html
• Amiga: http://www.lemonamiga.com/?game_id=3142
• SNES

WoX Releases

• Dos: http://www.abandonia.com/en/games/482/Might+and+Magic+IV+and+V+-+World+Of+Xeen.html
• Mac:
• PC-98

“Vintage” Computing:

• File Formats from the C64: http://petlibrary.tripod.com/formats.htm

Reference Code

• LHZ https://github.com/rwfpl/rewolf-mm3-dumper
• Xbr

Other WoX Engines:

• DeamMasters Xeen engine in scumvm https://github.com/dreammaster/scummvm/tree/xeenand https://github.com/roguevm/roguevm/find/xeen

Articles on the History of MaM

• 5 pages covering the series:http://www.hardcoregaming101.net/mightandmagic/mightandmagic3.htm

Reverse Engineering Dos Games:

• A good primer http://wiki.scummvm.org/index.php/HOWTO-Reverse_Engineering
• Dosbox 0.74 debug build: http://source.dosbox.com/dosbox-74-debug.exe
• Bridging IRA to dosbox https://github.com/wjp/idados
• Driving the dosbox debugger: http://www.vogons.org/viewtopic.php?t=3944

Code Audit, first release – v0.1.0 alpha

(From my dev blog)

With this first release I wanted to take stock of where the code is at, where I am heading and what my time is being spent on. I have a job and a family, so openXeen is largely coded in at night or when I can grab 5 minutes. This forces me to code in a manor ‘resistant to interruptions’ (finish one logical area at a time, use a fully thought out architecture).

What I also need to do Is audit how much time I spend on what. Which is where this line of code by package breakdown comes into play. It breaks my 8.8k lines of code down, telling me where my effort has been spent. I aim to update this graph at every delivery milestone. What I learnt:

• 1/3 of the code is concerned with reading and loading files contained in the .cc archives (reds)
• 1/3 of the code is ‘toolbox code’ (oranges), stuff that is not relevant to xeen, and ideally would have been provided by java or a 3rd party library.
• 1/6 is in game mechanics (blues), arguably this is an over investment in mechanics early on. But I am prioritising having a ‘game’ by the end of the year, not a tech demo.
• 1/6 is in rendering (greens). The rendering code has been kept as simple as possible. I love to write rendering engines, and know this is a trap. You spend far too much time on rendering ‘goodies’, then your engine was built without respect to the actual game (because the game did not exist yet) and you have nothing to show in your render. Your’e exhausted, and sometimes coded into a corner.

So I present the code, updated to work on the latest platform. As per the last article:

• This is not an intro to progmem article. The readership level is set at those who are already familiar with the arduino PROGMEM documentation here and the use of the F() macro and __FlashStringHelper*.
• Its’ designed as a reference on how to accomplish many different common tasks in PROGMEM.
• It’s  here  to save you the “lets see how to make this work” time and communicate common pitfalls.
• The code is well documented, so you should be able to find what you need quickly.
• There is data declarations out front,  assorted unit tests in setup() and a simple unit testing framework at the end of the file.
• Some of the examples have  //JBYCDMUS after the line. This stands for “just because you can, doesn’t mean you should” implying It works but is not recommended.
• To use this search for the method you need to use, and see it running in working tested code.

//----------------------------------------------------------------------------------//
//                                    BUSYDUCKS.COM                                 //
//                           _         _                  _                         //
//                         ( o)>     ( o)<     __       ( o)<                       //
//                      ____\\    ____\\   __ (.. )  \\\_\\                         //
//                 ~~~~\_///__)~~\_///__)~~\_\\V__)~~\_____)~~~~~                   //
//                                                                                  //
//                            Making you pro-duck-tive                              //
//                                                                                  //
//  Author: Duckman   Date: 08/02/16   Ver: 1.6   Licence: Creative Commons (by-sa) //
//                                                                                  //
//  Demonstrates the use of PROGMEM.                                                //
//  Compile with Arduino environment 1.6 or later                                   //
//                                                                                  //
//  Permision given to freely copy/paste "code snippets" into your own code. For    //
//  other uses (e.g. derivative works) the Creative Commons Attribution Share-      //
//  alike license applies (cite busyducks.com). This means comerical use is ok.     //
//----------------------------------------------------------------------------------//

#if !(defined(ARDUINO) && ARDUINO >= 140)
#include <environment.h>
#endif

void setTestName(const __FlashStringHelper* name);
void setTestName(const char *name);
bool assert(bool isTrue, Print *outStream=NULL);
void pass();
void fail(Print *outStream=NULL);
void printTestSummary(Print *outStream);

/*
char,                             (1 byte)    -127 to 128 also letters i.e. 'a'     pgm_read_byte
unsigned char, byte               (1 byte)    0 to 255                              pgm_read_byte
int, short                        (2 bytes)   -32,767 to 32,768                     pgm_read_word
unsigned int, unsigned short      (2 bytes)   0 to 65,535                           pgm_read_word
long                              (4 bytes)   -2,147,483,648 to 2,147,483,647       pgm_read_dword
unsigned long                     (4 bytes)   0 to 4,294,967,295                    pgm_read_dword

For ATMEGA based arduino's double is the same as float
float, double                     (4 bytes)   -3.4028235E+38 to 3.4028235E+38       pgm_read_float
*/

//--------------------------------------------------------------------------------------------------------------
// Data structures for test
//--------------------------------------------------------------------------------------------------------------
struct Person
{
  int height;
  char *name;
  int age;
  Person *spouse;
};

//--------------------------------------------------------------------------------------------------------------
// Test Data Sets
//--------------------------------------------------------------------------------------------------------------
#define BYTE_TEST_PATTERN_DATA {0, 1, 2, 3, 4, 9, 15, 16, 21, 31, 32, 64, 100, 201, 212, 255, 7}
#define BYTE_TEST_PATTERN_SIZE 17
#define MAX_STRING_SIZE 100

//--------------------------------------------------------------------------------------------------------------
// Test Data
//--------------------------------------------------------------------------------------------------------------
//  regular data
const byte  progMem_ucharArray[]     PROGMEM = BYTE_TEST_PATTERN_DATA;
const byte  progMem_uchar            PROGMEM = 130;
const int   progMem_int              PROGMEM = -3021;
const long  progMem_long             PROGMEM = 2000000001;
const float progMem_float            PROGMEM = 3.14159265359;
const char  progMem_string[]         PROGMEM = "Snollygoster";
const char  progMem_string2[]        PROGMEM = "Problem Alchemist";
const char  progMem_string3[]        PROGMEM = "Lead Paradigm Architect";
const char  progMem_emptyString[]    PROGMEM = "";
const float progMem_floatArray[2][5] PROGMEM = {{0.2, 0.1, 0.5, 0.7, -3.2},
                                               {0.4, 0.2, 1.0, 1.4, -6.4}};

//  NB this used to be in the form "PROGMEM const char *progMem_stringArray[] =",
//  now the extra const is required.
PROGMEM const char *const progMem_stringArray[] =
{   
  progMem_string,
  progMem_string2,
  progMem_string3
};

//  STRUCTS
//  this line is a foward decleration, it allows person1 to create a valid pointer 
//  to person2 even though person2 is not defined yet.
extern const Person progMem_person2;

const char     _name[]         PROGMEM = "Papa Smurf";
const Person   progMem_person  PROGMEM = {189, (char *)_name, 32, (Person*)&progMem_person2};
const char     _name2[]        PROGMEM = "Muma Smurf";
const Person   progMem_person2 PROGMEM = {160, (char *)_name2, 41, (Person*)&progMem_person};

//--------------------------------------------------------------------------------------------------------------
// Stats
//--------------------------------------------------------------------------------------------------------------
long passCount = 0;
long failCount = 0;
long countAtLastNameChange = 0;
char currentTestName[64];

//--------------------------------------------------------------------------------------------------------------
// setup and loop
//--------------------------------------------------------------------------------------------------------------
void setup() 
{
    byte localData[] = BYTE_TEST_PATTERN_DATA;
    char buffer[MAX_STRING_SIZE];
    
    Serial.begin(9600);
    
	//JBYCDMUS = just because you can, doesn't mean you should
	
    Serial.println(F("---------------- single variable tests"));
    setTestName(F("single variable tests"));
    assert(  progMem_uchar == 130                                       ); //JBYCDMUS
    assert(  pgm_read_byte(&progMem_uchar) == 130                       );
    assert(  progMem_int == -3021                                       ); //JBYCDMUS
    assert(  progMem_long == 2000000001                                 ); //JBYCDMUS
    assert(  (int)(pgm_read_float(&progMem_float)*10000) == 31415       );
    
    Serial.println(F("---------------- array tests"));
    setTestName(F("array tests"));
    for(int i=0; i< BYTE_TEST_PATTERN_SIZE; i++)
    {
        assert(   pgm_read_byte(&progMem_ucharArray[i]) == localData[i] );
    }
    for(int i=0; i<5; i++)
    {
        //  the easy way of accessing the array
        float a = pgm_read_float(&progMem_floatArray[0][i]);
        //  another way of accessing the array same as [1][i]
        float b = pgm_read_float(((unsigned int)progMem_floatArray)+(5+i)*sizeof(float));
        a = a * 2;
        //  to check two floating points are "equal"
        assert (abs(a - b) < 0.0001                                     );
    }

    
    Serial.println(F("---------------- struct tests"));
    setTestName(F("struct tests"));
    assert(  progMem_person.height == 189                               ); //JBYCDMUS
    assert(  pgm_read_byte(&progMem_person.height) == 189               );
    //  NB: this used to be (prog_char *)pgm_read_word(&progMem_person.name) but prog_char is depreciated
    assert(  strcmp_P("Papa Smurf", (char PROGMEM *)pgm_read_word(&progMem_person.name)) == 0 );
    assert(  pgm_read_byte(&progMem_person.age) == 32                   );
    assert(  progMem_person.age == 32                                   ); //JBYCDMUS
    
    //  get person1's spouse
    Person *p= (Person *)pgm_read_word(&progMem_person.spouse);
    assert(  p == &progMem_person2                                      );
    assert(  pgm_read_byte(&p->age) == 41                               );
    //get person2's spouse
    p = (Person *)pgm_read_word(&progMem_person2.spouse);
    assert(  p == &progMem_person                                       );
    assert(  pgm_read_byte(&p->age) == 32                               );

    Serial.println(F("---------------- memory operation tests"));
    setTestName(F("memcmp [memory compare]"));
    //  compares len bytes of the memory s1 and flash s2
    byte data[] = BYTE_TEST_PATTERN_DATA;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) == 0 );
    data[BYTE_TEST_PATTERN_SIZE-1] = 0;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) < 0  );
    data[BYTE_TEST_PATTERN_SIZE-1] = 255;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) > 0  );
    
    //  copy len bytes from flash to SRAM
    memset (data, 0, BYTE_TEST_PATTERN_SIZE);
    assert(  memcpy_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) > 0  );
    assert(  memcmp(data, localData, BYTE_TEST_PATTERN_SIZE) == 0            );
    
    Serial.println(F("---------------- string function tests"));
    
    //  ---- strcmp & strncmp Compare two strings
    setTestName(F("strcmp [string compare]"));
    assert(  strcmp_P("Snollygoster", progMem_string) == 0                ); 
    assert(  strcmp_P("sNollyGostEr", progMem_string) != 0                );
    assert(  strcmp_P("Bug", progMem_string) < 0                          );
    assert(  strcmp_P("Zoo", progMem_string) > 0                          );
    
    setTestName(F("strncmp [string compare, first n chars]"));
    assert(  strncmp_P("Snollyfoobar", progMem_string, 6) == 0            );
    assert(  strncmp_P("sNollyGostEr", progMem_string, 6) != 0            );
    assert(  strncmp_P("Bug", progMem_string, 3) < 0                      );
    assert(  strncmp_P("Zoo", progMem_string, 3) > 0                      );
    
    //  ---- strcasecmp & strncasecmp, Compare two strings, ignoring case  
    assert(  strcasecmp_P("Snollygoster", progMem_string) == 0            );
    assert(  strcasecmp_P("sNollyGostEr", progMem_string) == 0            );
    assert(  strcasecmp_P("Bug", progMem_string) < 0                      );
    assert(  strcasecmp_P("Zoo", progMem_string) > 0                      );
    
    setTestName(F("strncasecmp [string compare ignoring case]"));
    assert(  strncasecmp_P("Snollyfoobar", progMem_string, 6) == 0        );
    assert(  strncasecmp_P("sNollYGostEr", progMem_string, 8) == 0        );
    assert(  strncasecmp_P("Bug", progMem_string, 3) < 0                  );
    assert(  strncasecmp_P("Zoo", progMem_string, 3) > 0                  );
    
    //  ---- strcpy, strlcpy & strncpy: makes a copy of a string
    setTestName(F("strcpy [copy a string]"));
    clear(buffer, MAX_STRING_SIZE); //empty string buffer
    assert(  strcpy_P(buffer, progMem_string) == buffer                   );
    assert(  strncmp(buffer, "Snollygoster", MAX_STRING_SIZE) == 0        );
    
    setTestName(F("strlcpy [copy a string of maximim size, ensure null terminated result]"));
    char smallBuffer[12]; //  not long enough to hold "Snollygoster" AND the final null terminator
	
    clear(buffer, MAX_STRING_SIZE); //  empty string buffer
    clear(smallBuffer, 12); //empty string buffer

	
    assert(  strlcpy_P(buffer, progMem_string, MAX_STRING_SIZE) == 12     );
    assert(  strlcpy_P(smallBuffer, progMem_string, 12) == 12             );
    assert(  strcmp(buffer, "Snollygoster") == 0                          );
    //  This is the difference between strlcpy and strncpy, the whole string was not copied 
    //  to ensure a null terminator was present
    assert(  strcmp(smallBuffer, "Snollygoste") == 0                      );
	
    
    setTestName(F("strncpy [copy a string of maximim size, null terminate iff space allows]"));
    clear(buffer, MAX_STRING_SIZE); //  empty string buffer
    assert(  strncpy_P(buffer, progMem_string, MAX_STRING_SIZE) == buffer );
    assert(  strcmp(buffer, "Snollygoster") == 0                          );
    
    //  ---- strcat, strlcat & strncat: Concatenate two strings
    setTestName(F("strcat [join two strings]"));
    strcpy(buffer, "Chief ");
    assert(  strcat_P(buffer, progMem_string) == buffer                   );
    assert(  strcmp(buffer, "Chief Snollygoster") == 0                    );
    
	
    setTestName(F("strlcat [join two strings, limiting final size, ensure termination]"));  
    strcpy(smallBuffer, "Chief "); //smallBuffer is only 12 characters
    //  NOTE strlcat_P n = sizeof destination; while strncat_P n = number of chars to copy
    assert(  strlcat_P(smallBuffer, progMem_string, 12) == 18             );
    //  12th character is the nul terminator
    assert(  strcmp(smallBuffer, "Chief Snoll") == 0                      );
    
    strcpy(buffer, "Chief "); //smallBuffer is only 12 characters
    assert(  strlcat_P(buffer, progMem_string, MAX_STRING_SIZE) == 18     );
    assert(  strcmp(buffer, "Chief Snollygoster") == 0                    );
	
    
    setTestName(F("strncat [join two strings, limiting final size]"));
    strcpy(buffer, "Chief ");
    //  NOTE strncat_P n = number of chars to copy; while strlcat_P n = sizeof destination
    assert(  strncat_P(buffer, progMem_string, 6) == buffer               );
    assert(  strcmp(buffer, "Chief Snolly") == 0                          );    
	
    
    //  ---- strlen & strnlen: Finds the length of the string (searches for the null terminator)
    setTestName(F("strlen [find the length of a string]"));
    assert(  strlen_P( progMem_string) == 12    );
    setTestName(F("strnlen [find the length of a string, limited to n]"));
    assert(  strnlen_P( progMem_string, 6) == 6                           );
    assert(  strnlen_P( progMem_string, MAX_STRING_SIZE) == 12            );
    
    //  ---- strstr: searches s1 for the first occurrence of (the substring) s2
    setTestName(F("strstr [find a string inside another string]"));
    //  one item to find
    strcpy(buffer, "A Snollygoster sounds like something you would find in a handkerchief.");
    assert(  strstr_P(buffer, progMem_string) == &buffer[2]               );
    assert(  strstr_P("foobar", progMem_string) == NULL                   );
    //  what is defined to happen when searching an empty/null strings
    strcpy(buffer, "foobar");
    assert(  strstr_P(buffer, NULL) == NULL              );
    //  this is why "if(strstr_P(s1, s2) != null){...}" is a bad idea!"
    assert(  strstr_P(buffer, progMem_emptyString) == buffer              );
        
    Serial.println(F("---------------- done"));
    if(failCount > 0)
    {
        Serial.print(passCount); Serial.println(F(" test(s) passed"));
        Serial.print(failCount); Serial.println(F(" test(s) FAILED"));
    }
    else
    {
        Serial.print(F("All tests passed (")); Serial.print(passCount); Serial.println(F(" tests rum)"));
    }
}

void loop() 
{
}

void clear(char *buffer, int len)
{
    memset(buffer, '\0', len);
}

//----------------------------------------------------------------------------------------------------------
// Testing framework data
//----------------------------------------------------------------------------------------------------------
#define TEST_NAME_BUFFER_LEN (64)
extern long passCount;
extern long failCount;
extern long countAtLastNameChange;
extern char currentTestName[TEST_NAME_BUFFER_LEN];



//----------------------------------------------------------------------------------------------------------
// Testing framework
//----------------------------------------------------------------------------------------------------------

template<typename T>
__attribute__ ((noinline)) bool assert_EQ(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a == b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" != 0x"));
		outStream->println(b, HEX);
	}
}



template<typename T>
__attribute__ ((noinline)) bool assert_NEQ(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a != b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" != 0x"));
		outStream->println(b, HEX);
	}
}

template<typename T>
__attribute__ ((noinline)) bool assert_GT(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a > b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" <= 0x"));
		outStream->println(b, HEX);
	}
}
template<typename T>
__attribute__ ((noinline)) bool assert_LT(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a < b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" >= 0x"));
		outStream->println(b, HEX);
	}
}

void setTestName(const __FlashStringHelper* name) 
{
	currentTestName[0]= 0;
	if(name != NULL)
	{
		strlcpy_P(currentTestName, (const char PROGMEM *)name, TEST_NAME_BUFFER_LEN);
	}
	
	countAtLastNameChange = passCount+failCount;
}

void setTestName(const char *name)
{
	currentTestName[0]= 0;
	if(name != NULL)
	{
		strlcpy(currentTestName, name, TEST_NAME_BUFFER_LEN);
	}
	
	countAtLastNameChange = passCount+failCount;
}

bool assert(bool isTrue, Print *outStream)
{
	if(isTrue) 
	{
		pass();
		return true;
	}
	else 
	{
		fail(outStream);
		return false;
	}
}

void pass()
{
	passCount++;
}

void fail(Print *outStream)
{
	if(outStream != NULL)
	{
		outStream->print(F("TEST FAILED: "));
		if(currentTestName != NULL)
		{
			int localTestNum = (passCount + failCount) - countAtLastNameChange + 1;
			outStream->print(F("(")); 
			outStream->print(currentTestName); 
			outStream->print(F(" [test ")); 
			outStream->print(localTestNum);
			outStream->print(F("])"));
		}
		outStream->println();
	}
	failCount++;
}

void printTestSummary(Print *outStream)
{
	if(outStream != NULL)
	{
		if(failCount > 0)
		{
			outStream->print(passCount); Serial.println(F(" test passed"));
			outStream->print(failCount); Serial.println(F(" test FAILED"));
		}
		else
		{
			outStream->print(F("All tests passed (")); Serial.print(passCount); Serial.println(F(" tests run)"));
		}
	}
}

I believe strongly in plotting the data that I obtain, because plots tell you a story and they don’t mislead you like summary statistics can.

Often I want to plot data the arduino has acquired, but I find existing solutions don’t suit my needs. So I went out and made my own solution which writes a GNUPlot script in response to plot commands. I integrated the library with my general Arduino Toolbox (WDArduinoLib) and am releasing it under the GNU 2.0 License.

Goals

• Professional graphics
• Graphs manually editable after plotting for change colours etc.
• Arduino outputs data that  other people can defiantly grab and use (just paste into a cloud based GNUPlot terminal)
• Allow embedded linux system to offload the plotting of graphs from arduino collected data
• Easy straight forward API
• Linux, Windows and Mac compatible.
• Quality API documentation

Features

• Configurable output
  • You can use a Serial Port, SD-Card,  Telnet, TCP-IP, IrDA, whatever. So long as it derives from the Arduino Print class (ie has Print and Println()) this library can output a graph to it
• Uses GNUPlot as a server to execute the plot script this API outputs.
  • GNUPlot is the standard for scientific publication, it outputs presentable graphics ready for both websites, and software manuals.
  • GNUPlot has been around forever (1986) and is still actively developed.
  • GNUPlot can run on the Raspberry pi, PC, Mac or even online via http://plotshare.com/
• Extensible
  • Easily over-rideable classes to add new plot types or different output terminal (eg Matlab)
• Built in quality colour palettes designed for graphing.
  • Sample palettes for showing importance, of keeping different coloured categories at the same intensity.
  • Spectral palettes , optimised for on-white graphing.
  • Colour-blind compatible palettes .
  • Can still use arbitrary 24bit RGB colours if you like.
• Unit tested library to support quality software development
• Template driven code designed for maximum data flexibility
• Memory Efficient.
  • Use of progmem strings supported throughout.
• Useful, stable data format that does not rely on someone’s pet project still existing in 5 years time.
• All input, including text, is validated.

Examples

This library is simple to use and produces clean results with minimal configuration. I present several basic examples that show the API in use and the results obtained.

Example: Basic Line Graph

Line plots of time series data are probably the most important feature any graphing API targeted for micro-controllers can offer. This code creates such a plot. It demonstrates the use of multiple line styles.

//main
GNUPlotLineGraph gnuLinePlotter(&Serial);
PlotDampenedSineWaves(gnuLinePlotter);

//method
void PlotDampenedSineWaves(SerialGraph& plot)
{
	//setup graph
	plot.newGraph();
	plot.enableSaveImageFile(true);
	plot.setTitle(F("Dampened Sine Wave"));
	plot.setXAxisName(F("Time (Sec)"));
	plot.setYAxisName(F("Voltage (V)"));

	//setup series
	plot.setSeriesName(0, F("Slow decay"));
	plot.getLineApperance(0)->setLineStyle(LineStyles::SolidLine);
	plot.getLineApperance(0)->setLineWidth(4);
	plot.getLineApperance(0)->setRGB(GraphColorsSchemeBlues::Blue1);


	plot.setSeriesName(1, F("Medium decay"));
	plot.getLineApperance(1)->setLineStyle(LineStyles::DashedLine);
	plot.getLineApperance(1)->setLineWidth(3);
	plot.getLineApperance(1)->setRGB(GraphColorsSchemeBlues::Blue2);

	plot.setSeriesName(2, F("Quick decay"));
	plot.getLineApperance(2)->setLineStyle(LineStyles::DotedLine);
	plot.getLineApperance(2)->setLineWidth(2);
	plot.getLineApperance(2)->setRGB(GraphColorsSchemeBlues::Blue3);
	
        //plot graph
	for(int i=0; i<=720; i+=3)
	{
		float c = cos(DEG_TO_RAD*(float)i); 
		float y1 = Dampen(i, c, 1, 1.0/360.0); 
		float y2 = Dampen(i, c, 1, 1.0/240.0); 
		float y3 = Dampen(i, c, 1, 1.0/180.0); 

		plot.plotDatumXYn(i, y1, y2, y3);
	}
	plot.finishGraph();
}

Example: Plotting Points (Scatter Plot)

A scatter plots, with styles colours and trimmings.

//main
GNUPlotPointGraph gnuPointPlotter(&Serial);
PlotPointNoise(gnuPointPlotter);

//method
void PlotPointNoise(SerialGraph& plot)
{
	//setup graph
	plot.newGraph();
	plot.enableSaveImageFile(true);
	plot.setTitle(F("Sine Waves with Noise"));
	plot.setXAxisName(F("Time (Sec)"));
	plot.setYAxisName(F("Voltage (V)"));
	plot.setShowGrid(true);

	//setup series
	plot.setSeriesName(0, F("Pin 1"));
	plot.getLineApperance(0)->setMarkerStyle(LineMarkers::SquareMarker);
	plot.getLineApperance(0)->setRGB(0xff0000);

	plot.setSeriesName(1, F("Pin 2"));
	plot.getLineApperance(1)->setMarkerStyle(LineMarkers::CrossMarker);
	plot.getLineApperance(1)->setRGB(0x00ff00);

	plot.setSeriesName(2, F("Pin 3"));
	plot.getLineApperance(2)->setMarkerStyle(LineMarkers::CircleMarker);
	plot.getLineApperance(2)->setRGB(0x0000ff);
	
        //plot graph
	for(int i=0; i<=720; i+=5)
	{
		float c = cos(DEG_TO_RAD*(float)i); 
		float y1 = c + Dampen(i, ((float)(random(100)-50)) *0.1, 1, 1.0/240.0); 
		float y2 = c + Dampen(i, ((float)(random(100)-50)) *0.1, 1, 1.0/180.0)-2; 
		float y3 = c + Dampen(i, ((float)(random(100)-50)) *0.1, 1, 1.0/90.0)-4; 

		plot.plotDatumXYn(i, y1, y2, y3);
	}
	plot.finishGraph();
}

Example: Plotting Arbitrary Lines

Sometimes your not using time series data, and need to plot lines between arbitrary x/y positions. Many solutions for the arduino breakdown at this point. Here I demonstrate such a plot (based on the logarithmic spiral). Note I am using lines with point markers to show the actual points plotted.

//main
GNUPlotLineGraph gnuLinePlotter(&Serial);
PlotLogarithmicSpiral(gnuLinePlotter);

//method
void PlotLogarithmicSpiral(SerialGraph& plot)
{
	//setup graph
	plot.newGraph();
	plot.enableSaveImageFile(true);
	plot.setTitle(F("Logarithmic Spiral"));

	//setup series
	plot.setSeriesName(0, F("Spiral"));
	plot.getLineApperance(0)->setLineWidth(2);
	plot.getLineApperance(0)->setMarkerStyle(LineMarkers::SolidCircleMarker);
	plot.getLineApperance(0)->setRGB(GraphColorsSchemeSpectral::Spectral7);
		
	//plot graph
	float a = 1;
	float b = 0.1759;
	for(int i=0; i<(int)(10.0*20.0*M_PI); i+=5)
	{
		float t = ((float)i) * 0.1;
		float rt = a*pow(M_E, b* t);
		float x = rt*cos(t);
		float y = rt*sin(t);

		plot.plotDatumXY(x, y);
	}

	plot.finishGraph();
}

Example: Multi Column Bar Graph.

Bar graphs, for histograms and such are easy in this API. The example below shows support for multi column graphs, Note: negative values are also supported. The labels for the X-Axis are plotted as standard x values (the plot command is template driven and can support many different types of data).

//main
GNUPlotBarGraph gnuBarPlotter(&Serial);
PlotSampleBarGraph(gnuBarPlotter);

//method
void PlotSampleBarGraph(SerialGraph& plot)
{
	//setup graph
	plot.newGraph();
	plot.enableSaveImageFile(true);
	plot.setTitle(F("Google Results for Instruments"));
	plot.setXAxisName(F("Instrument"));
	plot.setYAxisName(F("# Google Results (millions)"));
	plot.setShowGrid(true);

	//setup series
	plot.setSeriesName(0, F("play"));
	plot.getLineApperance(0)->setRGB(GraphColorsSchemeOranges::Orange1);
	plot.setSeriesName(1, F("teach"));
	plot.getLineApperance(1)->setRGB(GraphColorsSchemeBlues::Blue1);
	plot.setSeriesName(2, F("like"));
	plot.getLineApperance(2)->setRGB(GraphColorsSchemeGreens::Green1);
	plot.setSeriesName(3, F("hate"));
	plot.getLineApperance(3)->setRGB(GraphColorsSchemeReds::Red1);

	//plot graph
	//Dataset compiled by Google-ing "I X the Y"
	//                instrument	play	teach	like	hate
	plot.plotDatumXYn("Piano",		173,	25,		211,	21);
	plot.plotDatumXYn("Guitar",		163,	22,		193,	27);
	plot.plotDatumXYn("Violin",     41,		2,		43,		1);
	plot.plotDatumXYn("Drums",		30,		8,		83,		9);
	
	plot.finishGraph();
}

Installation

1. Get the library from its github repository.
2. See the official guide on how to install libraries https://www.arduino.cc/en/Guide/Libraries
3. Run the provided example sketch
4. Install GNUPlot v5.0 or later (here).
5. Using the com port viewer, copy the output of sketch into GNUPlot.
6. Enjoy!

It is very possible to get the output generated by this library to GNUPlot automatically. How you achieve this is up to you.

It is possible to direct the output to a SD card. See the arduino help page on the file class, to create you own file on a SD card. Then pass the open file object in to the constructor for your plotting class (where I used Serial in the examples).

Documentation

Full documentation available here.

License

GNU 2.0

State

Most Features are well tested, but I don’t warrant or accept liability for any of the functionality in any way.

NB: some dynamic memory usage , refrain from using malloc during plotting operations to prevent possible heap fragmentation.

• Dynamic memory usage is a design decision I made weighing pro’s and con’s of the situation.
• Given ‘typical usage’ scenarios of the API it should not cause heap fragmentation.

Road-Map

May happen:

• Second x/y axis support
• Matlab support
• 3d plots
• Spectrogram
• Support for cloud based rendering for graphs
• Sage support
• Thousands separator (right now I could not deploy it because of a bug in the windows version of GNUPlot).

Won’t Happen:

• Real-time visualisation (plenty of other projects to do that already)