Team 2 (2010)

Welcome to the webpage for Natcar Team 2, 2010. Check here for announcements, updates, design documentation, and media.

While many people have built Natcars, my incarnation will be unique in that I am developing the hardware platform in parallel with a complete software simulation. While it can be painful at times, I believe that hand analysis, mathematical modeling, and computer simulation are critical tools in the design process. I developed the basic features of the computer simulation over summer, so I have a working platform to build on. The first phase of the project will culminate in a paper, which I hope will include the following

Modeling of non-idealities in the Natcar environment including sensor orientation, noise, non-idealities of the analog input signal path, finite sampling rate and resolution, time delays, mass, inertia, and friction
Methods for dealing with non-idealities, quantification of results, and comparison to naïve implementation
Quantification and comparison of different control algorithms

Some elements of the paper will be generally applicable, but it will mostly be framed in terms of my particular hardware design. For example, the analog input path will be based on my circuit design. I will be designing the hardware at the same time as the simulation, and hopefully both will mutually benefit from insights gained in the other. In scope for the hardware design is

Selection of RC car chassis, electrical characterization of motor and servo, development of mechanical constraints on sensor mounting and electronics
Schematics and part selection for all circuits
Hand analysis and SPICE simulation of relevant circuits
Prototyping of relevant circuits on breadboard and characterization of performance
Power analysis of subsystems and overall system

Over winter break, I will start laying out the PCBs in EAGLE and assembling the boards. Winter quarter will be devoted to assembling the hardware, refining the paper and making a poster, and debugging, testing, and optimizing my implementation. With luck, I'll finish in time for the competition in May.

Updates & Announcements

11/5/09: This week's meeting will be on Friday 11/6/09 at 4pm in EBU-II 333B.
10/27/09: This week's meeting will be on Friday 10/30/09 at 11:30am in the CSE basement. We will probably move to the ECE lab so that we can test the sensor circuit and characterize the motor.
10/26/09: Selected and ordered Microcontroller: LPC2103 on Coridium ARMMite Pro board. 60Mhz ARM7 processor with 8-channel 10-bit A/D. Found RC car chassis in old project space, no longer need to by chassis. Finished modeling magnetic sensor placement. Designed sensor circuitry, modeled in matlab and Simulink, ordered part samples from TI. Added ability to specify arbitrary sensor orientation and integration over sensor area to NatcarSim simulation.
10/10/09: Team webpage created.
9/24/09: NatcarSim posted to Google Code under GPL v3 license. Anonymous checkout and source code browsing is allowed. Permission to check in requires authorization by me.

Team

Name	Role	Email
Jordan Rhee	Team Lead	rhee.jordan@gmail.com
Hernando Rico	Electrical/Software	hrico@ucsd.edu
William Breidenthal	Electrical/Software	wbreiden@ucsd.edu
Robert Moroto	Electrical/Mechanical	rmoroto@ucsd.edu

Strategy/Approach

The goal of the Natcar project is to build an autonomous car that can race around track marked by a wire carrying a sinusoidal current. Natcar is a control system. If we define the error signal as the car’s distance from the track, then minimizing this value will keep the car on the track. A mechatronic control system interacts with the real world through sensing and actuation. Since the rules require a 1/10 scale RC car, actuation is already defined for us: steering and acceleration. For sensing, there are at least two options for generating a signal proportional to the car’s distance from the track: 1) using optics or 2) using electromagnetism.

Figure 1. General control system. In Natcar, the system input is the car’s wheel angle and acceleration. The output is the car’s position, orientation, and velocity. The measured output is a signal proportional to the car’s horizontal displacement from the track, and the reference is 0 since we want the car to be centered on the track.

Since the course is marked by white tape, an optical approach might use a camera and image processing to try to “see” the track and determine the car’s position and orientation relative to the track. While an optical approach would allow looking ahead to know the curvature of the track relatively far into the future, the practical challenges in implementing a real-time video processing system fast enough be useful are very hard. One would need a very powerful computer or highly optimized custom hardware to do video processing that fast. There simply isn’t enough physical space or power for a general purpose computer, and I don’t have the time, expertise, or money to design a custom video processing system.

The electromagnetic approach is much more practical. This approach uses Faraday’s law of induction, which states that the induced electromotive force or EMF in any closed circuit is equal to the time rate of change of the magnetic flux through the circuit. We know from the Biot-Savart law that an electric current generates a magnetic field, so there is a sinusoidally varying magnetic field around the wire which marks the track. If we place a coil near the track, this sinusoidally-varying magnetic field will induce a sinusoidally-varying voltage in the coil. The magnitude of the induced sin wave will depend on the coil’s orientation and distance from the wire. Therefore, the error signal (our distance from the track) is amplitude modulated on a carrier of 75Khz. If we place two sensors on the front bumper of the car, we can determine the car’s horizontal displacement relative to the track as the difference of the sensor values.

A system design for Natcar is now becoming clear. One decision we must make is how to implement the controller. Some Natcar teams do completely analog implementations, but I will use a general purpose microcontroller to implement a digital control system. The advantages of digital over analog are numerous: noise immunity, algorithmic flexibility, reduced power consumption, reduced cost. The rules put the following additional requirements on our implementation:

· The entire system must be powered by a single 7.2V standard RC car battery

· The power supply must be built from ICs and discrete components, i.e. no preassembled “blocks”

· The motor driver must be built from ICs and discrete components

From these requirements we can sketch a block diagram of each of the subsystems.

Figure 2. Natcar functional block diagram.

Now we want to design and implement each of the blocks. First we must consider dependencies between subsystems and come up with a design strategy. The motor driver is dependent on the electrical characteristics of the motor. Therefore, we must select a chassis and characterize the motor before designing a driver. The steering servo comes with the chassis, and will be driven by a PWM signal. To design the sensors, we must first characterize the input signal and know the input voltage range of the microcontroller’s ADC. To select the microcontroller, we must know the required sampling rate and resolution of the ADC, minimum clock speed of the CPU, number and type of IOs. We must also consider factors such as processor architecture, quality and availability of development tools, and cost. The user interface will depend on the control algorithm and the IOs of the microcontroller. Finally, we will design the power supply once we know the voltage and current requirements of each of the subsystems. The dependencies in the design flow are visualized in the following diagram.

Figure 3. Electronics Design Flow Dependencies. Arrow points in direction of dependency.

Work may now proceed on the individual components in any topologically sorted order.

Design

Let us define the input path as the system that translates the car’s physical distance from the track to a digital error signal suitable for input to the controller. The signal originates at the coils, in which a voltage is induced proportional to the time rate of change of the magnetic flux through the coils. The magnitude of the induced voltage depends on the distance and orientation of the coils from the track. We must now design a system which takes this signal input and translates it into a digital signal suitable for processing. The system includes analog circuitry, the ADC, and any subsequent digital processing that we do in the microcontroller. The analog circuitry needs to amplify the sensed signal, demodulate the 75Khz carrier, and low-pass filter the signal to avoid aliasing at the ADC. We can draw a block diagram of the system:

First, we want to characterize the input signal so that we can design the electronics and select a sampling frequency. Let’s do some back of the envelope calculations to get an idea of the magnitude of the input voltage and the useful frequency content. First, let’s calculate the magnitude of the induced voltage versus distance from the track. To simplify our calculations, we’ll assume we’re using square coils with turns located in the plane of the track.

We can now formulate the problem into something you might have seen on your high school AP Physics exam: A square coil with turns and sides of length is placed distance from an infinitely long wire carrying current . Derive and expression for , the voltage measured between two terminals of the coil.

We’ll use faraday’s law to calculate the induced EMF in the coil.

So the output is a sin wave with magnitude . Let us plot the magnitude of the induced voltage versus distance for several sizes of the coil. This will give us an idea of our input voltage range.

If we were to place our sensors directly against the floor, the input signal range would be about 1-25mV. Our microcontroller’s ADCs have an input range of 0-3V so we would need a gain of 120. The ADCs have 10 bits of resolution, so we would be able to resolve the entire dynamic range of the input signal.

So far our model is not realistic because it is not possible to locate our sensors directly against the floor. We’ll leverage the work of UC Berkeley student Darren Liccardo in his paper “Natcar Magnetic Sensor Modeling” to model more realistic sensor placement. We will extend his model by integrating over the area of the sensor. Note that we are NOT using the same coordinate system or direction conventions as him. The diagram below is drawn as if you were sitting in the car, looking forward at the track and the sensors. The sensor is square, extending units in the positive y direction (into the page). The wire also lies along the y axis, and current flows into the page.

We can write the magnetic field as a function of and :

The normal vector of the sensor is

The flux through the coil is then

Where

The magnitude of the induced voltage as a function distance, height,9 angle, and inductor size is:

Let’s plot voltage versus distance for several sensor angles, choosing a height of 1cm, sensor size of 1cm, and .

Left: Right:

Supposing we choose the orientation which has the least dynamic range () with a maximum voltage of about 5mV, we would need a gain of 1000 to boost the signal up to 5V.

Now that we have an idea of our input signal voltage range, we want to get an idea of the useful frequency content so we can select a sampling frequency and design our filters accordingly. The fastest Natcars travel at average speeds of around 10ft/s, so we’ll assume that 20ft/s is the fastest our car would ever go. The slowest part of the system is the steering servo, which has a response time on the order of tens of milliseconds. While the slow mechanical system sets the overall response time of the system, it is desirable to sample as fast as possible so that we can use the signal for detection and classification of the track. Therefore we will design our analog circuitry with a bandwidth of 10Khz, and sample at 20Khz or greater.

Designing the Sensor Circuitry

Now that we’ve characterized our input signal in terms of voltage range and frequency content, we can design the circuit. We wish to design a circuit which implements the following block diagram.

Before we dive into circuit design, let’s first use Simulink to verify the block diagram.

The input signal is modeled as a 10Khz sin wave double sideband AM modulated on a 75Khz carrier superimposed on high frequency white noise. The analog lowpass filter is a 5^th order butterworth filter with 3db frequency 10khz. The quantizer has and . Simulating the system over several periods of the input yields the following output.

Figure 4. Simulink output for the input path. Top: the input signal modulated on a 75Khz carrier with HF noise. Middle: the amplified, rectified signal and low-pass filtered analog signal. Bottom: the sampled, quantized signal.

We can see from the Simulink output that our block diagram is valid. That is, we can recover the original 10khz signal from the modulated, noisy signal. Now that we’ve verified the block diagram, we can go ahead and design the circuit. We will design everything with a single 5V supply. I have done the design on paper, so I will present the results and justify the design.

Note that there will be four of these circuits – one for each sensor.

The first stage accomplishes gain and half-wave rectification. The gain is achieved in two stages: a fixed gain of 50 followed by a variable gain of . The Texas Instruments INA156 is a rail-to-rail output CMOS instrumentation amplifier with a fixed gain of 50. By referencing the output to ground, we can also achieve half-wave precision rectification in this stage. When the input goes negative, the output will saturate at 0V. The requirements on this stage are a closed loop BW > 80Khz, and slew rate . The INA156 has and , so it meets the requirements. It also has high input impedance, high common mode rejection, and low input bias current. Since our sensor (a coil) can be modeled as a voltage source in series with a very high resistance, a high input impedance is desirable. Furthermore, the sensors are located several inches away from the board and will be connected to the board with wires. The signal will pick up common mode noise, so an instrumentation amplifier is desirable because it amplifies the difference of the signals, reducing common mode noise. The variable gain stage is implemented as a non-inverting amplifier that uses a trimpot for adjusting the gain. The trimpot can be used to fine-tune the gain after the circuit is assembled. This also allows flexibility in sensor selection and placement.

The filter stage is a 5^th order Butterworth low pass filter with cutoff frequency of . From simulations, we saw that the system needed at least a 3rd order filter. The OPA4340 is a quad opamp package, so we might as well use all the opamps available to us and make a 5^th order filter. The normalized transfer function of a 5^th order butterworth LPF is

We implement the 2^nd order terms using Sallen-Key topology. The last stage is an amplifier and ADC driver. The signal processing takes place between 0-5V, and the input voltage range of the ADC is 0-3V. The half-wave rectified signal only has half the power of the original signal, so after the filter stage, the signal will have magnitude of 2.5V or less. Simulink simulations indicated that a gain of 2 was necessary to boost the voltage back up to the ADC’s full input range.

The OPA 4340 is a quad op amp package, so the variable gain stage, filter stage, and output buffer can be implemented with 1 IC. There are 2 ICs per channel (INA156 and OPA4340) and 4 channels, so the final board will have 8 ICs plus an onboard 5V LDO and decoupling capacitors.

Pictures

This team does not yet have any pictures.

Videos

Here is a video showing output from the natcar-sim computer simulation. NatcarSim is a software project that simulates the physics and control logic of the robot in its environment, and visualizes the results using OpenGL. In this video, the car is using a (poorly tuned) PID controller. On each step of the simulation, the car can ask the environment what the magnetic field is at a point relative to itself. Since the car doesn't know its location, the environment translates the relative coordinates to absolute coordinates and calculates the magnetic field at that point using the track geometry. The car may only update its speed and wheel angle each step. The environment keeps track of its position and orientation. In this video, the environment is ideal and there is no mass, no friction, and no noise. The code is written in C++ and uses OpenGL for graphics and UBLAS for numeric computation.

Poster & Publications

This team does not yet have any publications.