I want to introduce you the brand-new uXbot (micro xBot) robot. It has been designed for educational purposes and with the main goal of serving as a base for the Robotics Workshop at Campus-Party España 2010.
Features:
ARM Cortex-M3 32 bit Microcontroller (LPC1343)
Motor driver up to 3.5A
12 Infrared sensors
Integrated battery charger
Battery Voltage monitoring
Firmware Programming via USB
4 General Purpose LEDs
800mAh Li-Po battery
Metal Gearbox motors
Bluetooth module
In order to make the development process easier, some libraries have been written for the end user with the following layout:
HALLib (Hardware Abstraction Layer Library): Provides an interface to uXbot hardware and the microcontroller peripherals such as sensor reading, pushbutton, voltage monitor, motors, timing functions.
VCOMLib: Provides a USB Virtual COM Port driver (ACM profile under Linux OS) so that the user can communicate to a PC.
uXbotLib: This is a high-level library which will be mainly used by users who do not have/need to have any knowledge about the underlying electronics of the uXbot. It provides an interface to move the robot in any direction, an open-loop PID controller for line following, sensor reading and filtering, etc.
All the tools used to develop applications for the uXbot are free and available for both Windows and Linux OS (32 and 64-bit).
In order to control the uXbot through the USB VCom port or Bluetooth, a C# application has been written. Anyone will be able to use it from Windows or Linux (using Mono). Here you can see an screenshot:
I want to show you two videos. In the first one you can see the uXbot being controlled from a Windows Mobile device using a simply C# application which sends commands to the motors depending upon the PDA acclerometer sensor readings. It’s pretty funny and addicting In the second one, the uXbot is following a black line at an average speed of 1.65 meters per second.
I would like to publish all the source and diagrams soon, so stay tunned
Daniel
PS. You can find more information at www.uxbot.es (Wiki & Forum in Spanish).
Since the very first moment I saw a 2-wheel self-balancing robot I got amazed about all the engineering behind it and I was so excited to build one myself. So now that it’s become a reality let me introduce you to TOBIAS
Accelerometer: Slow response & sensitive to acceleration forces due to movement
Gyroscope: Fast response & integration drift for angle estimation
Need to mix up the information from both sensors: Kalman Filter
Kalman Filter:
In this graphic you can see some data captured in real time by the microcontroller and then dumped offline to a PC for a later analysis.
The blue signal represents the estimated angle using just the raw data from the accelerometer: arc-tangent of y-axis by x-axis acceleration.
The green signal is the integration of the gyro sensor which clearly shows the drift over the time.
The red signal is the actual angle estimated by the Kalman Filter which shows that in the balancing state the angle falls between -3 and 3 degrees. Block Diagram:
Here you can see the block diagram of the complete system. First, you can observe that the signals are sampled at 3200Hz (oversampling) and then low-pass filtered with a Finite Impulse Response (FIR) Filter with a cutoff frequency of 100Hz.
A 16x decimator is then used to obtain signals with a bandwith of 200Hz and no aliasing. This filtering process improved the angle estimation so much because a lot of noise was removed.
The inputs for the Kalman Filter are the angular rate and the estimated angle from the accelerometer which is computed using an atan2 function call. After that, some tests reported that the angle output by the KF had a precision of about .1º which looks really accurate.
This angle is ready to be processed in order to apply the right torque to the motors using a PID controller -tunned by hand- with more effort than expected (and desired). The integral part of the PID is computed by the trapezoidal rule while the derivative component is calculated using a 7-steps Savitzky-Golay derivator.
The output of the PID is then applied to both motors in order to keep it balanced.
Implementation:
The LPC2148 is a very powerful 32-bit microcontroller which shouldn’t have many problems acting as TOBIAS’ brain. However, the firmware was as optimized as possible in order to allow future improvements and, in the mean time, keep the processor in power down mode while not doing anything to save battery (every mA of current counts ;)).
In order to figure out how the microcontroller could handle all the tasks, a profiling of the execution was performed using a GPIO and a logic analyzer:
As you can see from the image above, there’s plenty of time for the microcontroller to do some other things. This time was used mainly for logging purposes and in the current version, to read from a IR receiver and controlling TOBIAS using a cheap remote controller from an RC helicopter. This performance was achieved after optimizing the code of the most computationally expensive tasks (Kalman & PID). Also these functions execute from RAM and try to make a good use of the MAM (Memory Accelerator Module) hardware in order to speed its execution up as much as possible.
Considerations for future improvements:
The first approach was building a fairly good balancing robot without spending too much money and now I can say that it was definitely achieved.
The sensors used in the IMU were taken off a cheap PS3 gamepad bought on eBay, there’s no commercial electronic boards (entirely own design) - apart from the cheap step up/down DC-DC controller ($15) -, and both the plastic sheets and wheels are quite cheap and, thus, the overall cost of the robot doesn’t go beyond the 100€ ($140-$150).
However, the cheap motors made all the project a little bit more difficult (and challenging at the same time) than expected: they were not enough responsive and the gearbox wasn’t tight enough allowing you to turn the wheels freely about 3 degrees.
I’m sure that if another motors were used in TOBIAS, the performance would have been way better but it was more exciting to face the PID tunning and the signal processing under these ‘negative’ conditions.
References & Greetings:
T.O.B.B. Balancing Robot by Matthias Toussaint: I would like to thank Matthias so much for answering my e-mails and pointing me in the right direction with his unvaluable advice. All the signal processing was based on TOBB’s and the only main difference is that TOBB uses a very interesting complimentary filter (instead of Kalman) which works incredibly well as you can see in the video posted on his site. Thanks once again Matthias because I learnt a lot from you !!
Also big thanks to my friend Alberto Calvo, the co-author, who also made the 3D artwork shown in the article
Final Result:
All in all, it’s been a very interesting project and, as a reward, TOBIAS won a prize in the Freestyle Robotics Contest at Campus Party ‘09 last summer.
In this video you can see TOBIAS in action:
I’ve started to build some sort of two-wheel Balancing Robot and before getting the party started I’m having to deal with mixing up the data gathered from my inertal sensors.
My homebrew IMU (Inertial Measurement Unit) is composed by one 3-axis accelerometer and 1-axis gyroscope. The gyro sensor’s got an analog output (.67mV per degree/s) and the accelerometer’s got an i2c interface. I would love to share its part number with you but, since I liked this unit to be as cheap as possible, the sensors were ripped out (and reverse-engineered with a logic analyzer) from a cheap PS3 gamepad bought on eBay ;).
Since the output of the gyro sensor is ‘too low’ for my ADC, I built a simple non-inverter amplifier and a low pass filter with a cutoff frequency of 1KHz. Also I placed a high pass filter (cutoff frequency at .3Hz) in order to compensate the temperature drift. The data from the accelerometer’s digitally filtered on the microcontroller with a simple 1st order Butterworth filter.
The main idea of this kind of robots (inverted pendulum) is to measure the tilt angle in order to drive the wheels just below the mass. The higher the center of gravity, the easier balancing will be. Why do we need both an accelerometer and a gyro?
- The acclerometer senses not only the gravity (tilt) but the acceleration forces on its axis. So it would be useful if it was static (no acceleration due to movement).
- The gyro outputs angular velocity (degrees per second) and it’s not sensitive to acceleration. In order to get the angular position we have to integrate this signal. However this will drift over the time and the estimated tilt angle wouldn’t be accurate after some seconds.
The ‘trick’ is to take out the best of each sensor: the long-term information from the accelerometer and the short-term response from the gyro sensor. One way to do this is using a ‘black-box’ known as Kalman Filter (if you are brave enough, have a look at the theory; I’m not :)) which mixes up both signals predicting the actual tilt angle.
I got some source code of this filter from rotomotion (http://scratchpad.wikia.com/wiki/RotomotionCode) and pushed it directly onto my microcontroller. The sensors are sampled at 50Hz and fed to the KF at the same rate. In the next plot you can see the raw tilt angle (atan2(raw_accy, raw_accx)), the integral of the gyro sensor (using the trapezoidal rule) and the output of the Kalman Filter.
As you can see, the raw tilt angle is a little bit noisy while the gyro integration is very clean. Also, there’s a lot of drift in this signal but magically the KF manages to estimate the angle very accuratelly and free of noise.
Now it’s time to try the filter with stronger movements and vibrations before feeding its output to the PID which will - hopefully - make the robot balance
I’m working on a project which involves an i2c communication between a master and some slaves. The master device is using an LPC2148 microcontroller running at 60 MHz and the slave ones have a low-cost PIC microcontroller. Each slave device runs a different task and some of them are more CPU-intensive than others.
The nature of this i2c communication is essentially some kind of Query-Response protocol in which the master requests some processing from the slaves and they send back the results to the master. The processing time varies from one slave to another and sometimes it will be higher than the master ‘clock’ time.
This leaded me to find a way to stop the master until the slave is done with its processing: clock stretching. The slave will pull the clock line down, causing the master to stop until it’s done with its task and then releases the SCL line (going high due to the required pull-ups of the i2c signals).
As I was writing the slave C code using PICC compiler, there was no way to implement this technique directly from the supplied i2c functions therefore I’d got to implement it by myself:
if(state >= 0x80) //Master is requesting data
{
SCL_STRECTHING_ON
delay_us(400); // Simulate processing delay
i2c_write(buffer[cnt++]);
SCL_STRETCHING_OFF
}
Please, note that the values defined for SSPCON register / bits are for PIC16F677 microcontroller and it might differ from the one you’re using.
Below you can see an screenshot of the Logic Analyzer output I used for testing purposes. You can see the 400 us delay between two consecutive readings from the master while the SCL line remains low.
All in all, it’s a well known technique described in the protocol specification but as far as I’m concerned by googling a little bit, its usage is not very extended and there are not so much source code out there addressing this issue.
RL-AMC-50NP04 is an advanced Full H-Bridge board based on high performance MOSFETs capable of driving two high power DC motors. It has been designed to achieve a great efficiency and usage simplicity since just 3 pins are needed to control a motor. Based on the large experience working with Robotics we designed this board keeping in mind some important factors such as power dissipation, heating, simplicity and functionalities like braking, bi-directional control of the motors and a wide range of PWM frequencies from 3.3v or 5V microcontrollers.
Its small size makes this H-Bridge MOSFET board perfect to fit in your Robotics designs: 50 x 42 mm (1,97 x 1,65 inch) .
Main features:
2 high power DC Motors control.
PWM frequencies up to 20 KHz for speed control.
Bi-directional control.
Braking function (coast and brake functions).
3.3v / 5V logic capable.
Up to 8A continuous operation with very low internal resistance (0.038 ohms).
Up to 35A pulsed current.
Wide range of power supply voltage ranging from 3 to 40V.
Current sense (just 6mV per amp to minimize the total voltage drop when high currents are demanded).
Just 3 pins needed from your microcontroller to drive each motor.
Two LEDs per leg indicating the rotating direction of each motor.
Easy interface connections through an standard 10-pin male header.
Three two-pin terminal blocks for connecting the motors and their power supply.
Logic power supply ranging from 2V to 6V.
Here you can see the output of the board when driving one of its LEDs with a voltage supply of 8,4V. The voltage drop accross the LED is about 1 Volt and in this graphic you can appreciate that the rising and falling times are extremely small since it has been designed for operating in high-speed environments with the maximum efficiency. This minimizes the transition time of the MOSFETs (time when their internal Rds resistance is higher) and, thus, also minimizes the total power dissipation due to switching power losses.
If you are interested in this board or have any further questions / suggestions don’t hesitate to contact me.
DIEZ is a line following robot which has been designed for several national contests being held in Spain throughout the year.
The goal for this kind of robots is to follow a black line over a white floor as quick as possible. The track has also branches which should be taken properly by the robot. It should be able to read some little strips located at both sides of the track which shows the robot the right direction to take in the next branch. In almost all the competitions, taking the wrong side of the branch makes the robot to travel a longer distance and, sometimes involves a 10-15 seconds penalty over the total time achieved.
The tracks usually have many turns and 90 degrees corners so DIEZ has been designed to be lightweight and small in order to achieve these movements as fast as possible with the less moment of inertia.
Prior to the final assembly of the robot, a CAD design was performed when all the decisions about the design were made. Here you can see a GIF showing the first steps from CAD to assembly phases:
Sensors, Control Board and Algorithm:
The main board is an LPC2138-01 based on a 32-bit LPC2138 microcontroller at 60 MIPS.
The sensor board’s got 10 tiny SMD reflective sensors which are read by the microcontroller with one of its A/D converters. Due to the different light conditions in the contests and sometimes, the camera flashes and the reflection ratios of the track surfaces, DIEZ performs an ambient light cancelation by reading the sensors with the IR led switched off. Besides, the IR led light is modulated to achieve an even more reliable reading from the sensors.
The control algorithm used by DIEZ is a PD controller. The input of the controller is the position of the center of the line, which is estimated using an interpolation function of the values read from the sensor board. A C# application’s been developed to test and debug the algorithm before coding it into the microcontroller. Here you can see an screenshot of this program which allowed us to monitor in Real Time what the robot saw in every moment. Also, thanks to the SD socket of the LPC2138-01 board, the robot was recording all the data and parameters on it for a later study with this program. This was specially useful to detect some of the problems of the algorithm because we had all the telemetry. This recording was quite feasible using the Embedded File System Library since the robot just had to create a new telemetry file on a FAT32 filesystem which was perefctly readable from any computer.
Weight and Dimensions
The total weight of DIEZ is less than 400 gr (about 14 oz) with two Li-Po batteries (1450 mAh).
Its size is 15 x 15 x 7 cm (5.9 x 5.9 x 2.7 inches).
Video
Here you can see a video with DIEZ in action. Those ‘ugly’ pink thingies on its wheels are stripes of a water balloon which we had handy to increase the adherence and, thus, the maximum speed to reach a corner. Due to its light weight, these rubbers were necessary to avoid the skids.
That’s all
Again, hope you liked the article.
Regards,
Daniel Alvarez
Slayer is a special robot for me. It was my first line following robot and he has won several National Robotics Contests in Spain (Robolid and X-Treme Robotrackers at Campus Bot).
It’s got just two motors: a servo motor to stick its nose to the line and a DC motor with a small gearbox to achieve the movement.
The control board is based on ATMega32 which is a very nice 8bit microcontroller equiped with 32KB of Flash and 2KB of SRAM memory.
The sensor board’s got 8 infrared sensors and its acquisition is multiplexed to minimize the required IO pins. Also, an ambient light cancelation is performed so that the robot could be able to run in different light conditions and (almost) over any surfaces.
The picture on the right shows the simulator developed to test the algorithm in the PC. It helped me to tune the PID controller and to check all the computation done by the microcontroller. Basically I developed a tiny “RTOS” for the ATMega32 with a cyclic scheduler to achieve the acquisition, computation and PID task in Real-Time at the desired frequency.
At these competitions, the robots have to follow a black line over a white surface as fast as possible by taking the correct way in all the branches. The right way is indicated by a small black line located in the side to which the robot should take in the incoming branch. For this reason, the algorithm’s got to be accurate enough in identifying the marks and branches as well as smooth enough to complete the track as fast as possible. Also, the track has got 90 degrees corners which usually become the headache of the competitors.
In this video you can watch Slayer in the Final round of Robolid 2006 competition. It got the fastest time and no penalties because it took all the branches correctly.
This robot was developed by my colleague and friend Alberto Calvo and me during our studies at University. We got the best possible mark because of the originality and complexity of it.
It’s got 8 Hitec servos (2 per leg) and it could perform some nice sequences of movement which looked really natural. All the control was achieved inside a Xilinx Spartan II FPGA and the code was entirely written in VHDL. The servo controller was a hardware core which accepted a 8bit word for the position and another 8bit word to set the desired speed.
The sequencer and the interface to the PC was implemented inside a PicoBlaze microcontroller synthetized directly into the FPGA. There was no kind of feedback and it just played the stored sequences in its memory but it was quite flexible since we managed to simulate them on the PC.
This is an old project (2003) and due to a data loss I cannot recover any videos or screenshots but I will try to rebuild it someday.
In the second one, the uXbot is following a black line at an average speed of 1.65 meters per second.
