Neck movement of InMoov robotic head

A quick update on the project. In below video you can see the InMoov robotic head now moving its neck. Movements are 2 type of rotations: "yaw" by the servo inside the head, and "pitch" by the screw + servo mechanism.

For controls I used the previous Arduino+Shield used before (previous post). On the video the robots moves controlled manually by the potentiometers on the shield and automatic on a fixed sequence.

Humanoid Robot Head (based on InMoov project)

I´ve following for a while InMoov project. It´s an open source humanoid robot from French designer Gaël Langevin, who has done a great job accomplishing a nice and stylish robot.

Two years ago I started working as a full time lecturer at the Costa Rica Institute of Technology, I see this project as an engagement tool to attract high school students into STEM majors at college. 

InMoov website has detailed construction videos, bills of materials and stl files for the 3D printed parts. We 3D printed all those head parts and follow the assembly instructions. We took special care on the outside parts to make our robot look extra cool, so we applied automotive primer sealer and carefully sanded everything to get that nice and smooth finish, then we painted it white. For the eyes I followed Gaël's design on using a thermoplastic material to cover the eye balls to make them look glossy and shiny. It really enhances the appearance of the robot. 

 

On InMoov webpage the control of the robot is done by a software called MyRobotLab, however I decided to just used and Arduino. I also used 3 shields above the Arduino, one to power all the servos and 2 of them for the joysticks.

The robot has 2 servos on the eyes to make a 2 dimensional movement, one servo to open-close the jaw and 2 servos on the neck. Currently there’s only 1 servo running on the neck, I expect to mount the remaining one soon. 

My first job on the Arduino code was to set the center of each servo and the limits they can reach before something breaks. Then I put some code to map the joystick positions (they are just potentiometers) and map those movements as an increment/decrement on servo position.

Future work on the Robot Head is will be making a strong and nice looking head base (not a cardboard box ;) ) and installing in it the missing neck servo. Then we want to start merging this robot with a chatbot done by an investigator at the university, and hopefully we will have a talking robot!

The Arduino code is available here: GithubGist code

Humanoid robot video

Here's a video of my Bioloid humanoid robot. As mentioned in a previous post, I controlled it using a BeagleBone Black embedded system instead of its propietary controller. I created the routines for arms, legs and hips to move based on inverse kinematics equations, trajectory generators, and some high level behaviours.

Information about the project was in a previous post here.
Detailed information is here (in spanish).
All code used is here.

My humanoid robot (Bioloid robot controlled by a BeagleBone Black)

Well... actually it was not mine but from my university, but I used for my master thesis and I showed him how to move from scratch.

The details on the mathematical calculations and code implemented is detailed on my thesis. You can find it here (it´s in Spanish).

Bioloid robot with a BeagleBone Black board on the chest.

Usually Bioloid humanoid robots are controlled by Robotis proprietary controller (a microcontroller board) and their proprietary software. On that system, basic moves are already being done and you just have to program the high level instructions you want, like: "Robot, go get me some coffee", well maybe not so high level but you have basic moves like "walk forward" or "turn right" already programed. The idea at the university research center (AI2) was to replace that controller and use an embedded system instead, specifically a BeagleBone Black. By using an embedded system on future Bioloid projects, we could use the benefits of this type of system like true parallelism in processes, extended computation capacity and easy integration with cameras and IMUs. But before this, the guts of the system had to be done, and here I come...

My thesis objective was to develop the Locomotion libraries (in an API) for the robot to move, that is creating from scratch all the movements on the robot in order to have some high order instructions like the proprietary software have.

That's me with my robot.

The first thing I did is that I used the code created for a single robotic arm (see previous post) and used for the two arms in the robot. For the legs to move I programmed the kinematic equations that describe the movement of the foot using hip as a reference and the equations that describe the hip movement using foot as a reference. The reason to have 2 sets of equations for the legs is that for example walking is divided in two main phases: foot on ground (here you move the hip) and foot on air (here you move the foot). Likewise I created two linear trajectories generators, one for the foot and one for the hip. Both were generate movements in straight lines since it´s important to control on every moment were the foot and hip is, and avoid this way any possible unstable position.

Matlab simulation of the legs as kinematics chains.

This time for the communications from the BeagleBone Black to the servos (Dynamixel bus) I used an USB2Dynamixel device. The low level drivers for the BeagleBone Black to send the Dynamixel data frames was created by David Cisternes as a generic API for communications on a Dynamixel bus.

Next task was to create those high level movements everybody loves, so for example for a movement "one step forward" I divided the movement into 7 different segments: lean sideway, lift foot, low loft, move hip forward and sideway, lift back foot, low back foot, return to normal position. Then I created the trajectories for all the limbs during each segment. This duty required a lot of trial and error correction to reach a stable movement.

Robot during one the segments of "one step forward" movement.

I called this high level movements as "behaviors" in order to be used on a state machine that ruled the robot logic. The robot would move between behaviors based on the input from sensors, in my case the ones implemented on the smart foot (see previous post). Finally the robot was able to climb or descend stairs (not big ones, it was a small robot after all!), walk forward and make small turns to the right or left.

Robot climbing one step of a stair

Robot descending the same step of the stair

The code used on the BeagleBone Black and my thesis are on my GitHub web: https://github.com/jcbrenes/Bioloid-Locomotion-API

Arduino based smart feet for a Bioloid robot (Arduino as slave on Dynamixel bus)

During my Master thesis, I was in the need for some proprioception from a humanoid robot’s foot. The final objective was to make the humanoid robot climb and descent stairs, so I placed some pressure sensors and a proximity sensor on the robot foot.

With all these sensors in the foot, having a direct wiring to the controller would imply a lot of cables (ground, vcc, signals…), therefore I decided to connect them to the Dynamixel bus. I used an Arduino Nano for this matter.

I used a Sharp GP2Y0A21YK0F proximity sensor and four FSR pressure sensors, all connected to the Arduino analog inputs. FSR sensors are quite noisy, so I applied a rolling average to filter the measured values.

Arduino has a UART TTL that communicates using 3 lines: Tx, Rx, and GND. Dynamixel communication bus has 3 different lines: Vcc, GND and Data; this last one used to send and receive. To convert the 2 data lines on the Arduino board to only one, I used and 74LS241 chip that has several 3 states buffers by implementing the connections described in this web. Note that I had to use an enable signal from the Arduino to the buffer.

External circuit from Arduino to Dynamixel bus. Image from Savage Electronics.

I programmed the Arduino to keep listening to serial messages on the serial bus, when he detects the header of the Dynamixel data frame, then go to check the ID of the device, and if it is the right ID, check the rest of the message.

Dynamixel frame format. Message sent from Master to Slave.

Data from each sensor were assigned to a different address, creating this way a logical table with sensor data. When the Arduino is asked for data from a specific address, it will respond with a message with a 2 byte value as showed in the following example.

Dynamixel frame format. Message response from Slave to Master.

Finally I soldered all the circuits created on a prototype board and placed the Arduino Nano on top of the components to save space. Looking like below picture. Pins are for connection to sensors and Dynamixel bus.

Implemented circuit (components are below Arduino Nano).

When I placed the board into the foot and connected the sensors, I looked like the following pictures.

Assembled circuit on the robot's foot

New smart feet placed on the robot.

Arduino code is on my github web: https://github.com/jcbrenes/Planta-SerialDynamixel

New Robotic Arm with Dynamixel servos

During the last year and some months I was getting my Master degree. As part of the embedded systems class, I created a Robotic Arm that could write some letters. Pretty cool, right?

The arm has 3 Degrees of Freedom (DOF) using Dynamixel RX-10 servos. I controlled the robot with a Beaglebone Black board with a cape that has a MAX485 chip. This chip converts UART TTL communications to RS-485 differential protocol (used on the Dynamixel servos). Also. I had to create some drivers for the controller to speak Dynamixel language (specific data frames format) on the communications bus.

For the arm to reach some point in 3D space, I programmed the kinematic equations that translated this desired point to a set of angles for the servos. I used the equations proposed by Núñez et al on the paper “Explicit analytic solution for inverse kinematics of Bioloid humanoid robot” (IEEE paper site).

Also I created two trajectories generators: one for free trajectories (moving from 1 point to another without care of the described trajectory) and one for linear  trajectories (moving between 2 points describing a straight line).

Finally I programmed the a routine on the robot using these trajectories functions, so it can describe some letters on a vertical plane. Here's a video of the robot:

The code for the project is found here: project link.
Also here is the technical document for the project (in spanish): document link

My github site: https://github.com/jcbrenes

Getting feedback from the servo

You see, hobby servos are extremely easy to use but they are also pretty dumb, you would say them something like go to position “75 degrees” and then you will have faith that it reaches that point; but you really don’t get any confirmation from the servo. So if you are having a situation that can induce some bias on the position, like a lot of torque applied against the rotor, you don’t get any clue to where it actually is (besides visual feedback when you see the robot arm smashing somewhere it shouldn’t smash).

I decided I want to know where the servo rotor and horn actually are located at any time. For this endeavor I used the potentiometer that is already built in the servo.

First I opened the servo. Then I desoldered the connections from the servo PCB to the motor, so I could remove the PCB and gain access to the potentiometer. Once I was able to see the potentiometer I soldered a wire to the connection point in the middle (there are 3 connection points). I made a small notch into the servo case to put the new wire and later I soldered again the PCB to the motor. Finally I closed the servo.

Opening servo case

Servo PCB just desoldered from motor connections.
Note the potentiometer on the right, I soldered a line to  the yellow wire.

Servo closed again with the position feedback line coming from the case.

With this method I measured the voltage from the moving part of the potentiometer (that’s the middle connection point) to ground. I used the analog input in the Arduino, therefore I had to convert the analog value (a number from 0 to 1024) to a voltage value (a number from 0 to 5V).

Also to characterize which voltage value corresponds to each position, I took apart each servo from the arm and swept across all positions without any load. While I was doing this, Arduino was also sending position and measured voltage values to my PC by serial communication. With all that information, I graphed Voltage vs Position, and fitted a linear tendency line to the graph, the resulting equation from the best fit tendency line will be my model of servo position.

Shoulder servo graph with best fit line and equation.

Next step will be to use this position model into my arm code and develop some closed loop control logic to correct position based on the position feedback.

Coming from a halt... Servo calibration

Coming back from a halt… lots of things happened last year that consumed my time, but I’m back.

During the last weeks I've resuming the work I've done before. Although I have new ideas for the arm, the issue with the servos showing position errors kept bothering me; so I decided to give it a last try and solve it for good.

Background:  the issue was that the arm shows an error on the position, which increases as the arm increases its extend.  The larger error was seen on the shoulder servo. Hypothesis was error was caused by arm weight.

Debug process: First I calculated the sum of torques that will be applied to the shoulder servo (based on arm weight and extension) and compared with the spec data. Even on full extension the sum of torques won’t be larger than 4 Kg.cm (this type of units is used on hobby servos torques) and the shoulder servo (HS-755HB) is capable of holding 11kg.cm. Now, the hypothesis of weight seems not so good…

Due to Lynxmotion staff suggestion I also checked that power supply was capable to provide enough power to the arm (servos and control). My wall power adapter was sufficient and I also tried with a DC power supply (5V 2A).  Measured current consumption was around 350mA. Also with both power supplies the servos behaved similarly.

Then also due to Lynxmotion suggestion I took apart the arm and test the servo without any load… surprise! The servo kept showing errors without any load. Now, the error statement changed into: shoulder servo shows an error in position as it approaches 0 degrees.

I did some research and found some important fact about hobby servos. Their origin is very influential since they came from the RC world, where you need some precision for the center position (90 degrees) and then you just need it to go right or left but with no precise amount.

What I found on the literature is that there's an agreement about having center position with a signal of 1500us, but there's no consensus on what is signal length for 0 degrees and 180 degrees on hobby servos. 

Lynxmotion mentioned that "500 is 0 degrees, and 2500 is 180 degrees". Arduino Servo Library has "0-degree angle on the servo defaults to 544... 180-degree angle on the servo defaults to 2400. Other Arduino reference even says: "1000 is fully counter-clockwise, 2000 is fully clockwise". 

But the most important statement that I found was: "Note that some manufactures do not follow this standard very closely so that servos often respond to values between 700 and 2300".

Since I was using Arduino Servo library, it uses its default values and my experimental data was consistent with them: 547us for 0 degrees and 2392 for 180 degrees (It was slightly different from theoretic values, probably since I didn't have a scope so I used a DVM and measured Mean Voltage and then calculated time).

This article provided me some insights about how to modify time values for 0 and 180 degrees on the Arduino Servo function when declaring Servo Attach statement.  I found that my HS-755 servo has 670us for 0 degrees and 2300us for 180 degrees. I tried also with HS-422 servo and found a different set of values.

Technical conclusion: each servo might have difference time values for 0 and 180 degrees. For future settings, if I need some precision on angle settings, I need to manually measure those time values first and adjust Arduino Servo function accordingly.

Time for some reflection: the main difference this time is that I asked for help early in the debugging process. I consulted on a help forum from Lynxmotion and during the discussion process I got new ideas and found new answers. I could came to this point many time ago if I have just asked for help earlier.

Philosophical conclusion: While debugging an issue, try for a while alone but if it is taking you too much, ask for help. 

Back on writing soon

I haven't write anything new for some months, the reason for that is that I got married and I have been busy setting up our new home; but anxious the get my hands on the robot again, so new posts are coming soon!

A little pause: Class recommendation

Due to my work I had to move from Costa Rica into Houston, US; and with this I couldn't take my robot with me. I'll be in this new location until March 2013, so in the meantime I've been taking an online class of Machine Learning at Coursera (www.coursera.org). .

The class has been truly amazing, the teacher (Andrew Ng) has a great way to explain things without losing focus on the big picture, so you always understand why they are useful for. He also explains everything without assuming you know things, so you don't get lost in the subject. It's been a great experience and I strongly recommend you to take this class; it's like learning Kung-Fu for robots, I have a lot of ideas about how to apply it into my robot.

Also in the meantime, I'm trying to run a half-marathon...  

Inverse Kinematics video

I did a video about the Inverse Kinematics equations for the Arm. I also show there some of the errors I described in my previous post. And all of this is shown with some great dubstep beats... :) 

I'm quite an amateur on video editing, but I hope you like it.

Correcting displacement errors

Ok here's the deal: after putting the kinematics equations into the robot, theoretically everything was fine, but the robot was smashing into the table, it was having some deep dives heading for destruction. Why the heck was that happening?

My first thought was that maybe the controller was not calculating the right angle values, but after a quick check with a serial monitor, those values were fine. Then I thought that maybe the equations were wrong, so I simulate the different arm positions (below picture) but they were ok.

Yep, I drew the trajectories using a Logo simulator... it was fast and convenient at the time ;) 

With all the directions from controller performing as desired, I realized that some of the servos just weren't capable to go into some positions.

My theory was that it was due to the arm weight and that with larger extensions of the arm, this effect will be greater. To demonstrate that I measured the angles of the joints with several arm extensions. The shoulder servo showed a notorious error increase with larger extensions, elbow showed a relative stable error with a constant value (possible due to some assembly issue). Wrist servo had almost no error.

In summary: I had a shoulder servo that couldn't hold all the arm weight when extended and a elbow with a constant error value.

How to fix this?

On first impression the solution would be to buy a more powerful servo motor for the shoulder, but since I'm saving to buy an apartment, I don't have so much money to throw away things so easily; and the idea is not just to give muscles to the robot, but to make it more efficient.

So, I tried to help the servomotor with some elastic force. First I used the spring that Lynxmotion suggests on their page (and comes with the arm assembly parts), It helped somehow, especially for short and medium extensions, but for large extensions it was not effective. Then I added also a rubber band but the assembly behaved just the same as with only the spring.

Then I thought that if the error in the joint angle behaved always similarly, I could find an equation to describe it, therefore having an error correction equation. I made an X-Y graph with the theoretical values vs the obtained angles, added a trend line and found the equation for it; so next time I would order the servo to go to angle A in order to really go to angle B. I applied this software correction procedure to shoulder and elbow joints.

Shoulder and elbow angle functions

Ultimately, I figured out that reducing the mass of the arm, servos would perform better. So I amputated the arm and removed the wrist rotate upgrade to save some weight  (I prefer more accurate results even by eliminating 1 DOF). This last fixture gave me the best combination of low error values on shoulder and elbow joints.  

Another effect I had was that servos moved so fast that they had a large underdamped movement (that decreasing oscillation when it stops moving), hitting things due to this inaccuracy. 

When you have a motor with this issue, usually you apply a PID control to its movements and tuned it up, but since in a servo motor you do not apply a control signal directly (you just specify the desired position) this option was not feasible.

The technique used in several Arduino forums was to reduce the speed of servo, this is achieved by gradually increasing the desired position sent to the servo.

By using the error correction techniques described above and decreasing the speed of the servos, I was able to obtain smoother and more accurate results, however the best way to achieve more precise and accurate results would be to have some feedback of the joint position going to the controller, having this way a closed loop control for the position. 

In conclusion: I need to get better servos (like the Dynamixel servos) or hack the ones I have to have that position feedback in real time. 

Applying inverse kinematics to the robot

When it comes to programing the logic for your robot to move there are several paths you can take. Usually you start by specifying the position of each servo on every movement of the robot, thus giving the angles of the joints to make the arm gripper go to a certain position. This is called Forward Kinematics.

The disadvantage with Forward Kinematics is that you need to know the angle of every joint on every instant of a movement, therefore as the complexity of the movement increases it also increases the amount of angles you need to know. This characteristic makes long and tedious the duty to program your robot with the intention to go to variable positions. I started programming some moves to the robot in this way, but I quickly realized about how impractical this technique was.

If your intention is to go into more complex projects, you really don't want to program every position of every joint; you just want to tell your robotic arm (or any robotic chain) "go to X,Y,Z position". Well, that technique is called Inverse Kinematics, were you just specify the desired position of the arm gripper and the robot logic calculates the angle of every joint in order to accomplish that gripper position.

Using this technique allows you to escalate your code for higher levels of complexity, but you need to obtain the inverse kinematics equations for your robot; those are the equations that will give the joint angles (and thus servo positions) when you just input the final gripper position.
To obtain those Inverse Kinematics equations you need to image your robot arm as a series of geometric figures and use geometry principles to obtain the desired angles. I will explain how I did it for my robotic arm, but it varies according to the type of robot and the number of Degrees Of Freedom (DOF) it has.

First I started by dividing the arm assembly into the below figures, then I specified which values will be constants (in this case the lengths from joint to joint and the desired final position) and which angles will be my desired output (in this case the shoulder, elbow and wrist angles).

Geometric figures on my robotic arm

Now it comes the math-fun part: you can use the Law of Cosines to obtain the angles of a triangle by knowing the length of its sides. So we can obtain the elbow angle with the following formula:

Where c is obtained using the known sides of the triangles and Pythagoras' theorem:

Also by Law of Sines we can obtain angles A and B:

With A and B we can get the angles of the wrist (m) and shoulder (h):

Finally, I substitute the sides of the arms and the desired extension (E) on those formulas and I used them on some routines on the Arduino controller that specifies where to extend the arm. Also I created other routines for raising the arm, rotating the base, opening/closing the wrist and rotating the gripper.

By using these routines, I was able to scale my code into simpler instructions, something like: raise, rotate A degrees, go to B extension, raise, rotate C degrees, go to D extension and so on.

Note that these formulas use always the gripper perpendicular to the ground and on a 2-Dimensional space, places around the ground. Next steps will be to create these inverse kinematics equations for a 3-D space. 

Building the Robotic Arm

Building the mechanical part of the robot is one of the funniest part of projects, it’s just like building LEGOs when you were younger, but with tougher parts and tools.

Since I bought a robotic arm kit from Lynxmotion, there are detailed instructions on their webpage. You just need to follow the instructions, but pay extra attention to the pictures because not all the details are covered on the text; I had to disassemble parts several times to fix things I found they need to be in other way. Also you need to have some basic tools like screwdrivers, clippers, wrenches and allen keys. With all this, it’s just a matter of expending time on the building process and you will have a nice piece of hardware for further developments.

One interesting feature during that process is that you start to realize what are going to be some of the limitations your hardware will have and some of the challenges you will face. For example, I soon appreciated how rigid servomotors are, I mean the word actuator is literal, they just act on the way you order them to act; there's no sense of intelligence at all compared to when a animal moves a limb. Also I realized how much weight each articulation have to handle and how easy is for some servos to get stressed if too much weight is carried during many time.

One important outcome was that I discovered I want to explore more about proprioception, which is the perception of your body parts, its weight, force, position. I think that increasing this type of intelligence on robots would result into projects that could be applied to a wider range of situations.

Playing with Arduino

Learning how to use an Arduino board is a straight forward process if you follow the tutorials on Arduino page (http://arduino.cc/en/Tutorial/HomePage). You just need some basic programming skills and some basic electronic knowledge; the tutorials put everything on a very simple way.

The Arduino Environment is a higher level code based on C++ for microcontrollers; there are many libraries that cover the low level setup. For example if you use the PWM (Pulse With Modulation) library, you just have to specify the duty cycle of it; frequency of the signal is a fixed value, you can't change it easily unless you go the C++ code. This implies that Arduino code is less flexible but it also makes it a lot (really a lot!) easier to use.

After doing a lot of the examples on the tutorials, my objective was to control the servo motors to be used on my robot. So I used the servo library from Arduino to control the position of 1 servo by manipulating a potentiometer, then the same for 2 servos and then for all the 5 servos.

As I mentioned on the previous post, the Arduino Uno board can source up to 2 servos; so for sourcing all the 5 servos I used an external 5V power supply. Be careful that if you use a wall adapter power supply, not to buy any cheap one because it can be very inaccurate on the voltage it says to provide.

Then I created a costume sequence with the servos, that's a bit trickier since you have to code each servo position separately, thus you have to know where every servo should be at every moment of the sequence. This exercise is very useful since it's something pretty similar than controlling the robotic arm in an open loop project.

You can take a look at how the servos worked on the following video:

Next step will be to build the mechanical part of the robot and create some sequence for it, so that the arm can show off.

Choosing my first robot

Where to start when robotics field is so wide? Where to start with so many kinds of robots and possibilities?

Step #1: Establish my criteria.

I started by asking myself: Do I want to build from scratch my robot or do I want to buy a built one? After some deep thinking and reading a lot of people’s experiences on the web, I went to the conclusion that for the first robotic project it's better to buy at least the robot hardware, creating it would take a lot of time and at most probably you want to start putting into the robot some logic right away.  

I remember from the time I was in college the painful debugging sessions when you have a low quality hardware structure, having to adjust electrical control and software with after every mechanical adjustment. So during my research I placed strong emphasis on looking for a sturdy and robust mechanical hardware that would give me reproducible and stable results.

Finally, another positive characteristic about buying the structural hardware in that way is that I can concentrate myself on getting familiar with the electrical hardware (servo motors, sensors, and controller).  Later I can have a project regarding mechanical part, but not now.

Next question was: What Kind of robot do I want? Also a though question, the type of robot to use would define some of the challenges I would face (e.g. equilibrium for walking robots). Keeping in mind that this is my first robot I didn't want to go for the most complex type of robot right away, I better master a medium range type of robot and then I will go on to most complex ones.

I decided for a robotic arm since it's a medium complexity structure that has a wide range of possibilities. A lot of studies have been done with this type of robot which can support my learning process and it’s still very used for investigation of intelligent systems.

Step #2: Choose mechanical hardware.

With all my criteria established, I surfed the web looking robot sites. For structural hardware and motors I decided myself for a Lynmotion Robotic Arm Kit (www.lynxmotion.com) like the one in the picture below. These modular kits have a strong finish in aluminum and they have very good reviews on different websites.

Step #3:  Choose a controller.

Lynxmotion offers a control solution for its robotics arm, but I was not very attracted to it since I was looking for a control solution that is more widespread and standardized, giving me the possibility of exchanging experiences and projects (one of current challenges in robotics field is standardization). If you would like the software solution they provide you will face the same issue, it's a customized solution that works well for this specific robot (besides it is a little expensive), it lets you move the robot, create sequences and even some type of closed loops projects; but it keeps you limited to that, there's no option for communication to other PCs, mobile phones, or other controllers. At the end point I'm looking for something without those boundaries, I know it may imply developing interfaces and logic for the robot by me, but that's exactly what I'm looking for!

During the last year I have been hearing everywhere about Arduino boards, the open source hardware project. I went and checked the specs and those boards had the capabilities to control servomotors and receive feedback from sensors (there are many videos about it on youtube), there are even lots of libraries for all kind of projects, makings things like motor control easier so you don't have to do everything from scratch (not doing what it's already done, thus focusing on new things). That's the kind of collaborating platform I was looking for; Arduino is widely used and has a large community of contributors.

In particular I went for the Arduino Uno Board (the basic board, see below picture) for the same reasons I choose a robotic arm. I have worked with microcontrollers in the past but with this board you already have everything you need for the microcontroller to work and Arduino have a programming environment based on C/C++ where you don't have to program in low level C for microcontrollers, for example you don't have to configure crystal (oscillator) frequency and deal with any bug about it. This board can supply current for one or two servo motors, but as the Arduino site states, if you are going to use more motors (that's my case) you have to source them from a different power supply. It's important to separate sources from logic and power to avoid weird issues (leading to painful debugging).

I got my Arduino board and robotic Arm a couple of weeks ago, so happy to finally have the hardware here. I have been playing a little bit with the Arduino board; my next post will be about it. 

Motivation

First of all a little background about me: I have been a technology fan during all my life. I have a BS in electronic engineering and I worked for semiconductor industry for 5 years. Now I'm working on automation of processes for several industries.

Why do I want to write a blog about my experience with robots? Well I'm a robotics enthusiast, I’m always looking videos, reading webs, papers and anything related to robots; but now my intention is to pass from being a fan to become a real developer, and I want to document that journey here. I do believe that documenting is crucial in knowledge building, it also increments exposure and consequently networking with fellow enthusiasts.

What is my one year objective? Initially I want to become confident on current robot tools and techniques, starting with hobby parts and controls, then moving to more advanced projects and finally creating cutting edge projects (hopefully documenting them through papers and submitting them in well-known forums). Sometimes projects may look simple to the naked eye but I do want to embrace them with a research orientation, focusing on obtaining well documented and reproducible results rather than how visible the robot may look.

What is my long term objective? On the next years I want to pursue a post graduate degree on robotics with a research emphasis. Then my dream is to get a job in robotics, uniting my passion to my career. Someday I read that if you are doing what you love, success comes for default; so I’m looking forward to go through that path.

I kindly invite you to follow me through my posts and feel free to send a message for any question or suggestion (onecuriousrobot@gmail.com).

Best regards,

Juan Carlos Brenes
onecuriousrobot@gmail.com