Category: Robotics

Unfortunately, Silvestre is not getting too much attention this year due to the lack of time but there was still some work to do regarding the acceleration: https://dani.foroselectronica.es/silvestre-getting-ready-for-2012-230/

The acceleration graph was quite good but still not as good as it could be. One of the main problems was the DC-DC converter which was unable to provide enough current at stall so we designed a new one and these are the results:

  X axis represent time in 4.8 ms units

Compared to the results obtained last year, Silvestre is able to run 1 meter longer in the same time and its top speed is also higher. The price to be paid for this extra power is a higher current consumption which has to be taken into account when choosing the right battery for the competition.

The new DC-DC converter board has to be carefully analyzed and I hope to write a new post about it soon.

Dani

After some months resting, Silvestre’s got back to work this past weekend and the first thing we’ve done is to enhance the communication protocol in order to get even more data in real time on the PC. This data is essential to study software, hardware and mechanical aspects now that we’ve got a quite stable platform, and we need to focus on subtle things.

We plan to make some improvements over the way Silvestre speeds up and brakes so we definitely need to know how it behaves in both situations:

Blue line shows the maximum speed of the wheels (no friction) whereas red line shows Silvestre speed when motors are set to 100% from a stopped position. The track surface is pretty much the same as the one used in most of line followers contests in Spain and wheels were carefully cleaned beforehand. The result after mixing up the signals from the accelerometer and encoders (graph) showed that, during the acceleration phase, wheels didn’t skid.

As you can see, the robot can reach up to 5.6m/s in 0.9 seconds after having traveled a distance of about 4 meters and, in a typical straight in contests of around 2 meters, Silvestre would have to face a turn at about 5 meters per second yet making it harder to get back to a safe speed if the next turn is very close. Hence, we need to learn the track very well during the first laps so that we can precisely know the highest safe speed at every point of the circuit and also, we need to get a great control over the braking phase to slow down into such speed as fast as possible.

So far we had little time to improve the braking and graph isn’t showing good data from second 1 ahead but special attention has to be paid on how weights are transferred while deccelerating because the robot might lose traction thus making it to brake earlier. I look forward to working more on characterizing dynamic aspects of the robot and making the most out of it

I’m back from the 15th edition of Campus Party and it was a great success for us regarding the competitions we took part in. Here are the results:

• Web/Mobile App Development Challenge by Coritel (Accenture) – Innovation Area: 1st place!
• “Best of Show” Robotics competition: 1st place
• “Speed Runners” Robotics competition: 1st and 2nd places
• “Campus Climbers” Robotics competition: 3rd place

I enjoyed very much this edition of Campus Party attending  great conferences  and meeting up with some old friends again and new people into robotics and technology. I’m already looking forward to the next edition and seeing more cool stuff during a whole week in Valencia 🙂

D.

I wrote an application for Android OS based devices to control the uXbot robot remotelly via Bluetooth. This has been my first experience with Android development and, even though the UI creation isn’t very straightforward, the rest of the features such as Bluetooth discovering, pairing or sensor data acquisition have been fairly easy.

Features:

• Inertial control using device accelerometer
• Manual control using a Joystick widget (from https://code.google.com/p/mobile-anarchy-widgets/)
• Adjustable speed
• Bluetooth SPP connection

I’ll be uploading some videos in the next few days and, when it’s a little bit more tested, I’ll be glad to publish the sources so that anyone can add new features (IR sensor readings, battery voltage, firmware uploading using uXbot internal bluetooth bootloader,…).

UPDATE:

Daniel

Last 8th October took place the 3rd edition of the CRJET International Robotics Competition in Cataluña.

Silvestre was the WINNER of the Line Following Robots category. During the qualifying session in the morning, Silvestre set the fastest time, completing 3 laps to the 11.752 meters track in 14.02 seconds (2.5m/s average speed). Piolin – Silvestre’s little brother – made the second best time at qualifying but had some issues and got a final 3rd place losing against Shibuya in the Semifinal round.

Its revolutionary positioning system allowed Silvestre to identify the main straight and to speed up to 4.8 m/s. Thanks to its inertial sensors and the wheel encoders, Silvestre could brake at the right point reaching the corner at a safe speed. This strategy had not been seen in any Line Follower competitions so far making Silvestre look even more impressive.

 Silvestre Highlights (the slow motion part is very cool 😉 )

Final Race, Silvestre VS Shibuya:

For the next contests, the challenge is to make another key improvement to keep Silvestre on the top of the podium.

Also, Tobias was awarded with the “Most High-Tech” prize in the “Best of Show” category so it was a pretty successful weekend 🙂

Daniel

Silvestre is a line following robot who was born early this year. So far, he’s competed in two national contests in Spain achieving a 5th place in the first one and winning the other one.Among his main  features:

• 8 Infrared sensors
• Two Maxon DC motors
• Bluetooth enabled (telemetry and configuration)
• LPC2148 ARM7 32-bit microcontroller
• PD Loop running at 100Hz
• Error estimation using cubic interpolation over the IR sensors data
• Accelerometer and gyro sensors

In the video above you can see Silvestre running on a 8.44m long track. Whenever he crosses the mark, sends the lap time over the Bluetooth link to a PC software which displays the timing information along with some other data such as battery level. In the best lap in the video he can reach up to 2.24m/s and as long as the wheels become dirty, the grip decreases and therefore, the times get worse.

The microcontroler’s got 512KB the flash. Half of this memory’s currently holding a custom filesystem to store configuration profiles (speed, PID constants, enabling/disabling features, etc.) which can be loaded, stored and deleted through the PC software.

In order to speed up the communication between the computer and the robots we designed a low bandwith binary protocol with error correction which’s been implemented and optimized carefuly in all of our robots. This way, the development of new software (for both robot and computer side)  gets simplified from the communication point of view and there’s no need to start over again every time. You can see an screenshot of the PC application we’ve built:

RL-Telemetry application

The inertial sensors help Silvestre to measure how good he’s performing and enables him to adjust the speed and PID constants as  the wheels are losing grip. Basically, the accelerometer data is used to accelerate faster to the setpoint speed whereas the gyro tells him whether he starts drifting (too much angular acceleration).

In the contests being held in Spain, there are no marks indicating when a lap has started so there’s no way for the robot to figure out when to modify its parameters  so something that might be useful as well with the gyro data is to be aware of the actual orientation of the robot. Thus, integrating the gyro signal, Silvestre knows when he is facing the initial position again and this is likely the starting point. However, this approach is not valid when the track’s got two or more straights in the same direction because the robot will get to 360º and the lap’s not been completed yet.

The key for improving Silvestre’s performance has been undoubtely the ability to gather data from the sensors in real-time so that they can be later analysed on a computer.

My friend Alberto Calvo and me have worked hard on this robot and we’re looking forward for new contests and challenges. Our main goal, rather than just following a line, was researching how the usage of inertial sensors and self-learning processes could be applied on this kind of robots.  We’re still working on Silvestre in our spare times so I’ll probably update this post soon.

Daniel

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).

• IDE: CodeLite
• Toolchain : CodeSourcery G++ Lite for ARM EABI

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

• Mechanical Description:

• • 4mm thick PVC sheets
  • High torque motors (0.69 Nm)
  • High grip wheels (95mm diameter)
  • High momentum of inertia (~1.5 kg and modifiable Gravity Center with lead sheets)

• Electronics:

• • RL-LPC2140 Microcontroller board (LPC2148 32-bit)
  • RL-AMC50NP04 H-Bridge MOSFET board
  • DC-DC power supply fixed to 10V
  • Homemade Inertial Measurement Unit (3-axis accelerometer plus 1-axis gyro)

• Inertial Measurement Unit:

• • 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:

Daniel