Mikroe Buggy: Obstacle Avoiding Robot

Aug 22, 2015 0 comments

In this post I will show how to create an obstacle avoiding robot using the MikroElektronika Buggy, equipped with a Clicker2 for PIC18FJ microcontroller board, plus one Proximity Click board and one Bargraph click board. The reason I choose the PIC18 microcontroller is that I already have the MikroC PRO for PIC full license. While there are a few Click boards that can perform distance measurements, the VCNL4010-based Proximity Click allows for the greatest range, of almost 20cm. Finally, the Bargraph Click is used to provide a visual indication of the proximity measurement: the closer the object in front of the rover, the higher the indication on the bargraph.

The hardware is deceptively simple. Just plug the Proximity Click into mikroBUS socket #1 (front-left one), the Bargraph Click into mikroBUS socket #3 (the one in the rear) and install the Clicker2 for PIC18FJ board. That’s all.

The software takes fully advantage of the existing Libstock code for the sensor boards, as well as the Buggy itself. Of course, some changes had to be made for this particular applications. You may notice that instead of posting one huge code listing I decided to split the code into some smaller files that are #included in the main program. The reason is that this approach simplyfies the reuse of the code in future projects. As such, four files are part of the project: the Obstacle Avoiding Robot.c contains the main code, inside VCNL40x0_PIC18_BUGGY.c we find the code related to the proximity sensor, the BUGGY_PIC18_BARGRAPH.c contains the code for the bargraph display, while the BUGGY_PIC18_FUNCTIONS.c has pins definitions and code for the Buggy itself. The code listings of these files is as follows:


The code in this file is based on the existing Libstock example, of which I have stripped all unnecessary information. I have also changed the code to work with I2C2, to match the PIC18F87J50 pinout.


Once again, the code in this file is based on an existing Libstock example. The file contains the pin definitions corresponding to mikroBUS socket #3 on the Buggy, and the functions required by the HC595 shift register. Note that the input of the BarGraph_Display function must be between 0 and 10. No checks are performed against values outside this range.


In this file we find pin definitions for LEDs on the Clicker2 for PIC18FJ, pin definitions for the lights on the Buggy, and the functions to initialize and move the Buggy. One might observe that there is only a function to turn the Buggy to the right. There is nothing wrong here, as in the main code I choose a right-turn-only strategy. If needed, a left turn function can be added easily.


Finally, the main piece of code. Here we first #include all the above code, and then we define some variables. Then we define the VCNL_update_proxi function, which gets the proximity value from the VCNL4010, updates the bargraph and then returns the proximity value.

The main code performs some self-test, such as flashing the LEDs on the Clicker 2 for PIC18FJ, then initializes and performs a self-test of the bargraph. Later, the VCNL4010 is initialized, and the average reading with no obstacle in front of the sensor is computed. A short note here: allow at least 30cm clear space in front of the rover when you start it, or else the proximity sensor will not initialize correctly.

Furthermore, the Buggy is initialized. This sets the appropriate TRIS registers for the pins that control the LEDs, and initializes the PWM pins that control the motors.

After the initialization is complete, we are ready to go. We start forward, until the robot senses the approach of an obstacle. At that point the breaks are applied, and the brake lights turn on. As it happens with a regular car, the inertial forces still drive the Buggy forward. When the second threshold is reached, the Buggy drives backward for about 3 seconds, signal lights flashing. A right turn is then performed, and the Buggy resumes its forward course.

Another observation here is that we don’t have any motor encoders, so a perfect 90 degrees turn is not possible. All I can do is to adjust the delays until the rover performs a satisfactory trajectory.

With all these explanations, here is the code listing:

Related Posts


{{posts[0].date}} {{posts[0].commentsNum}} {{messages_comments}}


{{posts[1].date}} {{posts[1].commentsNum}} {{messages_comments}}


{{posts[2].date}} {{posts[2].commentsNum}} {{messages_comments}}

Contact Form


Email *

Message *

Recent Comments