This is a three part Series to explain how I control my BotTwo&n

read more

Introduction

Updated 29/01/2014 All pcDuino v2 tutorials

Update! The pcDuino version 3 is now available

In the last twelve months or so several somewhat inexpensive single-board computers have burst onto the market, and of those was the pcDuino. This has now evolved into the pcDuino v2,  the topic of our review. The pcDuino v2 is billed as the “mini PC + Arduino”, a combination with much promise. Out of the box it runs a version of Ubuntu 12.04 on Linaro 12.07, or can also run Android Ice Cream Sandwich if so desired.

The pcDuino v2 is a single-board computer like many others, however with some interesting additions – the most interesting being the Arduino-shield hardware connections and pcDuino v2 Arduino development environment. We’ll first run through the pcDuino v2 as a Linux computer, and then delve into the Arduino-compatibility. But first, our test board… which arrived safely in a neat box:

… which contains the pcDuino v2 itself:

At first glance you can see the various points of interest, such as the Allwinner A10, which is a 1GHz ARM Cortex A8 CPU:

… the Realtek WiFi add-on board (which is fitted to the pcDuino v2):

… and also a USB socket (for keyboard, mouse, USB hub and so on), a microUSB for USB OTG use, a full-sized HDMI socket for full HD video, RJ45 Ethernet socket,  a microSD socket for expansion, and the Hynix flash memory ICs. From the pcDuino v2 website, the specifications are:

Hardware:

• CPU – 1GHz ARM Cortex A8
• GPU – OpenGL ES2.0, OpenVG 1.1 Mali 400 core
• DRAM – 1GB
• Onboard Storage – 2GB Flash, microSD card (TF) slot for up to 32GB
• Video Output – HDMI
• OS – Linux3.0 + Ubuntu 12.04/Android ICS 4.0
• Extension Interface Arduino Headers
• Network interface – 10/100Mbps RJ45 and on-board WiFi module
• USB Host port 1
• Requires – Power 5V, 2000mA
• Overall Size 125mm X 52mm

Software

• OS – Ubuntu 12.04 (pre-loaded) or Android ICS 4.0
• APIs – all the Arduino shield pins are accessible with the provided API. 

  It consists of API to access the following interfaces: UART, ADC, PWM, GPIO, I2C, SPI

• Programming language support – C, C++ with GNU tool chain, Java with standard Android SDK, Python. 

However at the time of writing all models with the date stamp of 17/09/2013 (and newer) have 4G of onboard flash storage – a great little bonus. With the addition of an inexpensive microSD card you can add up to an additional 32 G of storage.

Getting Started

This is the crunch-point for many products – how does one get started? With the pcDuino – very easily. Apart from the computer itself, you’ll need a monitor with HDMI inputs and speakers, a USB keyboard and mouse (with a USB hub – or one of those keyboard/trackpad combinations) and a power supply. The pcDuino v2 requires up to 2A at 5V – a higher-rated plugpack than usual. Don’t be tempted to use a normal USB socket – the pcDuino v2 will not work properly on the available current.

So after plugging all that in with the power the last to connect – the pcDuino v2 fires up in around five seconds, quickly running through the Ubuntu startup process and ended with the configuration screen in around five seconds:

After setting the time zone, language, screen resolution (full HD) and so on it was another ten seconds to the desktop:

At this point we found by accident that the A10 CPU runs hot – in some warmer permanent installations it could use a heatsink. But I digress. We now have a “normal” computer experience – the WiFi found the home network without any issue and the Chromium web browser runs well considering the speed and the RAM (1G) of the pcDuino v2:

The next step is to format the extra onboard storage, which can be done with the usual tool:

We just formatted it to ext4 and moved on. The included software is nothing unexpected, there’s the Chromium web browser, office-style applications, terminal, XBMC, remote-desktop viewer and of course you can hit up the Ubuntu package manager and install what you need.

It’s easy to get carried away and forget you’re not using a typical multi-GHz computer so bear that in mind when software runs a little slower than expected. However working with WordPress and Google Docs inside Chromium was acceptable, and a fair amount of this review was written using the pcDuino v2.

Excluding the Arduino development environment which we look at in the next section, pre-installed programming tools include Python (v2.7), C/C++ with GNU tool chain and Java with the standard Android SDK. At this point we haven’t tried the pcDuino with the Android operating system, however plan to do so in the near future and this will be the subject of a separate article.

At this point we’d say that the pcDuino v2 is a winner in the SBC (single-board computer) stakes, as you don’t need to worry about external WiFi, or deliberating about which version of an OS to use and then having to download it to an SD card and so on… the pcDuino v2 just works as a computer out of the box.

The pcDuino v2 as an Arduino

At this point we’d like to note that the pcDuino v2 is not an Arduino circuit wired up to a computer (such as the Arduino team did with the Yun). Instead, the pcDuino v2 is a computer that can emulate an Arduino – and has the GPIO pins and shield sockets onboard.

So when you run a sketch on the pcDuino v2’s version of the Arduino IDE – the sketch is compiled and then executed using the CPU, not an ATmega microcontroller. Speaking of which, the IDE is a modified version of 1.5.3 which appears identical to the usual IDE:

In fact when you compile and upload that blink.ino sketch everything runs as normal, and a small LED situated near D2／3 will blink as normal. However you do need to use more #include statements, for example #include <core.h> for all sketches. When uploading a sketch, a new window appears that will be blank, as shown below – this window needs to stay open otherwise the sketch won’t run

One of the benefits of using the pcDuino v2 is the extra space available for sketches – a quick compile shows that you can have a fair bit more than your typical ATmega328 – in our example we had 104,857,600 bytes available:

We don’t have a sketch that large, but at least you have some headroom to create them if necessary.

Arduino Hardware support

The shield header sockets are in the standard R3 configuration – and all GPIO is 3.3V and not 5V tolerant. However there is a conversion shield available if necessary. There are also some extra GPIO pins available – another eight, as shown in the following image:

At the time of writing there is support for GPIO use, SPI (up to 12 MHz, master-only), I2C (up to 200 kHz, at 7-bit and master-only), a UART (serial on D0/D1), PWM and ADC on A0~5.

However ADC is a little different, due to the internal reference voltages of the Allwinner CPU. Take note of the following as if you exceed the maximum voltages you could damage your board. Pins A0 and A1 are 6-bit ADCs, which return values from 0 ~ 63, which range from 0V to 2V. Pins A2~A5 are 12-bit ADCs, which return values  from 0 ~ 4095, which range across the full 0V to 3.3V.

There isn’t access to the usual serial monitor in the Arduino IDE as such, instead you need to use an external, hardware-based solution such as connecting a USB-serial adaptor to pins D0/D1 and using another PC as the terminal. And when you press ‘reset’ on your Arduino shields – it resets the entire computer, just not the Arduino emulation – (learned that the hard way!).

However you can output text and data to the console window that appears after uploading a sketch – and doing so is pretty easy, just use prinf as you would in C or C++. For example, the following sketch:

#include <core.h>

// example code from http://www.cplusplus.com/reference/cstdio/printf/

void setup() {
  // put your setup code here, to run once:

}

void loop() 
{
   printf ("Characters: %c %c \n", 'a', 65);
   printf ("Decimals: %d %ld\n", 1977, 650000L);
   printf ("Preceding with blanks: %10d \n", 1977);
   printf ("Preceding with zeros: %010d \n", 1977);
   printf ("Some different radices: %d %x %o %#x %#o \n", 100, 100, 100, 100, 100);
   printf ("floats: %4.2f %+.0e %E \n", 3.1416, 3.1416, 3.1416);
   printf ("Width trick: %*d \n", 5, 10);
   printf ("%s \n", "A string");
  delay(1000);
}

produces the following output in the console window:

It would be recommended to read this guide about using the pcDuino v2 as an Arduino which highlights pretty well everything to get you started, including the notes on interrupts and PWM – and this page which explains the headers on the pcDuino v2. Finally, as the “Arduino” is emulated you cannot use the on-board networking capabilities of the pcDuino v2 such as Ethernet, instead you use a shield as you would with a normal Arduino.

At first glance it may seem that the pcDuino v2 is difficult, which it is not. One needs instead to consider their needs and then work with the available features. Just like many other new development boards and systems, the pcDuino v2 (and pcDuino platform) is still quite new – but growing – so more features and compatibility will appear over time.

How much faster is the pcDuino v2 against a normal Arduino board?

There should be a great difference between the Arduino’s microcontroller and the A10 CPU, even taking into account running the OS and emulation. To test this, we’ll use a sketch written by Steve Curd from the Arduino forum. It calculates Newton Approximation for pi using an infinite series. The pcDuino v2 version of the sketch is below:

//
// Pi_2
//
// Steve Curd
// December 2012
//
// This program approximates pi utilizing the Newton's approximation.  It quickly
// converges on the first 5-6 digits of precision, but converges verrrry slowly
// after that.  For example, it takes over a million iterations to get to 7-8
// significant digits.
//
// I wrote this to evaluate the performance difference between the 8-bit Arduino Mega,
// and the 32-bit Arduino Due.
// 

#include <core.h> // for pcDuino v2
#include "Serial.h"

#define ITERATIONS 100000L    // number of iterations
#define FLASH 1000            // blink LED every 1000 iterations

void setup() {
  pinMode(13, OUTPUT);        // set the LED up to blink every 1000 iterations
  Serial.begin(57600);
}

void loop() {

  unsigned long start, time;
  unsigned long niter=ITERATIONS;
  int LEDcounter = 0;
  boolean alternate = false;
  unsigned long i, count=0;
  float x = 1.0;
  float temp, pi=1.0;

  Serial.print("Beginning ");
  Serial.print(niter);
  Serial.println(" iterations...");
  Serial.println();

  start = millis();  
  for ( i = 2; i < niter; i++) {
    x *= -1.0;
    pi += x / (2.0f*(float)i-1.0f);
    if (LEDcounter++ > FLASH) {
      LEDcounter = 0;
      if (alternate) {
        digitalWrite(13, HIGH);
        alternate = false;
      } else {
        digitalWrite(13, LOW);
        alternate = true;
      }
      temp = 40000000.0 * pi;
    }
  }
  time = millis() - start;

  pi = pi * 4.0;

  Serial.print("# of trials = ");
  Serial.println(niter);
  Serial.print("Estimate of pi = ");
  Serial.println(pi, 10);

  Serial.print("Time: "); Serial.print(time); Serial.println(" ms");

  delay(10000);
}

As mentioned earlier, you can’t see the IDE serial monitor, so an external PC needs to be used. We connected a USB-serial adaptor running at 3.3V I/O to a PC:

Now back to the sketch. An Arduino Mega 2560 can do the calculation in 5765 ms, a Due 690 ms, and the fastest I saw the emulated Arduino in the pcDuino v2 do it was 9 ms:

Wow, that’s quick. However take note that the completion time was all over the place. When it was 9ms, the only application open was the pcDuino v2 Arduino IDE. The completion time increased when opening other applications such as Chromium, formatting a microSD card and so on.

Why is that? As the pcDuino v2 is emulating an Arduino, the CPU needs clock cycles to take care of that and all the other OS tasks – whereas a straight Arduino just runs the code generated by the IDE and compiler. Nevertheless the speed increase is welcome, and opens up all sorts of possibilities with regards to deeper calculations in sketches they may taken too long on existing hardware.

Support and Community

From what I can tell there is a growing base of users (including this one) and like everything else this will help the pcDuino platform develop and evolve over time. There is a Linksprite “Learning Centre” with a growing pcDuino v2 section, the website, wiki, and support forum which are useful sources of information and discussion.

Conclusion – so far

The pcDuino v2 is a great mix of single-board computer and Arduino-compatible power. There is a small learning curve, however the performance gains are more than worth it. Another USB socket wouldn’t go astray, and the documentation and support will increase over time. However we really liked the fact it’s totally plug-and-play with the onboard storage, OS and WiFi.

And finally a plug for my own store – tronixlabs.com – offering a growing range and Australia’s best value for supported hobbyist electronics from adafruit, DFRobot, Freetronics, Seeed Studio and much more.

Have fun and keep checking into tronixstuff.com. Why not follow things on twitter, Google+, subscribe  for email updates or RSS using the links on the right-hand column, or join our forum – dedicated to the projects and related items on this website.

The post Review – pcDuino v2 appeared first on tronixstuff.

Hi everone!

read more

Just to clear up any confusion from the title, this wood burning CNC machine runs on electricity. The wood burner acts as the print head. It’s the thing in the upper right of the field that looks a bit like a soldering iron. In this case it’s being used like a dot matrix printer.

We suppose this is a form of halftone printing, although it doesn’t produce the uniformity we’ve seen with mill-based halftone techniques. [Random Sample] built the machine from wood, drawer sliders, and stepper motors with toothed belts. His Python script takes an image and transforms it into a file which can be used to guide each of the three axes of the machine. An Arduino receives these commands via the USB connection. Each image prints in a grid, with darker pixels created by leaving the hot tip in contact with the wood for a longer period of time.

Don’t miss the sample video embedded after the jump.

[Thanks Ian via Reddit]

My son and I bicycled up to campus today to test out his data logger code (that will be used in the circuits course) on the Windows computers in the lab.  The lab support staff had told me yesterday that they had gotten Python 2.7.3 installed and the Arduino 1.0.3 development environment, as well as the PySerial module that the data logger code requires.

My son has been working pretty intensely on the code lately, doing a complete refactoring of the code to use TKinter (instead of PyGUI, which is difficult to install and quite slow) and to have a more user-friendly GUI.  He also wanted to make the code platform independent (Windows, Mac, and Linux), though he’d only tested on our Macs at home before today.  He’s also trying to make the Python part of the code (the user interface) work in both Python 2.7.3 and Python 3.3, though the languages are not precisely compatible.

We found three problems today:

1. Python 2.7.3 was not quite completely installed.  They’d forgotten to update the path to include C:\Python27\  (The path should also include where the Arduino software was installed—I forget where that was now.)
2. The device drivers for the Arduinos were not installed.  On Macs, there are no drivers to install, but on Windows, you need different drivers for different Arduino boards, and it seems you need to have the board plugged into the USB port in order to install the drivers. (Instructions at http://arduino.cc/en/Guide/Windows#t0c4)
3. My son had forgotten to include one of the dependencies in his list of what needed to be installed—the Arduino Timer1 module from http://playground.arduino.cc/code/Timer1/ .

Because they had given me administrator privileges on the machines, my son was able to fix one of the machines to run the data logger code (though he had a couple of minor changes to make in his code for Windows compatibility also).

For the data logger debugging, about all I did was type in my password for him, and once do a search to see where the Arduino code was hidden.

When he has finished debugging and documenting the code, my son will be releasing it with a permissive license on bitbucket, and I’ll be putting links to it here and on the course web page.

Spending too much time indoors? You need a Personal Energy Orb, a glowing Arduino powered ball that allows you to trade physical exertion for a tolerable mouse speed. Developed by two students at the University of Munich for a physical computing course, the PEO connects to a bike-mounted revolution counter to note how far a user rides, counting the total distance toward usable time on a computer. A fully "charged" green orb will allow a user to use their PC unhindered -- but a spent red orb will drag Windows' cursor sensitivity settings to its lowest. The idea, the project's creators say, is to annoy the user off of the computer and back on to their bike. It sure sounds aggravating to us. Check out the full homework assignment at the source link below, complete with goals, follies and Python scripts.

Filed under: Misc

Personal Energy Orb Aruino project knows you haven't been exercising, cripples your computer originally appeared on Engadget on Sun, 26 Aug 2012 02:19:00 EST. Please see our terms for use of feeds.

I'm working on a project where I send a bunch of data through an arduino to my laptop.  I'm using python serial to read in the serial data.  That part is working fine.  Then I do some processing and I want to send the results back to the arduino.  This part is not working so well.  

It seems like python  serial.write()  only likes to send strings?  Right now I'm trying to send back one integer value.  Any ideas how to do that?  

Comunikino is a box, connected to a PC which runs a script in Python.  When receiving a mail, the subject will be printed to its LCD. You can then use one of three Comunikino’s buttons to send a mail back to say “Yes”,  “No” or “Readed”  (this button can also to be used to say: “Hey! I’m thinking of you”).

The project has been developed by Eraticlux, check here the full project.

It seems that there is a shortage of programmers who can do embedded systems (which is what computer engineering is mostly about these days).

Critics lay much of the blame for the embedded programming gap at the doorstep of university computer science departments that have tended to migrate curricula toward trendy programming languages like Java at the expense of unglamorous tasks such as how to design and analyze algorithms and data structures.
Struggle continues to plug embedded programming gap | EE Times (by George Leopold)

I’m not so sure that Java is at fault here. It seems to me to be perfectly fine second programming language (after a simpler one like Python that does not require all data structures to be declared before any code is written).  The problem is more that the instruction focuses entirely on designing huge complex data structures and using large libraries of complex software components, rather than on fundamentals:

The problems start early in the curriculum. Too often an introductory Computer Science course will fall into one of two extremes: either focusing on the syntactic details of the programming language that is being used—“where the semicolons go”—or else treating programming as a matter of choosing components and plugging them into a GUI.

The basics—how to design and analyze algorithms and data structures—are covered summarily if at all. Software methodologies such as Object Orientation that are best approached in the context of the development life cycle for large applications, are introduced through trivial examples before their benefits can be appreciated: the proverbial cannon that is used to shoot a fly.

The education of embedded systems software engineers: failures and fixes | EE Times (by Robert Dewar)

I’m not so sure that I believe in Robert Dewar’s proposed solution, though, as he suggests having students do more high-level design (software architecture, rather than nuts-and-bolts programming), which is in direct opposition to his claim that students should be getting more training in low-level languages like C.

Robert Dewar also makes an argument for group work at the university level—something that is common in computer engineering programs, but apparently rare in computer science programs.  At UCSC, I know that all computer engineers, electrical engineers, and game design majors are expected to do group senior projects, and some of their other classes (such as mechatronics) are also group projects.

I think that the lack of group projects in many CS courses is not so much tied to Dewar’s idea “a perhaps regrettable staple of the educational process is the need to assess a student’s progress through a grade, and a team project makes this difficult” as it is to the problem of scale—a group project is only reasonable when the project is too big to be done more efficiently by a single person.  Creating and managing such big projects in lower-level classes would be a major undertaking, particularly in the short time frame of a quarter or semester, when a lot of things other than group dynamics need to be learned. Pasting a group structure onto tiny project would make things worse, not better, in terms of training students to be effective in groups (see Group work).

Some entrepreneurs have addressed the problem by starting up “initiatives like Barr’s week-long, hands-on Embedded Software Boot Camp.”  The idea is to take programmers who already have degrees and supposedly know C and train them specifically in the skills needed to do real-time programming. The cost is not small ($3000 for 4.5 days, if you register early).

Some computer scientists have been pointing out problems in the standard CS curriculum for a while:

I started saying this over a decade ago. I even did embedded stuff in my 3rd year data architecture course—my department was uninterested, and the students had a real hard time wrapping their heads around the thought that there are places where resources are limited.

The department fought me when I said that students needed to learn more than one language (Java). The department disagreed when I said that students should learn how to program for environments where bloated OO methods might not work (… But, the ARE no places where efficiency matters!!! It’s all about “Software Engineering”!).

The students had NO idea what it meant to program for a machine that had no disk, only memory.

Part of the reason CS departments are seen as being so out of touch is BECAUSE THEY ARE!!!

University should not be about job training, BUT it is also NOT about teaching only those things the faculty find interesting.

Struggle continues to plug embedded programming gap | The Becker Blog.

I know that there have been struggles between the computer science and computer engineering departments at UCSC about what programming language to teach first, with the computer scientists arguing for Java and the computer engineers arguing for C and assembly language.  Eventually they reached a compromise (which has been stable for about a decade), with the computer science students taught Java first and the computer engineering students taught C first, then both making transitions to the other language.

I think that both approaches work, but the strengths of the resulting programmers are somewhat different.  For device drivers and small embedded systems, I’d bet on the computer engineers, who have a better grasp of low-level details, interrupts, and hardware/software interactions.  For more complicated projects, I’d want one of the computer scientists doing the high-level programming, teamed with computer engineers to do the detail work.

I actually don’t like either C or Java as a first programming language.  I think that students would be better off starting with Scratch, which gets them quickly into multi-threaded code, real time operation, and race conditions, without burdening them with a lot of syntax.  Then they can switch to Python to learn about code syntax, types, and objects, without the burden (or support) of compile-time type checking.  After that they can switch to Java to learn about declaring all their data structures and having very rigid type rules (useful for bigger projects to make interfaces between different design groups more explicit).  In parallel with learning Python and Java, they should learn C and C++ in the context of the Arduino microprocessor (or similar small microprocessor) to control real-time physical systems.

The computer engineers could even skip Java, and learn their rigid type systems strictly in C++ (which they are more likely to use later), though Java is cleaner and makes the learning somewhat easier.

Computer scientists should not stop with this handful of languages, though, as they are essentially all Algol derivatives.  The CS students should also learn a couple of languages that come from different lineages (LISP or Haskell, for example).

Today I had to write a program to fit a sphere to a bunch of points that were supposedly near the surface of a sphere, but were noisy and sampled in a very biased way.  Since this is obviously not a new problem, I started out doing web research.  but I didn’t look for fitting a sphere, but for fitting a circle, since that is a simpler related problem.

I found a lot of papers, including several review papers, on how to fit a circle to a bunch of points.  The “obvious” method is to  do a least-squares fit to minimize the distance between the points and the circle, minimizing , where is the radius and is the center of the circle.  Unfortunately, that is a difficult problem to solve, and even numerical methods require a lot of iterations to get decent solutions.  What most people do is to change to a slightly different problem that optimizes a different fitness function.  For example, Kåsa’s method minimizes .

There is a very nice, but very formal, presentation of the methods in a paper by Vaughn Pratt from 1987: Direct Least-Squares Fitting of Algebraic Surfaces.  This paper introduced Pratt’s method, which was later slightly improved to make Taubin’s method. I did not read these original papers (other than skimming Pratt’s paper).  Kåsa’s paper (A curve fitting procedure and its error analysis. IEEE Trans. Inst. Meas. 25: 8–14) does not seem to be available on-line.  The IEEE digital library is missing the whole 1976 year.

I did find a recent paper that does careful error analysis of both the geometric approach and several of the algebraic approaches (including the most popular ones: Kåsa, Pratt, and Taubin):

Ali Al-Sharadqah and Nikolai Chernov
Error analysis for circle fitting algorithms
Electronic Journal of Statistics
Vol. 3 (2009) 886–911 ISSN: 1935-7524 DOI: 10.1214/09-EJS419

This paper shows that Taubin’s method is theoretically superior to Pratt’s which is theoretically superior to Kåsa’s (having less essential bias), and gives a very weak example showing it is also tru empirically.  More interestingly, it also gives a “hyperaccurate” algorithm that has less bias even than Taubin’s method.  I did not read the error analysis, but I did read the description of their Hyper algorithm and the implementations of it that Chernov has on his website.

Since I needed Python code, not Matlab code, and I needed spheres rather than circles, I spent a few hours today reimplementing Chernov’s Hyperfit algorithm.  I noticed that the basis suggested by Pratt for spheres, , was a simple modification of the one used in both Pratt’s paper and Chernov’s paper for circles, .  I decided to generalize to dimensions, and use the Numpy package in Python for all the matrix stuff.  I hope I got the generalization right!

From starting to look for papers until getting the code working was about 6 hours, but I had lunch in there as well, so this felt like pretty speedy development.  I’ve released the code with a Creative Commons Attribution-ShareAlike 3.0 Unported License, and would welcome corrections and improvments to it.

Of course, after all this buildup, you are probably wondering why I needed to fit a sphere to points—that is not a common problem for a bioinformatician to have.  Well, it is for the robotics club, of course.  They’ve been having a lot of trouble with the magnetometer calibration and heading code, so we decided to try doing an external calibration of the magnetometer, which has an enormous arbitrary 3D offset.  By waving the magnetometer around in different orientations (which means tumbling the ROV once the magnetometer is installed), we can sample the magnetic field in many orientations, though far from uniformly.  The center of  the sphere fitted to the readings gives us the 3D offset for the magnetometer.

My son and I tested it out with Python code and Arduino code that he had written to get the data from the magnetometer to the laptop, and the magnetometer readings do seem to be nicely centered around (0,0,0) after we do the correction.  We’re still having trouble using the accelerometer to get a tilt correction to give us clean compass headings, but that is a problem for tomorrow morning, I think.