Hobby Creek Arm Mod – 3D Printed Illuminated Magnifying Glass

In this post I will explain how to 3D print and build an illuminated magnifying glass for a Hobby Creek Pana-Hand. The motivation for this project came when I was building my new dual extruder 3D printer (which I used to 3D print the models I will later show) and somehow managed to short out the fan pins and burn an SMD MOSFET. Fortunately for me, I’m not afraid of soldering so I decided to buy a bunch of transistors and go for the kill.

If you’re like me and you haven’t yet mutated a third hand, you will probably find it useful to have some sort of alligator clips stand to facilitate soldering or tinkering $_57.JPG . I currently own a Hobby Creek Pana-Hand which allows me to have not only one extra hand but a gazillion of them ready to obey my every wish and command. I used this setup to get the board in place and position some solder close enough so that I wouldn’t have to hold it, but unfortunately the transistor is really small and I had to use an external illuminated magnifying glass to actually be able to see anything.

After I successfully managed to replace the transistor, my subconscious mind had already made the decision: I was going to make an illuminated magnifying glass arm! I did some digging through my old junk cupboard and found one of these ubiquitous helping hands with a magnifying glass on it and dismantled the damn thing. The magnifying glass itself is good enough for the kind of soldering I do and it’s about 60mm in diameter which is also quite a decent size.

The final thing I needed which I didn’t already have or couldn’t 3D print was an arm to spare. Fortunately for me Hobby Creek also makes a Universal Holder Arm which looked easy to disassemble so I bought one of those and basically removed the reusable zip-tie and kept the screw.

The Design Process

I followed a pretty inefficient iterative process and ended up with a couple of useless 3D printed parts on the way, but in my defence I’m a software engineer so CAD modelling is not something I’m really experienced at. It is my hope that someone will read this some day and learn something so in this section I will go over the pretty basic electronics, the CAD model design and the selection of 3D printing materials. If you’re not interested in the process I followed to reach the final product, you can go directly to the build section.

Electronics

The electronics of this project are very simple, it is just an LED circuit with 12 LEDs in parallel and a current limiting resistor in series with the supply. As the name suggests, the current limiting resistor is used to limit the current going through the LEDs and avoid burning them. Due to the parallel arrangement, each LED has the same voltage but, in very simple terms, the current is shared amongst them. The following diagram is a simplification of the final circuit using only two LEDs:

Screenshot from 2016-07-05 21:11:16.png

Now the important part in this circuit is to get the current limiting resistor value right, otherwise we will either risk reducing the lifetime of our LEDs or simply not have enough brightness. The calculation is rather simple, but before we can actually calculate anything we need to find out the following:

Voltage source ( $V_s$ ), which in this case is going to be 5v.
Voltage drop of the LEDs ( $V_l$ ), in this particular case it happened to be 2.8v, but you will have to measure the one of your LEDs. An easy way to do this is to use a high enough resistor (> 1k should be more than enough) and measure the voltage between the LED terminals.
Desired LED current ( $I$ ), we can find this value experimentally by playing with the resistor value and checking if the brightness is enough for our purpose. A rule of thumb with typical 5mm LEDs is to avoid getting too close to 20mA as the LED lifetime will be decreased significantly (Don’t quote me on this). I’ve determined that with about 8mA, the LEDs are bright enough.
Number of LEDs you’re going to use ( $n$ ).

With all this information, it’s now easy enough to calculate the resistor value we need with the following formula:

$R=(V_s - V_l) / (I \cdot n)$

If you’re too lazy to launch the calculator app on your phone or on your computer, you can always use this online calculator, and go to the parallel case. I must admit I was lazy enough to use this calculator, but in fairness it does provide you with the closest resistor to the value you can actually buy, which is pretty handy. If you weren’t satisfied with my explanation, maybe can help, but I wouldn’t know as I haven’t even looked at it.

If you’re still wondering about the result in this particular case, it’s 22.9Ω but the closest resistor I can buy is 27Ω. For the power supply I will be using a μUSB breakout board, since I always have a couple of cables lying around the table. The LEDs I will use are standard 5mm white; I also had a couple of 3mm LED, but in my experience those are very easy to damage and the degradation is much faster.

Finally a note of caution, I might be wrong on my suggestions so if you want to be 100% sure of what you’re doing, you can probably find other resources online with much more accurate information. In any case, it worked fine for me and if you break a couple of LEDs it’s not the end of the world.

3D Printable Model

Modelling the glass holder as I envisioned it was probably the most difficult part. To create all the models I used Onshape which is a pretty cool 3D CAD modelling software which works pretty well on the browser. The model itself had a couple of requirements such that it should fit the 60mm magnifying glass, the 12, 5mm LEDs and the μUSB breakout board. My original idea was to divide the model in three different parts: the light diffuser, the core and the lid. I started with a very simple prototype which was probably unnecessary and a product of impatience. This prototype only allowed me to fit the LEDs and the magnifying glass, so it was pretty useless.

The second prototype was another failed idea, but it allowed me to understand how to better design the diffuser since the small diffuser was not very effective. I also figured that connecting all of the LEDs in this approach would not be easy, as I would’ve had to squish the cables around the screws.

The third design worked pretty well on every aspect: the size was just right, the LEDs and the magnifying glass fit really well, the connection between the LEDs was relatively easy to make and the diffuser (which was completely empty) worked pretty well. Unfortunately, at this point I came to the conclusion that white PLA for the diffuser was not the best idea as, even though it diffused pretty well. I believed I could find a better material for the job, and so I did.

The material choice I went for was Clear Taulman T-Glase. T-Glase is very well known for its optical properties so it was the perfect choice for the job. As you can see on the following picture, the light diffusion is quite nice on clear T-Glase:

Unfortunately, once I made the decision, I opened a small Pandora’s box of my own. T-Glase is famous for being difficult to print with problems ranging from terrible overhangs, irregular extrusion, flimsy layer adhesion and, to make matters worse, T-Glase has very little adhesion to PLA, so the dual extrusion idea was going to be quite difficult. Fortunately, PLA, the paragon of 3D printing materials, adheres just fine to T-Glase, which solved half of my problems.

So once I got past this particular bump on the road, I went ahead and created my next and final design, which included a solid diffuser and a much more compact lid, with the arm connection on the inside. I’ve generated a couple of images from the different parts of the model for your enjoyment:

This final design can be printed on a dual or single extruder 3D printer, although if you go for the single extruder approach you will need to glue the diffuser to the core. The reason for the diffuser being completely solid is because that way I can take full advantage of the internal reflections produced on T-Glase, but if you’re going to use another type of material you might need to print the diffuser hollow. The final STL files can be downloaded here.

3D Print & Build

Bill of Materials

If you want to buy any of the materials I used for this build you can use the following links, although I must warn you that the eBay and Amazon links are “affiliate” links and they provide me with a negligible amount of money.

Helping hands or 60mm magnifying glass| eBay UK US | Amazon UK US

12 White LEDs | eBay UK US

2mm x 8mm, Self-Tapping Wood Screws | eBay UK US

Taulman T-Glase Clear | Amazon UK US

PrimaValue Blue PLA | Amazon UK

Hobby Creek Universal Holder Arm |

μUSB Breakout Board | eBay UK US

27Ω resistor

With all the decisions made and the models generated, it was time to get on with the 3D print and the build of the illuminated magnifying glass. The first step in the process was to 3D print the models. As mentioned before, I used blue PLA for the core and the lid, and Clear Taulman T-Glase for the diffuser. If you don’t have a dual extruder, you can print each part individually and glue the core to the diffuser with some sort of cyanoacrylate or even hot glue. The settings I used for each material were the following:

Blue PrimaValue PLA:

0.2mm layer height.
185º extruder temperature.
60º heated bed temperature with kapton tape.
50% infill
3 top and bottom layers.
100% cooling fan.
70mm/s speed.
0.4mm nozzle.

Clear Taulman T-Glase:

0.2mm layer height.
238º extruder temperature.
70º heated bed temperature with kapton tape.
50% infill
3 top and bottom layers.
100% cooling fan.
15-25mm/s speed.
0.4mm nozzle.

Since I printed both the core and the diffuser together, I also used a prime pillar which was exclusively printed with T-Glase and an ooze shield printed only with PLA. The reason for this is that the ooze shield, as the name suggests, collects the oozing from both the PLA and the T-Glase (which oozes a lot), and the prime pillar allows to get the T-Glase filament running before printing each layer of the part. I also used a brim to increase the adhesion of both the ooze shield and the prime pillar. You might be wondering why I printed with the diffuser on the bottom, given that it has some overhangs. The main reason for this is that I needed the PLA to be printed on top of the T-Glase as the other way around wouldn’t work due to the terrible adhesion when printing T-Glase on top of PLA. I used Simplify 3D to generate the G-Code and this is the resulting preview:

Screenshot from 2016-07-05 17:56:09.png

Even though the print worked, it was certainly not an easy print. Since Simplify3D doesn’t provide a way to generate different parts of the brim with different materials and the adhesion between T-Glase and PLA is far from perfect, the prime pillar decided to make a run for it, resulting in a mess of spaghetti T-Glase. Fortunately, this madness was contained to the last two layers containing T-Glase. If you think I’m exaggerating have a look (I cleared up some of the mess at this point, but it’s pretty descriptive):

2016-07-05 14.43.11.jpg

Since T-Glase doesn’t adhere to the kapton tape as well as some sources claim, I had to ramp up the temperature to 70º, which ultimately caused the PLA to warp a bit, although I must admit it’s not too bad:

2016-07-05 15.03.17.jpg

Printing the Lid was pretty much straightforward using the settings detailed before. With the printed parts ready, the next step was to add the LEDs and solder them in parallel. To do this, I stripped a cable and introduced it through each groove, finally soldering it to the anode or cathode respectively.

2016-07-05 16.07.18.jpg

Once all the LEDs had been soldered together, I soldered the resistor to the μUSB breakout boar.The positive cable was then soldered to the resistor and the negative cable to the breakout board itself. I also glued the breakout board to the core with some cyanoacrylate:

2016-07-05 17.06.36

The next step was to connect the arm and the lid using the original screw, at this point I must warn you that the screw I received on my Universal Holder Arm might be different to the one you’re using, so it might not be a perfect fit. The fit between the lid and the arm needs to be pretty stiff, with no rotation whatsoever:

2016-07-05 17.08.32.jpg

With the lid secured to the arm, it was time to screw it to the core with the 2x8mm self-tapping screws. At this point it is important to make sure that the magnifying glass is already placed on the core, otherwise this will be a futile effort. The end result should look as follows:

2016-07-05 17.10.53.jpg

The final and probably the most exciting step of the process is to connect the arm back to the pana-hand and connect the μUSB cable. If you used similar materials you should get a pretty decent light diffusion all the way to the centre of magnifying glass. In my case, you can see that the light towards the centre is quite uniform:

If you used Taulman T-Glase but didn’t manage to get such a uniform light diffusion, you can try printing the part again increasing the nozzle size and reducing the temperature. According to Taulman, this will produce a clearer print with improved optical properties. In any case, I believe that white PLA with a hollow diffuser would have been good enough with sufficiently bright LEDs, so if you try it out yourself, let me know!

Conclusion

Overall I’m pretty happy with the build, sometimes these types of projects end up producing something interesting but with little or no practical use, and probably the same can be said of most of the things I’ve ever 3D printed, but this is definitely one I will make use of. It has also been interesting printing multiple materials as that was the main goal I had in mind when I decided to build a printer with a dual extruder.

Unfortunately printing with multiple materials presents some challenges which need to be overcome by either making a “dual colour friendly” design or making a large number of calibration prints to get the parameters exactly right. In my opinion Simplify3D is probably one of the best slicers out there, but I believe it still needs some work in order to support this type of prints. I could probably come up with a number of additions which would have helped, but the most important one I think would be the ability to print a brim on either the ooze shield or the prime pillar using the extruder assigned to each specific feature.

If you’re interested in making your own magnifying arm, you can download the and print them yourself. If you don’t have a dual extruder or you don’t want to go through the same process I did, you can always print each part individually and then glue the c0re and diffuser parts together, the result should be more or less the same.

Please be aware that this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This includes not only this blog post but also the STL files which I have produced after many hours of work. If you would like to use my work for commercial purposes, please get in contact with me.

That’s all folks!

Learning ROS for Robotics Programming

As it can be obvious by now given my posting frequency, writing is not something that comes easy to me, especially not in English, so this will definitely be a surprising post. In August, a couple of friends and I published a book about the Robot Operating System (ROS), a robotics framework which we’ve been using for a long time and which made the basis for the software stack.

This is the second edition of the original Learning ROS for Robotics Programming, which was written by two of the same authors and also reviewed by one of the authors of the second edition. Unfortunately, as life would have it, I couldn’t be involved with the first edition, so I couldn’t pass on the opportunity to participate in this iteration.

This second edition improves upon the first by providing updated content, as the latest versions of ROS are significantly different to those used in the first edition. Be aware that even though the book was originally written to support ROS Hydro, we also provide support for Indigo and Jade in our GitHub repository. We have also improved in general the content of the existing chapters with up-to-date examples and better explanations. Finally, we have replaced the last chapter with two new chapters covering point clouds and robotic arms, which we consider to be a great addition to an already extensive book. The layout of this second edition is as follows:

Chapter 1 – Getting Started with ROS Hydro: as the name suggests, this first chapter goes through the installation process of ROS Hydro on Ubuntu, covering also the process of doing so in a VirtualBox virtual machine as well as on a Beaglebone Black.
Chapter 2 – ROS Architecture and Concepts: the second chapter covers most of the bits and pieces ROS is made of, including practical examples in which the user will learn how to create nodes and packages that interact with each other, as well as with the famous turtlesim.
Chapter 3 – Visualization and Debug Tools: there are many situations in software development where we have to deal with the unexpected, this chapter provides information as to how to use common debugging tools, as well as other tools provided by ROS, in order to debug and visualize our nodes, the data and the interactions between the different elements in our system.
Chapter 4 – Using Sensors and Actuators with ROS: a very important part of robotics is dealing with hardware, this chapter covers the usage of common and cheap sensors and actuators supported by ROS, as well as some others more complex, and not as cheap, such as the Kinect or laser rangefinders. Finally, this chapter will also cover how to use an Arduino with ROS to expand our hardware possibilities even further.
Chapter 5 – Computer Vision: from connecting a USB or FireWire camera and publishing images to performing visual odometry with stereo cameras or RGBD sensors, passing through the image pipeline to perform corrections and transformations to our images, this chapter provides an overview of the computer vision tools provided by ROS and OpenCV.
Chapter 6 – Point Clouds: this chapter explores a different approach to 3D sensor data communication and processing by using the Point Cloud Library (PCL), which is a library tailored to 3D data (or point clouds) processing and it’s well integrated with the latest versions of ROS, providing message abstractions and other facilities.
Chapter 7 – 3D Modelling and Simulation: in many situations, working in robotics requires working without the robots themselves and in some others the amount of tests required to validate a system make it an impossibility to use the robot for that purpose, in those situations the best bet of the roboticist are simulations with accurate 3D models. Since simulations are an indispensable tool for any serious robotics project, this chapter covers the process from creating an accurate 3D model of our robot to simulating it and its environment with Gazebo.
Chapter 8 – The Navigation Stack – Robot Setups: this chapter introduces the navigation stack, which is an incredibly powerful set of tools provided by ROS to combine sensor and actuator information to navigate a robot through the world. This introduction goes through the basics of the navigation stack, explains how to understand and create our own transformations and covers odometry with the use of a laser rangefinder or Gazebo.
Chapter 9 – The Navigation Stack – Beyond Setups: as a continuation to the previous chapter and using all the concepts explained throughout the book, this chapter finalises the configuration of our robot to make full use of the navigation stack.
Chapter 10 – Manipulation with MoveIt!: the final chapter of the book covers the integration between ROS and MoveIt! which provides a set tools to control robotic arms in order to perform manipulation tasks such as grasping, picking and placing, or simple motion planning with inverse kinematics.

The authors of the book, which I consider amongst my best friends and most trusted colleagues, are Enrique Fernández, Ph.D. in Computer Engineering by the University of Las Palmas de Gran Canaria and currently working as a Senior Autonomy Engineer at Clearpath Robotics, Aaron Martínez, M.Sc. in Computer Engineering and co-founder of Subsea Mechatronics, Luis Sánchez, M.Sc. in Electronics and Telecommunications and also co-founder of Subsea Mechatronics, and of course yours truly, M.Sc. in Computer Science and Currently a Software Engineer at Dell SecureWorks (I know, unrelated to robotics).

Come on, stop talking and tell us where we can buy the book…

I know, I know, you’re an impatient bunch, right after this paragraph I’ve included a non-exhaustive list of places where the book is currently sold. If you’re not too sure yet, remember that Christmas is very close and books are always a great gift for friends and family, and who doesn’t want to have a grandma who programs robots* as a hobby instead of knitting?

We’d like to hear your opinions, so don’t forget to comment if you’ve already read the book or even if you haven’t, and spread the word!

* The authors do not claim this book can teach your grandma to program robots.

100 Prisoners and a Lamp

A few weeks ago a colleague of mine proposed me an interesting problem which years ago he found very challenging and a lot of fun and of course you can’t just tell this kind of thing to a computer scientist and expect no reaction whatsoever, so I went ahead and started thinking of a solution. The first thing to say about this problem is that it can have more than one solution and that the only way to compare them is by calculating the average time it would take for the problem to be solved following that particular approach. The goal of this post is not to do a mathematical examination of all the possible solutions but only to talk about the solution I came up with, leaving the problem open to the readers imagination. If you come up with more solutions, please don’t hesitate to comment about them! The problem statement is the following:

There is a prison with 100 prisoners isolated from each other and a very bored prison warden who proposes a challenge: each day he will select a prisoner at random and put him in a special room fitted with nothing more than a lamp and he will give that particular prisoner the opportunity to tell him when all of the prisoners have been at least once in that room. If the prisoner is right all of them would be given a pardon and if he is wrong all of them die. Since the prisoners are isolated, he will give them one hour to elaborate a plan between them, after which they won’t be able to communicate again until the game is over.

At first glance, it’s obvious that the only link between each prisoner in the room and the next one is the lamp, so it has to be used as a method for communicating the next prisoner some message. Defining the lamp as a method to convey a message seems trivial, but given that it can only hold one bit of information it seems that we need something more in order for this message to have a meaning, we will call this extra information the context of the message.

Now, the main difficulty of the problem is defining a context with which to assign a meaning to the message, or rather define how the prisoner going into the room will interpret the lamp being on or off. One way to look at it is that we need something to accumulate information so that whenever a prisoner goes into the room he has a bigger picture than just one bit, I propose this accumulator to be another prisoner which will interpret the message left in the room and accumulate the information, thus acting like an 100 bit message himself.

Given that one of our prisoners is an 100 bit accumulator, who does this job has to be decided during the planning hour, and also how and what the other prisoners should convey through the lamp. For this particular approach, each of the other prisoners will have to inform the accumulator if they have been in the room or not by turning the lamp on, but they will only do so if when they entered the room the lamp was off and if it’s the first time they’ve been there, this way the lamp will inform the accumulator that at least one of the other prisoners has been there for the first time. Finally, the accumulator has to turn off the lamp every time he goes into the room and finds it on, so that a new cycle can start.

With this solution, the accumulator prisoner (or counter as I called it in the following code) will have to go at least 99 times to the room to be able to tell the warden with complete certainty that all of the prisoners have already been there. Considering the best case, this would take him as least as 198 days if he went after each prisoner and for every prisoner this was the first time. If we assume now that on every 100 day cycle at least one new prisoner has been into the prison and that the accumulator is always the last, it would take him 9900 days which is quite a bad prospect for the prisoners and probably most of them will be already out by then.

The following code attempts to simulate the situation by creating random numbers as if it was the warden picking a random prisoner, it also includes the solution by having the accumulator (counter) prisoner and a lookup table for each of the prisoners (in order to store if they have been in or not).

int main()
{
    // ID of the prisoner in charge of counting
    const int prisoner_counter_id = 0;
    // Prisoner state (been with lamp off or not)
    int prisoner_lookup[100];
    // Number of counts by prisoner in charge of counting
    int prisoner_counter = 0;
    // State of the lamp
    int lamp = 0;
    // Current prisoner in the room
    int prisoner_room;

    memset(prisoner_lookup, 0, 100*sizeof(int));

    while (prisoner_counter < 99)
    {
        // Select a random prisoner
        prisoner_room = rand() % 100;

        if (prisoner_room == prisoner_counter_id)
        {
            // Random prisoner is the counter
            // If the lamp is on, count it
            prisoner_counter += lamp;
            // Turn off the lamp
            lamp = 0;
        }
        else if ((lamp == 0) && (prisoner_lookup[prisoner_room] == 0))
        {
            // If the lamp is off and prisoners "first time"
            // Turns on the lamp
            lamp = 1;
            // He has now completed his visit to the room
            prisoner_lookup[prisoner_room] = 1;
        }
    }
    
    printf("Counter counts %d\n", prisoner_counter + 1);

    return 0;
}

As I said, there are other solutions to this problem although it seems a bit difficult to come up with them once you already have a solution. I suggest you give it a try and see what you can get. If you still can’t find any other solutions, I’m sure a fast search will give you many results, but what would be the challenge in that?

Lamp Image |

Arduino IMU: Pitch & Roll from an Accelerometer

One day, looking for cheap sensors on ebay, I found this interesting board which contained everything I was looking for. It basically consists of a 3-axis accelerometer (ADXL345), a 3-axis magnetometer (HMC5883L), a 3-axis gyroscope (L3G4200D) and a barometric pressure sensor (BMP085). My plan is to build an Inertial Measurement Unit (IMU) (or maybe I should call it Attitude and heading reference system (AHRS)) and in the process learn how to interact and interpret the information all of this sensors provide. The fact is I have some experience using IMUs since I used one on my and another one on the , but the fact is they come preprogrammed and there is not much point in working with the raw sensor data unless you want to improve the measurement or give it another use.

For this project I am also using an Arduino Duemilanove, for that reason I wanted to call it ArduIMU, but there is already , so I will have to find another name (suggestions would be appreciated). Connecting the sensor board to the Arduino is pretty straightforward, every sensor has an I²C interface so you can access each of them using the . The drawing was done using fritzing, on which I created the corresponding custom part for this board, although I did something wrong and it does not conform to the fritzing graphic standards.

This will be the first of a series of posts I plan to write about this project, since there are several steps I need to take in order to fully understand each sensor and several more to combine them in order to improve accuracy. In this post I want to talk about the accelerometer and how to obtain the roll and pitch angles from it, which is a process that can also be called tilt sensing.

Accelerometers are devices that are capable of measuring the acceleration they experience relative to free-fall, the same acceleration living beings feel. As a consequence, accelerometers are incapable of measuring the acceleration of gravity, but can be used to measure the upwards acceleration that counters gravity when at rest. This acceleration is measured as $1g$ on the z-axis, when both pitch and roll angles are zero, but when the sensor is tilted either the x-axis or the y-axis experiences a component of the upward acceleration, whose magnitude depends on the tilt angle.

Pitch & Roll estimation

Obtaining the pitch and roll angles is then a matter of being able to read the accelerometer, convert these readings to the g unit (1g = 9.8 m/s²), and apply the corresponding equations. The process of obtaining and converting the accelerometer readings depends on the accelerometer you are using, in my case, the ADXL345 in its basic configuration, provides 10-bit resolution for ±2g, but has several other ranges (±2g, ±4g, ±8g, ±16g) and resolutions (from 10 to 13 bits depending on the range) . Generalizing, the formula used to calculate the acceleration from the accelerometer readings is:

$G_{Accel} = Raw_{Accel} \cdot \dfrac{Range}{2^{Resolution - 1}}$

Once we have the correct acceleration components, we can proceed to calculate the different angles using the following equations:

$pitch = \arctan{\left(\dfrac{G_y}{\sqrt{G_{x}^2 + G_{z}^2}}\right)}$ $roll =\arctan{\left( \dfrac{-G_x}{ G_{z}}\right)}$

For more information about where these equations come from, you can read the documentation I include at the end of this post. As you can see, the denominator of the pitch equation is defined to be always positive, so the equation itself only provides $[-90, 90]$ range, which is exactly what is expected for the pitch angle. In contrast, the roll equation provides $[-180, 180]$ range. It is important to take into account that when the pitch angle is 90º, the surge axis (roll) is directly aligned with the gravity vector, thus we cannot measure the roll angle anymore, this is what is called Gimbal Lock.

Also, be aware that the roll equation is undefined when both $G_x$ and $G_z$ are equal to zero, and that for each possible value of the calculation done inside the arctan function there are two valid solutions, not only on the roll but also on the pitch equation. These problems can be easily solved in code by using the function atan2, which eliminates the angle calculation ambiguity by taking into account the quadrant.

Removing short-term fluctuations using a Low-Pass filter

At this point we already have a fully functional pitch & roll estimation system, but if we experiment with it we will discover that the readings fluctuate quite a bit and this may be very annoying for some applications. Removing these short-term fluctuations can be achieved by means of what is called a Low-Pass filter. This type of filter attenuates the higher frequencies of the signal, thus providing a smoother reading. The Low-Pass filter is easily implemented by using the following equation:

$y_{t} = \alpha \cdot x_{t} + (1 - \alpha) \cdot y_{t - 1}$

Where $y_t$ is our filtered signal, $y_{t-1}$ the previous filtered signal, $x_t$ the accelerometer reading and $\alpha$ the smoothing factor. It probably may seem obvious, but filtering should be done to the accelerometer readings before calculating the angles, instead of to the angles themselves. Regarding the smoothing factor, the lower we set it, the more it will take for the angle to stabilize, so we should not set it too low because then we could lose real-time behaviour. With this I mean that the reading will not correspond to the real angle until it stabilizes, and this could take some time.

The source code & the ADXL345 library

I developed a small library to interface with the accelerometer, even though at the moment I have only implemented the basic functionality, I plan on supporting all of the device features. You can find it in my github account, where you can also find the processing code I used for the video example below. Thanks to the library, the code is pretty straightforward. It just reads the sensor accelerations which are already converted into gs by the library, applies the Low-Pass filter and then uses the roll and pitch equations to calculate the angles.

#include
#include 

const float alpha = 0.5;

double fXg = 0;
double fYg = 0;
double fZg = 0;

ADXL345 acc;

void setup()
{
        acc.begin();
        Serial.begin(9600);
        delay(100);
}

void loop()
{
        double pitch, roll, Xg, Yg, Zg;
        acc.read(&Xg, &Yg, &Zg);

        //Low Pass Filter
        fXg = Xg * alpha + (fXg * (1.0 - alpha));
        fYg = Yg * alpha + (fYg * (1.0 - alpha));
        fZg = Zg * alpha + (fZg * (1.0 - alpha));

        //Roll & Pitch Equations
        roll  = (atan2(-fYg, fZg)*180.0)/M_PI;
        pitch = (atan2(fXg, sqrt(fYg*fYg + fZg*fZg))*180.0)/M_PI;

        Serial.print(pitch);
        Serial.print(":");
        Serial.println(roll);

        delay(10);
}

Links & References

Source | ADXL345-Accelerometer Arduino Library & Processing
Documentation | AN3461 – Tilt Sensing Using Linear Accelerometers
Fritzing Part |

Hello World!

Welcome to The C Continuum!

Even though this blog is called The C Continuum, it’s not only going to be about programming in C, I will probably talk about other languages (prolog, haskell, C++, python, …) and other topics (maths, physics, computer science, …).

But as we are in The C continuum, this introductory post will be dedicated to the first step in the process of learning a new programming language: the very simple, yet enlightening, Hello World! program:

#include 

int main (int argc, char *argv[])
{
    GtkWidget *window, *label;

    gtk_init(&argc, &argv);

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Hello World!");
    gtk_container_set_border_width(GTK_CONTAINER(window), 10);
    gtk_widget_set_size_request(window, 210, 100);

    g_signal_connect(G_OBJECT(window), "destroy",
                     gtk_main_quit, NULL);
    label = gtk_label_new("Hello World!");
    gtk_container_add(GTK_CONTAINER(window), label);

    gtk_widget_show_all(window);

    gtk_main();

    return 0;
}

As you may already know, the code above is written in C and uses the GTK library to generate a graphical interface. If you wish to compile the code you can use the following command:

    gcc -Wall `pkg-config --cflags --libs gtk+-2.0` hello.c -o hello

Enjoy!