The error message “Unable to create the display plug-in MPForum.Forum.1” has been plaguing me on my laptop. Whenever I launch the MPLAB 8.92 programming environment it immediately crashes. I spent hours last year trying to fix it to no avail, and I spent almost all of yesterday too. The Microchip forums have a number of posts on the subject but none of them offered a solution for me.

Finally, I have found a solution! The problem is caused by DEP (Data Execution Prevention). The MPForum.dll has a bug that triggers DEP into terminating the process. To work around this, simply disable DEP for mplab.exe. This is done in the System control panel, search Google for exact details.

DipTrace is a good schematic/PCB editor, but the jagged graphics leave a lot to be desired. You can make it a bit easier on your eyes by using your graphics card driver’s control panel to force anti-aliasing on. The image becomes a little blurry, but overall I find it easier to read.

For an nVidia card open the NVIDIA Control Panel from your start menu and select “Manage 3D Settings”. Choose the “Program Settings” tab then press “Add” and locate the DipTrace executable (default: c:\program files\diptrace\schematic.exe). In the list below set “Antialiasing Mode” to “Override any application setting” and “Antialiasing Setting” to “8x”. If DipTrace is already running you may need to restart it for it to take effect. DipTrade must be using either OpenGL or Direct3D for rendering.
AMD cards have similar settings.

Click on the image below to see difference. When the image is displayed you may need to click again to view it at its full size.

Disasters are rarely caused by a single failure. Instead, the fates conspire to align a series of small misfortunes which combine together to create a catastrophe. Such an event befell the Raffe recently.

The tale begins almost exactly one year ago. In May 2014 I made my way, laptop in hand, to San Diego in order put the finishing touches on the Raffe’s software ready for the Bay Area Maker Faire. At home I do all the development work on my PC, but for travel I switched to my laptop. This was the first misfortune – the PIC microchip programming software MPLAB refused to run on my laptop. I spent a few hours trying fruitlessly to persuade it to run before deciding to cut my losses and switch to Lindz’s laptop. Even though our laptops are identical makes and models running the same operating system, MPLAB runs on his laptop but not mine.

I spent my two weeks of vacation working hard to polish up the new software – all new LEDs necessitated some hardware modifications to the custom electronics and lots of firmware modifications, plus updates to the PC software. All of this was done on Lindz’s laptop. Usually I commit my software modifications to SVN, a change management system that keeps track of the changes that have been made as well as making sure there is another copy of the files, but because I was in San Diego I could not connect to the network, so the changes were not committed. This was misfortune number two.

With the changes complete we went to the Maker Faire and everything worked splendidly. The new spots and LEDs were much brighter and looked great. When the faire finished there was no time to relax, I left immediately for the long flight home. This was the third misfortune: I did not have time to take a copy of the software. We both have an extremely busy schedule, and after the faire ended we quickly forget that I did not have the latest copy of the software.

Fast forward almost a year, when misfortune number four struck: Lindz’s cat pushed his laptop off a table, destroying its hard drive. I sent him a copy of the software to load onto a spare machine and it was only then that we realised that what I’ve sent him is out of date. Misfortune five, the laptop had no backup schedule. Two weeks of full-time work were now stuck on a broken hard drive. Recovery was estimated at $1,250 which was far too much to afford.

The only option that remained was to redo the work. It was not a nice prospect, because I already knew just how difficult it was. There was little choice however, so I spent almost the next two weeks programming 16 hours a day to recreate the work that had been lost. That work is now complete, so not only has the lost work been redone, but new features have been added that will make it better than ever this year.

I just spent at least twelve solid hours of work debugging some firmware, finally solving the issue by flipping a single bit from a zero to a one. Such is the life of a computer programmer.

The Electric Giraffe Project now has an all-new website!

Ok, it looks almost exactly like the old one, but it’s been rewritten from the ground up using a different CMS and using responsive design techniques, meaning it will now work much better on mobile and tablet devices.

Rather than using a traditional fixed width design, a responsive design allows the size of the page to adjust to the size of the viewing area, be that the size of the browser window on a PC or the size of the screen on a mobile device. Further to that, the use of CSS @media queries allows the layout of the website to change dynamically based on the size of the page. One example of this is that the website’s main menu appears on the left on a wide screen, but is moved to the top on a narrow screen to allow more room for the articles.

I've been designing a very simple new circuit to control the servos in the forthcoming new neck.

Each joint calls for a two channel servo driver, and I decided to add current sensing capability to this.  By continuously monitoring the current drawn by the motor, the circuit should be able detect the increase in current that occurs when the motor is stalled – because the neck has hit an obstruction or the mechanism has jammed – and shut down the servo drive before too much damage is done.

The circuit is split into three parts: Firstly, a current sensing resistor; second, a low-pass filter; thirdly, an amplifier.  The output from this is then fed into a standard CAN (Controller Area Network) circuit driven by a PIC chip.

The principle of measuring current with a current sense resistor is very simple: you put a low-value resistor in series with the power supply, and measure the voltage across it.  The resistor can be placed either at the power supply's positive terminal ("high-side"), or negative terminal ("low-side").  Using the low side is slightly simpler as one end of the resistor is grounded.  It has some disadvantages (the ground voltage level for the circuit being sensed is raised up by the voltage across the resistor, and it cannot measure if the load is shorted to ground), however those aren't a problem for this application.

The current flowing through the motor passes through the current sense resistor, developing a small voltage of V = IR.  I have estimated the maximum servo current to be 5A (this will be confirmed when I get the actual servo specifications).  With a resistance of 0.05 ohms, this will give a voltage range of 0 – 0.25V for a current of 0 – 5A.

The power rating of the resistor is important here.  Power is calculated as P = I²R, so at 5A this would give me a power rating of 5*5*0.05 = 1.25W.  This is the minimum wattage for the current sense resistor.

Before being amplified, the signal passes through a 7Hz low-pass RC filter.  This is simply a 220 ohm resistor and a 100uF capacitor arranged so as to block any high frequency noise that may be present on the sensor, for example voltage spikes caused by the servo motor's operation.  The motor will only need to be sampled a few times per second, so I chose 7Hz as the cut-off frequency for the filter to avoid any aliasing effects when sampling.  Aliasing occurs when signals are sampled more slowly than half their maximum frequency component, and causes the high frequencies to appear as if they were low frequency changes, giving you an erroneous result.

The next stage is a non-inverting amplifier.  An amplifier is necessary here because the chip's analogue to digital converter is not especially precise, so amplifying the signal from 0 – 0.25V into the range 0 – 2.5V allows me to use more of its range, giving a more precise current measurement.

Because the amplifier output needs to operate down to zero volts, I chose the LM358 dual operational amplifier.  This 8-pin IC contains two amplifiers with an output swing of 0V to Vcc -1.5V.  Normal amplifiers cannot drive their output to the power rails, so a "rail to rail" amplifier is needed for an application like this – however in this instance I only need to include the 0V rail, so the LM358 will do the job just fine.

The two feedback resistors are arranged to give me an amplifier gain of 10.

Finally, the signal passes through a 20 ohm resistor before being fed into the PIC chip's analogue to digital converter.  The 20 ohm resistor is recommended to ensure the amplifier remains stable when driving a capacitive load.

This is what happens if you forget to restore your transformation matrix after doing a rotation in OpenGL – oops!
 

There are a couple of things that have been bothering me about the software.  First is the lack of multi-threading: the UI and the pattern generation are done in the same thread, meaning that if the pattern generation runs slowly (for example because of heavy processing doing beat detection or video processing), the UI might become sluggish.  The second is the rendering of the UI being done in Windows GDI.  I really pushed the GDI beyond what it was designed to do.

Even though neither of these things are a problem (the CPU is plenty powerful enough, and the UI functions perfectly) I still wanted to make the changes because, well, I'm a bit of a perfectionist.

I decided that it was finally time to bite the bullet.  I have split the frame generation off into its own thread so it can now be run on a separate core to the UI, keeping the UI nice and responsive.  The difficulty here was ensuring everything is synchronised and thread-safe, but a sprinkling of critical sections here and there have got it covered.

Replacing the rendering engine is a much harder prospect.  At the moment everything is written using Windows controls (they're owner drawn so that they have their own visual style, but they're still standard components.)  I'm going to use OpenGL for the rendering, and scrap all the Windows controls.  This means that I have to write from scratch all my own UI widgets like buttons, checkboxes, edit boxes, list views… the works.  It's a huge task.  I also have to do all my own message handling, creating the whole windowing framework, processing mouse and keyboard messages – everything.

I've been working on it for a few months now and it's starting to take shape.  I have implemented the basic OpenGL rendering engine, texture loading and drawing.  I've implemented a small number of the basic UI widgets: buttons, drop-down lists and scroll bars.  There is still a long long way to go, but I'm getting there.

The new sensor boards were completed in time for the 2011 Maker Faire:

 
This is the fourth iteration of the nose board, previous versions having been smashed by the lower jaw springing up into them.  Each petting zone (nose, eyes, and new for this year: under the chin) now has a frosted polycarbonate guard on top of it.  This serves three purposes: it provides a nice tactile surface for petting; it glows when lit by the new petting zone LEDs; and it protects the sensors from damage.  Previously we had simply used blobs of glue to protect the sensors, but it was ugly.  The new plates look great, are tough and durable, and also easy to remove if the circuit board needs to be accessed.

The new LEDs in the petting zones provide very helpful visual feedback.  When multiple people are petting the giraffe at once it’s hard to know if your input is being registered or not because he’s busy responding to someone else’s input.  With the LEDs you get immediate feedback that your input is doing something, even if he can’t respond to it immediately.  There was some debate over how many petting zones there should be in the nose.  Originally there were two, but last year Lindz expanded it to five.  I argued to reduce it back to two because people just cannot see the difference – they are already at sensory overload in a fair environment before they even get to the giraffe, and they just don’t have the attention necessary to see details like that.  We decided to go for two zones, and I tried to differentiate them as much as possible by clearly grouping them with a large distance between them, and providing tactile feedback in the form of a ridge between the two groups.  Even so, most people would pet the whole nose at once and not try to trigger the two zones independently.

Something that came out of the faire is the need for an "interview mode" – a simple reactive mode that can be turned on during TV interviews to make sure he responds predictably and immediately while on camera.
The new status LEDs on the servo driver board were useful for keeping an eye on what he was doing, but it’s possible that they could be expanded even more, perhaps into an LCD with a readout of his status.

The sensor/servo board mounted in the head has been split into two boards.  This has allowed the number of servo channels to be expanded to ten and the number of sensor channels (petting zones) to be expanded to twelve.  The prototype petting zones now have LEDs built into them so they react instantly when touched, providing people with immediate feedback to show that their petting is being registered by the Raffe.  Previously it could be difficult to tell because many people could be petting the Raffe at the same time, but of course it will only speak one sentence at once in reaction.