The goal of this university Robotics project was to design and implement two control functions of a wheeled robot.  These control functions were Manual Wireless control via Bluetooth and Magnetic Path following via GMR (Giant Magnetoresistance) Sensor control.

In the end a fully functional robot was constructed.  The tasks that the robot successfully accomplished were:

  • Bluetooth wireless communication
  • Closed loop PI controller implementation
  • Manual control via keyboard input and navigation of obstacle course
  • Autonomous steering via GMR sensors and navigation of obstacle course


The software was divided into many sections of which there are some sub-sections. The sections are as follows:

  1. Set-up and Initialize: Header of the program that contains all of the global definitions, including statements, function prototypes and so forth.
  2. Main Thread: Main body of program which reads the users commands.
    1. Configure: Instructions for selecting mode of operation and calibrating sensors if required.
    2. Manual Mode: Reading user inputs for manual steering and velocity control.
    3. GMR Mode: Reading user inputs for manual velocity control.
  3. GMR Control Thread: Reading GMR sensors to determine position of robot relative to path.
  4. PI Control Thread: Reading QEI sensors to determine velocity of robot relative to set points.
  5. Motor Control Functions: Conversion of control signals to outputs.
  6. Debugging and Control: Print out various information and control whether or not to use the encoders and PI Control Thread

Setup and Initialize

Before the program runs, there are various housekeeping requirements. All the required libraries are imported as well as numerous definitions and global variables are declared. The function prototypes are listed as well as initializing the GMR and PI threads.

Manual Control

Once in Manual Control Mode the robot is controlled by the keyboard via the Bluetooth interface. The user has full control of the velocity and steering. The user manipulates the variables “Set” and “Steer”. These later combine to form each wheels set point:

Using the w/s keys the user increases/decreases the “Set” variable by +/-0.5 (cm/s) respectively. For quicker acceleration the t/g keys perform the same function but change the variable by +/-2 (cm/s). The a/d keys control the “Steer” variable and increase/decrease it by +/-0.25 (cm/s). In addition to these keys the space bar provides and emergency stop setting all variables to 0, and the f key straightens out the robot by setting the “Steer” variable to 0.

The set points are calculated and stored as global variables. These are then compared to the PI Control Thread readings as the desired speed of each wheel. This will be described in further detail later.

GMR Control

Once GMR Mode is entered the user is prompted to begin a calibration routine. For this routine the user must slide the GMRs over the wire (or other magnetic source) at their operational height and in the proper orientation relative to the field as outlined by the GMR datasheet. While doing this the MBED will take inputs from both of the GMRs and calculate their Max and Min readings. The Max value corresponds to each sensors β value (described later) and the Min value is the voltage offset due to the hardware configuration. If during this calibration routine the Max value is found to be 0V, the program will print out an error message telling the user that there is an error and which GMR is having issue. If there are no errors the user is instructed to enter the separation distance of the two GMR sensors in cm. Once this is done the robot is ready to follow the path.

The robot will sit idle until the user increases the velocity with the w/s keys as described in the Manual Control section. Different from the manual control section the user only has these keys and the emergency brake (space bar) for input. The steering is controlled by the GMR readings.

The GMR thread will begin by reading each GMR reading. The A to D reading for MBED will scale the voltage reading down to 0-1 floating point. This value has to be scaled back up to its actual voltage level and the offset needs to be removed. Once this is done a proper differential curve can be made by subtracting one reading from the other.

The effects of this are demonstrated in the graphic below, the two peaks represent the position of the two GMRs.

From these two GMR readings the error can be calculated. If the “Diff” is positive then the wire is closer to the left GMR and a Negative “Diff” has the wire closer to the right GMR. The error is calculated with the following formula:

With the error calculated the “Steer” variable can be generated to finish the set point. This is simply done by multiplying the error by a constant to convert it from cm to cm/s.

PI Control

The PI Control thread takes the set points for each wheel and compares them to readings from the QEIs and makes corrections where required. This thread begins by reading the two encoders from the DE0 board. To do this a brief pulse is sent to trigger a write from the DE0 followed by a control word to determine where to write from and how many variables to send. This is done twice, once to read number of ticks from the encoder and the time elapsed since the last read for the right wheel, then again for the left wheel.

These values as they are aren’t of much use initially; they need to be converted into wheel velocities of cm/s for uniform comparisons. To do this the pulley and gearbox ratios need to be evaluated as well as the encoder ticks need to be converted to angular velocity. For the supplied 1.8o two channel encoders this is accomplished with the following formula:


  • N = # of ticks read from encoder (dPosition)
  • t = time elapsed since last read (dTime)
  • Ng = Gearbox ratio
  • Np = Pulley ratio
  • Rw = Radius of wheel (cm)

With this conversion done the standard PI control calculations can be made. The error, e, comes from the difference of the calculated velocity and the desired set point velocity. The xState integrator is approximated with the Euler approximation (x = x+e). Then these values are multiplied by the PI constants to generate an output, u.

There are some checks to ensure there wasn’t any overflows, prevent integrator windup and bound variables though. To check for overflow a basic check is performed. If the error is positive but the calculated velocity is less than the set point then there was an overflow so the error is set to a Max value. Similarly for negative overflow a Min error can be set. The integrator windup is prevented by checking if the final output, u, is saturated. If this is the case the integrator, x, is reset to 0. All these variables (e, x, u) are bound with max and min values as well.

The final u for right and left wheels are passed to the motor control functions.

Motor Control

To operate the H-bridges the MBED bust sent a direction bit (high or low) and a PWM signal for controlling the speed. To generate these values a variable is passed to the respective motor control function. This variable is converted to a percentage of the wheels max speed then a quick check is done to ensure it is within max/min bounds of +/-100%, the value will saturate if required.

The PWM is generated by using the percentage of max wheel velocity to compute the on/off time of the PWM. The period is set to 20ms so if a wheel speed of 50ms is required then the PWM will be set to have a pulse of 50%*20ms=10ms. To find the direction all that is required is the sign of the passed value. Since the motors are mounted on opposite sides of the vehicle one has to turn opposite to the other to make the robot drive forwards, i.e. DirR=1 and DirL=0.

Debugging and Control

Included in the code is a Debugging module. This is a rudimentary module but proved to be very helpful. This function requires the MBED to be connected to a computer via USB as large amounts of data may be transmitted which could cause trouble for the Bluetooth. It is simply a global variable and depending on what it is set to, different information will be printed out to the screen. The various debugging options include:

Debug = 0 –> Print Out Nothing
Debug = 1 –> Print Out GMR Calibration Readings
Debug = 2 –> Print Out PI Control GMR Readings
Debug = 3 –> Print Out Tracking Results (Roadway)
Debug = 4 –> Print Out e, x, u Calculation Results
Debug = 5 –> Print Out GMR Motor Outputs
Debug = 6 –> Print Out Encoder Readings from DE0
Debug = 7 –> Print Out Calculated Wheel Velocities
Debug = 8 –> Print Out dVel, e, x, u, setpoint for each wheel (Right then Left)

Most of these are simply printing out calculated variables. One of interest though is Debug Mode 3, Roadway. This is a convenient way of checking the GMRs and where they think the wire is located. This will print out a scrolling map, i.e. it will update and print a new estimation of the wires location. The map displays the two GMRs with a marker for where the wire is located based on the calculated error at a given time. An example is below is shown in the Testing section of this report.

The other option is a variable called “Control”. This variable will simply turn the PI control thread on or off. When high, 1, the program will operate to its full potential as was described in previous sections. If set low, 0, the PI Thread will be bypassed and instead of sending the control signals, u, the set points are sent directly to the Motor Control Threads. This is helpful for testing individual hardware components.


QEI Interface

– Pull-up resistors on QEI channels

For the wiring on the bread board, extensive pre-planning was performed in order to avoid any cluttering and danger of circuit shorting. Also, it helped during the troubleshooting phase to find the wiring path with minimal effort. The wiring paths on the breadboard are shown in Figure 5 at its final stages. The pull-up resistors on Quadrature Encoder Interface are shown with numbers 1 and 2 for the left and right encoders respectively. Also, the UNB DEx Breakout Board’s connections were placed on 3 and 4. The connections between the MBED chip and FPGA board via the UNB DEx Breakout Board were followed as in Figure 6 from the lecture notes. Also, the QEIs’ connections were connected to 10 and 11 for left and right motor.

GMR & OP Amps

To use the GMR sensors and amplify their output, an op-amp was required; but in order to achieve a higher input resistance, two buffers were required for both outputs of the GMR sensor. For each GMR, a TL084 was used, as they have four TL081 op-amps built in. During the testing phase, it was determined that TL084 doesn’t work properly and as expected by one voltage source. To overcome this issue, the 8V source of the power supply was used and it was split in half and a virtual ground was created using a voltage divider, as it can be seen in Figure 7.​

This setup could provide two voltage sources with ±4V and a virtual ground, which helped to operate the buffers and op-amp as it was expected. The voltage divider is shown by number 6 in Figure 5. By selecting the values of R2 and R3 equal to 8.25kΩ and 604Ω, the gain of the op-amp was set to 13.66V/V. It was important to control the gain in order to preventing the voltage goes higher than 3.3V as it was the maximum voltage input for the analog input pins of the MBED chip.

As it will be mentioned in the Testing and Tuning section, the GMR sensors were mounted 2.5” ahead of the wheel axle, with 5cm separation from each other. This was chosen as the best tracking result could be achieved.


To control the motors, the UNB H-Bridge ver. 1.2 was used as it allow to control two different motors simultaneously using PWM, DIR, enable, break and ground pins for each motor. For this design, only the PWM, direction, and ground pins were used as the other pins were not required for this particular setup. The operation method has already been described in the software section. The Motor1 and Motor2 connections were used for the left and right motor respectively.

To control the robot wirelessly, UNB Bluetooth Adapter Board and Linksys Bluetooth Adaptor were used.

To setup the connection after powering the robot up the following commands should be entered using the Putty terminal emulator and port 4, after loading and running the Source Code Snippets in the MDEB, based on the course note instructions:


Then add the Bluetooth device on the computer that will be used to control the robot. All other settings and port speed configurations have already been set as per the course notes.


The MBED NXP LPC1768 was used as the central processing unit for this robot. The following list describes the pin usage and configuration:

AnalogIn GMR1(p19); // Left GMR input
AnalogIn GMR2(p20); // Right GMR input
DigitalOut MotorRDir(p26); // Direction Control Right Motor
PwmOut MotorRpwm(p25); // Speed Control Right Motor
DigitalOut MotorLDir(p24); // Direction Control Left Motor
PwmOut MotorLpwm(p23); // Speed Control Left Motor
Serial BluetoothSerial(p28, p27); // (tx, rx) for PC serial channel
SPI DE0(p5, p6, p7); // (mosi, miso, sclk) DE0 is the SPI channel with the DE0
DigitalOut SpiReset(p12); // DE0 Reset (pulse high then low to trigger reset)
DigitalOut SpiStart(p11); // DE0 Start Read (pulse high then low to trigger read)

Along with the Ground and +Voltage for powering up the MBED independently from the USB connection.

It is critical to tie the grounds of MBED, DE0 and GMR sensors, in order to receive meaningful signal in the input pins of the MBED. One issue that rises in this setup is that tying the GMR ground to the MBED causes a voltage offset of 4 volts which is greater than the maximum input of the MBED pins. To fix this problem, two voltage dividers, using 1kΩ resistors, were added in path of op-amp outputs (Number 9 in Figure 5) to the pins 19 and 20of the MBED in order to divide the voltage by two. This new addition and other connections can be seen in Figure 8.

Testing and Tuning

Manual Control

Since the robot was being controlled by an operator this testing was performed by having an operator attempt to navigate obstacles (pop cans) on the floor. The control variables Set and Steer were then manipulated to speed up or slowdown that given control aspect and the test was repeated. This was more of an exercise of tuning the robot to the operator’s skill level as opposed to a scientific test of performance. The results of the tuning are listed below.

PI Controller

Tuning the PI controller wasn’t a high priority for this project. Even a poorly tuned PI controller can control a process considerably well. The focus of this design team was to ensure the robot could overcome the obstacles that it would encounter. Basic visual inspection was performed to ensure that the PI control gains (Kp and Ki) weren’t so high that there were extreme or violent oscillations in the robot but this was not the case. Some basic tuning was done in junction with the Manual Control tuning to alter the agility of the robot. In the end the values used were Kp=0.75 and Ki=0.9. This resulted in a PI controller that by visual inspection performed extremely well at Manual and GMR Automated control. A sample of the calculation results are displayed below.

GMR Control

Roadway Test

The first test was early on in the construction to verify the operation of the GMR circuitry and the MBED calculations. This was the Debug Mode 3 described earlier. Two GMRs were placed on a T-bar and they were waved over top of a current carrying wire in the proper orientation as described in their data sheet. The MBED would read the GMRs every 500ms and print out a display of where the MBED thinks the wire is located based on the calculated error. This was also compared to oscilloscope readings. The bars, |, represent the position of each GMR while the x’s represent the estimated wire location based on the differential sensor setup and error calculation. Time scrolls with the printout on the vertical axis. A sample of the results is shown below where the wire starts in the middle, then the T-bar and sensors slide to the left (i.e. the wire moves right relative to the center of the sensors) and then back.

Once the GMR array was mounted on the robot and connected to the rest of the circuitry a problem was encountered though. The reference ground for the GMR array was 4V above that of the MBED ground due to the split rail and virtual ground method that was implemented. This offset was accounted for with a voltage divider and in the code as described earlier but now the GMR sensors lost much of their sensitivity and a dead zone was created in the middle. The Roadway test changed considerably.

As can be seen in the figure above there are now jumps in the error calculations. The test was performed repeatedly to ensure that the sensors weren’t passing over the wire too quickly between readings but this was proven not to be the cause. The offset from the GMRs created this problem now. This problem can also be seen if the GMRs are placed too far apart. The peak values are at the extremes closest to each sensor but there is a large section in between the sensors where the wire is too far from both sensors to provide an adequate reading. One solution to this issues is to mount the GMRs closer together but this wasn’t desirable as the array can pass over the wire entirely if there is too large of a twitch from the robot and the natural oscillation of a PI controller. Once the GMR array was mounted to the robot this didn’t prove to be much of a hindrance and the sensors still provided enough of a differential reading to control the robot.

GMR – Axle Relationship

The GMR array was initially mounted to the front of the robot, 12” away from the drive axle. To test the GMRs in this position a test course was constructed from a current carrying wire (to generate a magnetic field) with two obstacles. There was a 6” radius half circle turn (included a 6” radius quarter circle entrance and exit) as well as a step impulse of 0.5”. These two obstacles were deemed to be the most difficult and if they could be accomplished then the rest of the course could as well.

The robot then attempted to navigate the course. The step impulse was surpassed immediately with not changes required but the sharp 6” turns proved to be a challenge. The robot would begin to navigate the turn but eventually the sensors and the wire would approach a parallel orientation with the tangent to the wire. This would cause both sensors to read the same value and the robot would think the wire was located close to the center of the sensors and drive forward, losing the wire entirely. This is demonstrated below.

This problem was not a factor of the GMR separation but rather the distance between the GMR array and the drive axle. Tests were then performed moving the sensor array closer and closer to the drive axle with the goal to be navigating the impulse and 6” radius turn. The results are tabulated below.

View the code here.

This course was among the most practical and interesting courses in the undergrad program and it provided a great opportunity to implement the theoretical concepts that I had learned during the past few years, such as PI controller, and the use of it in a real world fully functional machine.

You can also see the video of the final product while my teammate and I were presenting it to the class:

Leave a Reply

Your email address will not be published. Required fields are marked *