There are many ways to change an output pin. The way we know and love is the famous digitalWrite() function.

But even the Arduino Reference claims that it is not the most efficient. The Arduino functions do a lot of error checking to make sure the pin is configured right and has to map Arduino numbering to actual IO ports.  All this cost processor cycles, and time.  But how much? This article is not to teach you how to useIO registers, you can read about it on the Arduino Port Manipulation page. This is to cover exactly how inefficient the Arduino functions are.

I ran some tests to find out. The test platform was a 16Mhz Arduino and a very nice oscilloscope watching one of its output pins. I ran two tests, one setting the pins to know values(on or off), and one that ‘flips’ the pin from its previous state.  My code was inside a never ending for loop, so the result would always be a square wave form that I could measure in frequency.

The estimated CPU cycles is calculated from ½ the waveform period measured divided by the period of 16Mhz, since it takes two write operations to complete a full period in a waveform.  There could be some differences in the machine instructions it takes to set a bit compared to clearing a bit, so this is somewhat rough.

The 3 methods I tested were

• digitalWrite(pin, LOW);         digitalWrite(pin, HIGH);
• CLR(PORTB, 0) ;     SET(PORTB, 0);
• PORTB |= _BV(0);                   PORTB &= ~(_BV(0));

The macros used:

#define CLR(x,y) (x&=(~(1<<y)))

#define SET(x,y) (x|=(1<<y))

#define _BV(bit) (1 << (bit))

The results

As you can see, digitalWrite takes around 56 cycles to complete, while direct Port addressing takes 2 cycles. That’s a big difference in time for programs that have lot’s of IO operations!

Next I tested just flipping a pin. By this I mean I just changed the pin state without knowing what the initial state was without testing. The methods of testing

• digitalWrite(pin, !digitalRead(pin))
• PORTB ^= (_BV(0))
• sbi(PINB,0)

#define sbi(port,bit) (port)|=(1<<(bit))

The results

Wow, the Arduino method takes a whopping 121 cycles to flip a pin! The sbi() using the PIN register is a neat trick for what usually is a read only register, and is the fastest at only 2 cycles.

So you see, the Arduino functions take much MUCH longer to complete pin operations then using direct port IO. But there is a reason why. Arduino does a lot of error checking, and has to look up pin number mappings to actual Atmega pins. Direct port access is not for the faint of heart, but it can be much faster for when you are ready to take off some of the Arduino training wheels.

Credit to Webbot for showing us the PIN register trick.

UPDATE: Well, it seems the attention of my article has made me aware of a neat-o library for Arduino that keeps the code simple, but runs just as fast as direct port manipulation. Arduino Forum post here. I just tested the digitalWriteFast2() function and it also seems to only require 2 cycles to complete.

Share on Facebook

It’s been a while since I posted an update on SAGAR, but here’s the latest.

I wanted her to go faster. My original motors would only do about 1.2 m/s tops. Well, with a little help from a friend, I found new motors that would bring up the top speed to well over 3 m/s. However, they require more current to reach that speed, more then my original controller could handle. So it had to be replaced.

I wanted to build a single board motor controller from scratch, but couldn’t find the parts I needed with the support for the higher current. I decided on a motor driver board from Pololu, and designed my own ‘daughter board’ to connect to it.

The daughter board is an Arduino board of my own design. It mates directly with the Pololu driver board, and included the pin headers for motor encoders, and a connector for a Dimension Engineering voltage regulator. The regulator will be providing the 5V rail for all the electronics in SAGAR.

I have several copies of the daughter board if anyone wants them. They are yours for free but you pay shipping. Leave a comment if you would like one.

Here are some pictures: (click for full size)

New

Some more pictures:

The old Motor Driver. I feel like it was such a messy job now.

With the Voltage and Current Sensor

Installed. Man it looks sexy!

Share on Facebook

My Source VI can be Downloaded Here

LabView V8.6 HERE

The following video showcases my sample program.

Share on Facebook

The big change is you can now define what pins of the Arduino are used, no longer are you tied to pins 10-13.

Also, vibration (Rumble) and analog button pressure readings (how hard is a button being pressed) are now working.

The library has changed names. PSX -> PS2X to avoid confusion with other sets of code. Sorry for those that need to change a bunch of their programs.

I had to rewrite a lot of code that powers the library, there is not much left of the original code written by Shutter of Arduino forums. There were many bug fixes, now the controller should automatically be in analog mode, and the mode button should be locked. There’s also a catch to make sure not to much time has past since the last controller reading. If there was, it will configure the controller again, in case it timed out.

Download here:

PS2X lib v1.41

Old Versions:

PS2X_lib_v1.0

PS2X_lib v1.3

PS2X lib v1.4

For those who missed the excitement the first time, here’s a wiring diagram(from the amazing CuriousInventor PS2 Interface Guide) and demonstration video:

Image Source: CuriousInventor

Here’s a video demonstrating the library.

Share on Facebook

Outdated. Go to new library HERE

A while ago, I spent countless days trying to interface an Arduino and a Play Station 2 controller. I wanted to build a controller for my SAGAR robot, and figured PS2 + Arduino would be perfect. However, no matter what I did, no existing library would work for me. I shelfed the project for a while, but recently found this forum post with some code by a member named Shutter. I tried out the code, and to my surprise, IT WORKED!!! Well, mostly anyway. It didn’t really have analog stick support, nor was it formatted into an easy to use library.

Well, through need I spent some time adding analog stick support, and formatted it into a library. It works fine on my Arduino Pro mini.

Here are my library files, and an example Arduino sketch that uses it. Enjoy, and comment here with any bugs you find.

To install the lib, unzip the Source Files zip into your Arduino/hardware/libraries directory.

Go to new library page  HERE to download.

Note: The library is hard coded to use pins 10-13 for interfacing the controller. When I get time, I’ll add code that lets you change the pins when initialized. For now, the pin-out is as follows:

PIN     Name             Color

10        Attention     Yellow

11        Command     Orange

12        Data              Brown

13       Clock            Blue

Image Source: CuriousInventor

Hack-a-day Visitors:  I’m honored to be featured on Hack-a-day, and hope this helps out some fellow builders. I also want to re-iterate that I started out with existing code by Shutter of Arduino forums and added analog support, as well as turned the code into a working library.  I can’t take all the credit.

Here’s a video demonstrating the library.

This code is demonstrated in the video. The program works by setting up the library, initializing the controller, and continuously reading the controller and sending the data to the robot.

Share on Facebook

First, you need to connect the two systems at the physical level, IE you need to wire the two devices together. For my project, I used an XBEE radio link. This emulates a serial cable between the Axon and my laptop. I used an Axon’s uart port, and a USB port on my laptop for the USB to Uart chip. LabView has VISA libraries to read from a serial port. This is the easy part of any communication system.

The tricky part is how to convey information between the two. I need to go back to a basic level to fully explain this. For us 10 fingered humans, we express numbers in base 10. The number ‘6’ means this many ( * * * * * *) things. We say ‘6’ to express that many items to another human, and the base 10 number systems is commonly accepted by the human race as THE way to express the number of things. Computers are different. They can only express things in binary, base 2. So ‘6’ to a computer is 110. The problem is that there are many ways to express ‘6’ in a computer. It could be 0110 or 1010 or 01111010. We tell the computer how to represent a number when we declare it as an int, double, etc. So if we were to send data at a binary level, we would have to keep track of how either system is representing it’s numbers. If they don’t match, they won’t understand each other.

There’s also this little thing called big/little endian. This describes the order of how a number is stored in a computer. One way is the way we would consider normal, IE 231 is stored as 2 – 3 – 1. The other way stores numbers backwards, 1 – 3 – 2 . If the two systems as mismatched, again you get communications errors.

These two variables of computer systems are hard to keep track of, and make communications challenging. A way around this is to convert all communications to the ‘human’ standard, something we organic life forms can understand. I use printf() statements to output a sentence of data in a comma delimited form otherwise known as a NMEA sentence. For example,

$SAGAN,20,2,30.193392,-85.797508,55,193*75

Conveys information about the waypoint mission SAGAR is running. The first field, the ‘header’, tells LabView what sentence this is, ie what it conveys. The next fields give the number of waypoints, the current waypoint, the coordinates of the waypoint, the range and bearing to that waypoint. The sentence ends with a * and a checksum to check integrity of the sentence.

Because we are converting all binary data to ascii representations of base 10 numbers, there is no way to confuse the data, no need to worry about how it’s declared in either system nor how it’s stored in memory.

When LabView receives the sentence through a serial port, it checks the sentence against the checksum to confirm its integrity, scans the header to determine its contents, and then breaks it apart into ‘tokens’. These tokens are sub-strings of the numbers between the commas. Then they can be converted into computer numbers using the LabView equivalent of atof(). (Ascii to float).

And there we have it. We successfully conveyed a number from an Axon Microcontroller to a laptop running LabView, without messing with how numbers are declared or stored. The tradeoff, however, is it takes more bandwidth to send ascii sentences then it does to send binary data, but the ease in which to integrate the two systems is worth it, at least in my opinion.

Share on Facebook

First I’ll show the new interface, and talk about how it communicates with SAGAR.

Here is a video of the new interface, with an inset of SAGAR as it runs the mission.

NMCI friendly:

YouTube:

During the run we recorded, there was a glitch half way through. It appears Labview started to slow down and the gap between live events and what was being displayed grew, until the Labview buffer overflowed and sentences where lost. I have yet to look into that problem, as it is the first time we have observed it.

When my girlfriend came to me for ideas for her LabView class, I suggested she write an interface for my robot. I knew I would have to develop a communication protocol that I could hand to her from the start. I took a look at the structure of the ArduPilot communications, and it seemed odd to me. Is the structure a known protocol? I’m sure one of the developers will tell me.

I decided to stick to something I knew, the NMEA protocol. For those who are not aware, GPS systems communicate via the NMEA protocol, as do many other robotics systems. The structure of a NMEA sentences starts with a header that identifies the sentence, then comma delimited fields that contain the data to be passed. The sentence is usually followed by a checksum, to validate the integrity of the data. I came up with my own header, and added the fields of sensor data I wanted to have displayed on the interface. Here is an example of my structure.

$SAGAR,heading,pitch,roll,wheelspeed(Commanded l+r, actual l+r),

distance_trav,GPS_Fix,GPS_Lat,GPA_lon,GPS_speed,GPS_COG,

Battery_V,Battery_I,processor_load*CS

This is one of two sentences SAGAR will send to the interface. The other sentence contains mission statistics like current waypoint number, distance to waypoint, etc. There are also 4 sentences that the interface sends to SAGAR, each representing a different mode for SAGAR to enter, and commands to follow. There is a fail-safe in place, if SAGAR doesn’t receive a command sentence in 500ms, it halts and enters stand-by.

SAGAR started as a bag of parts nearly a year ago, and grew from there. (Almost) everything is from scratch, down to DIY battery packs.

Not too shabby? Forgive and spelling/grammar, I am definitely bad at both.

Coming up next: The importance of a good chassis, and building my own closed loop motor controller.

Share on Facebook

The terrain isn’t actually that rough, SAGAR’s orientation sensor is just noisy. I’ll have to take a look at it later. The current position of SAGAR is plotted real time on Google Earth, as well as the current WayPoint goal.

Watch the video on Youtube here.

Share on Facebook

I used a Ardupilot program to generate the mission file with waypoints, convert it to a hex file using gcc, and I manually flash that into the Axon’s EEPROM memory. When SAGAR comes online, I give it a command to scan the mission file in memory, then I command it to run the mission.

It worked rather well, I had to stop it a few times to avoid hitting a curb or two, but other then that it hit all the waypoints in it’s mission. The cheapo Venus GPS I’m using for SAGAR apparently is really inaccurate at times.

More to come…

Share on Facebook

I ordered some parts for SAGAR, moved the compass out of the main body and up on some standoffs. I added a top deck to protect the compass. The upper deck will be used in the future to hold the ultrasonic rangefinders when I move to feature based navigation.

Pictures of the new design below.

Share on Facebook