Вы находитесь на странице: 1из 44

Nerdmobile Final Report

Austin Pettyjohn Pablo Oropin Kenny Barnett

Table of Contents
Introduction.2 Frame ..3 Motors..5 Equations of motion6 Wheels..9 Power Source and 5V regulator12 Gyroscope14 Accelerometer..15 Potentiometer..17 Microcontroller18 Programming...19 Motor controllers.27 Testing..31 Budget...33 Schedule35 Appendix..37

Introduction: The Nerdmobile Project has been an effort to design and create an upright, self-balancing scooter similar in design to the Segway. We were limited to a budget of $700 and given two semesters to complete the project. The Fall semester would be primarily used for designing the scooter and selecting parts, while the Spring semester would be reserved for construction and testing. From the very beginning, we knew that the projects greatest limitation would be the budget. The cheapest Segway model starts at $5000, so we realized that because we were restricted to only $700, we would have to make a lot of compromises. We looked at other groups and individuals who had made balancing scooters for between $1400 and $3000 and decided that we could achieve our goals within our budget. The specific part selection decisions will be explained in more detail in their respective sections of this report. We dubbed our scooter The Nerdmobile and decided upon the following requirements: The Nerdmobile must support a rider of 114 kilograms The Nerdmobile must reach a top speed of two meters per second The Nerdmobile must weigh less than 39 kilograms The Nerdmobile must fit through a standard door-frame The Nerdmobile must operate for 30 minutes of continuous use The Nerdmobile would be chargeable through a standard wall socket The Nerdmobile would be capable of navigating any slope or surface considered wheelchair accessible

Mechanical System
Frame We started the design phase by discussing how best to create a frame that would support the rider and the scooters components while remaining maneuverable and functional. The frame consists of two parts: the base and the tower. The base holds the weight of both the rider (up to 113 kg) as well as all the other components such as motors, battery, etc. The tower gives the rider something to hang on and contains the steering mechanism. For the base, we would have liked to use aluminum since it is very lightweight relative to the amount of weight it supports, but we found that it would simply be too costly. Instead, we decided on steel since it would support even more weight and cost roughly half as much as aluminum. To ensure that we wouldnt have any deflection or bending when we stood on the base, we decided on a steel plate that was .635 cm thick. This plate gives us the rigidity to support a rider of at least 113 kg as well as being thin enough that it is fairly easy to drill through. Though it is certainly heavier than aluminum, at only 11 kg we arent in danger of exceeding our 39 kg limit for the entire frame. The base needed to be big enough for a person to stand on comfortably, but also small enough to meet our requirement of fitting through a doorway. After sketching out various sizes on sheets of paper and standing on them, we came to the conclusion that a 61 x 38 cm base was the best balance between comfort and compactness. For the tower, we needed a material that could support a person pushing and pulling on it, allow handlebars to be mounted on it, and be mountable to the steel base. We briefly considered steel pipe, but decided it would be too heavy, too expensive, and overly rigid. After a bit more consideration, we decided to go with 5 cm diameter and 3 feet long PVC pipe. PVC is very lightweight, and more than sturdy enough to allow the rider to hang on to it. There are also a number of end attachments for PVC available, which made mounting to the base and attaching handlebars very simple. To mount the tower to the base, 3

we used PVC glue to attach a 5 cm threaded piece of PVC to the end of our tower. We then screwed that into a metal hub that was bolted to the base. To attach the handlebars to the tower, we used a PVC end piece that had a hole in the top of it. The handlebars were placed in a tightening bracket that had a hole for a .635 cm bolt at the bottom and the end of the bolt was molded to fit in the notch in the adjusting arm of the potentiometer (refer to the sensors section of this report for a more in-depth explanation of the steering process). The potentiometer was bolted onto a Plexiglas shelf that was glued inside the tower beneath the handlebars. The handlebars were then set into the groove in the potentiometer and held in place by a rectangular bracket screwed into the PVC directly below them. The whole assembly is very stable and allows smooth adjustment of the handlebars.

Figure 1: Handle bar and PVC pipe

Figure 2: Potentiometer attached to handle bar

Motors The most important mechanical component of the scooter is the motors. The motors must be strong enough to move a 39 kg scooter with a 114 kg rider on it at a quick enough rate to be able to catch up with the angle of the riders lean. They must be also be small enough to fit on the scooter, and draw a small enough amount of current that we could reach our requirement of a 30 minute runtime without needing a battery so large or heavy that we couldnt fit it on the scooter. Before we could select motors, we needed to know how much torque we would have to supply for the Nerdmobile to balance and move. To determine this, we had to first identify the equations of motion for our system. We decided to use the Lagrangian method, which would give us both a force and torque equation. First we have to set up the Lagrangian with equation (1), reproduced below. The terms K and P are separate equations for the kinetic energy (2) and the potential energy (3). Combining the two equations produces our Lagrangian

equation (4). After performing partial derivatives with respect to x we are left with the force equation

(5). Similarly we perform partial derivative of giving us our torque equation (6). We are most interested in equation (6), which we used to calculate the torques involved in the Nerdmobile. The force equation (5) is useful in determining how much force we will be placing on our system to avoid overloading it. Using equation (6), we determined that in a worst-case scenario, we would need 26 Newton-meters of torque to ensure proper operation.

Equations of Motion (1) L = K P


1 1 mc ( x 2 + l 2 2 x L sin ) + I 2 2 2

(2) K =

(3) P = mc gl cos
1 1 1 1 mc x 2 + l 2 2 mc x L sin + I 2 mc gl cos 2 2 2 2

(4) L =

(5) F = mc x

1 1 mc L sin + mc L 2 cos 2 2

(6) T =

1 mc L( x sin + 2 x cos ) + (mc l 2 + I ) mc gl sin 2

Motors, contd Now that we knew how much torque we needed, we starting shopping for motors that could supply that much. The first motors we considered were CIM motors commonly used in FIRST (For Inspiration and Recognition of Science and Technology) competitions. The following table shows the specifications of that motor:
CIM FR801-001 characteristic

Nominal Voltage Peak Power Stall Torque Stall Current No Load RPM No Load Current

12 V 337 W 2.42 Nm 133 A 5310 2.7 A

Table 1: Specification of CIM motor

Using these motors, we would have more than enough torque if we also used a gearbox with a 12:1 ratio. However, when researching the gearboxes, we found them to be prohibitively expensive at $90 each. Added to the $30 for each CIM motor, we would be up to $250 (or 35% of our budget) for just the motors. We continued searching for motors, and eventually came across the RS-550 Planetary Gearmotor. This motor is available with a variety of gearboxes attached to it, dropping it from a high RPM to a lower RPM with greatly increased torque. The best fit for our application was the 64:1 ratio gearbox, which would give us .375 Newton-meters per amp. If we supplied 40 amps, the motor would output 15 Nm of torque, giving us 30 Nm total (more than our required 26). After shipping, two of these gearmotors cost us $120.

The following table shows the characteristics of the geared motors used in the Nerdmobile.
Physical Type Reduction Stages Gear Material Weight (Gearbox only) Weight (with motor) Length (Gearbox only) Length (with motor) Width (Sqaure) Shaft Diameter Shaft Length Shaft Key Shaft End Tap Mounting Holes (12) : Planetary : 64:1 :3 : All Metal : 335g : 553g : 52mm : 109mm : 44mm : 13mm : 76mm : 3.2mm : #10-32 : #10-32 Calculated Performance* Motor Operating v Nominal v No Load RPM No Load A Stall Current Stall Torque Kt Kv : RS-550 (Pinion) : 6v - 14.4v : 12v : 302 : 1.2A : 85A : 4515 oz-in : 53.1 oz-in/A : 25 rpm/v 31884 mN-m 375 mN-m/A

Table 2: Specifications of motor used in the Nerdmobile

Wheels In our previous reports, we discussed a set of wheels that we had ordered. We discovered, after receiving them, that they had a bearing in the center of the hub. Obviously, this wouldnt work for us, since if we attached the motors shaft to the bearing, the motor would only spin that bearing and not the entire wheel. We contacted the company that we purchased them from and were able to return them for a refund. We searched for replacement wheels all over the internet and local shops, but the only wheels with a metal rim and no bearing we could find were far too expensive (more than $80 each). When we broadened our search to include plastic rims, we only found one type that was within our size range (25 33 cm) and had a center diameter that matched our shaft (1.27 cm), shown in the following figure:

Figure 3: Nerdmobile wheels

Size 30.48 cm x 4.44 cm Tread Diamond Hub 1.27 cm bore x 4.44 cm Offset 1.27 cm Shpg. 1.36 kg

These wheels were $4 on the same surplus site that we found our previous wheels. We would have liked to have found something that was a bit higher quality, but these were really our only
9

option considering the budget. The lack of durability in the plastic came to haunt us as we attempted to find ways to lock the wheels to the shaft of the motors. The first thing we tried was drilling through the center region of the wheels and dropping bolts through the holes and into the keyed region of the shaft. We then locked the bolts in place with nuts and lock washers. To prevent the wheels from sliding up and down the shaft, we used shaft collars. This solution seemed to work well, until we started running the motors. The wheels became more and more loose over time due to the fact the torque from the wheels was causing the bolts to tear away the plastic holding them in. This allowed the wheels to rotate a few degrees without turning the shaft, which in turn made it very difficult for the balancing algorithm to function properly. Next, we tried to glue a metal key into the center hub of the wheel that would catch in the keyed region of the shaft. We tried several types of glues, including J.B. Weld, acrylic cement, and epoxy. Each one failed miserably at keeping the key locked to the wheel. Our next attempt was to bolt 3 thick washers that would go around the shaft to the outside of the wheel. Across the center hole of those washers we bolted a metal bracket, and then filed it down to create a key that fit inside the keyed region of the shaft. This created a tight lock onto the shaft that we were very happy with. Unfortunately, the power of the motors tore the key right off the metal bracket with little effort. Our next idea was to create a matching keyed region in the center hub of the wheels that we could slide a piece of metal into. When creating this region with a Dremel tool, we deliberately did not cut it as long as the piece of steel we were going to use as a key. This meant that once we place the wheel on the shaft of the motor, we had to hammer the key down the shaft, creating a very tight lock. Again, this solution seemed final until we tested it with running motors. It worked for a few hours of testing, but the metal key was constantly hollowing out the plastic of the wheels, making a looser and looser fit. Eventually, the slack was so much that the
10

Nerdmobile could no longer balance itself. To rectify this, we created new key regions in the wheels, then filled them with Plumbers Goop (a type of glue/sealant) once we placed them on the shaft. When the keys were hammered into the goop/key, they made the same strong lock. Now when we ran the motors, the goop acted as a cushion against the force of the key pushing against the plastic rim. We no longer encountered the loosening problem for the rest of our testing.

Layout The following figure shows how everything was mounted underneath the base of the Nerdmobile.

120A Circuit breaker

Main circuit board Maxi fuse box


Wheel

Motor

Victor 884 motor controller

Gyroscope and accelerometer

Figure 4: Nerdmobile physical layout

11

Electronics System
Power Source and 5V regulator: A 12V lead acid battery was used for the Nerdmobile. This battery is a 30 A-Hr Duralast Gold. The reason why we chose this battery was because it small enough to fit in the base and it was the lead acid battery with the most Amp-Hr that we could find for a price that met our budget constraints, $30. Besides the battery, a 120A circuit breaker and a maxi fuse box was used for safety reasons. The following diagram shows how the power system was developed:

12V Lead Acid Battery

120A circuit breaker

Maxi fuse box with 3 40A

5V regulator LM1084

Microcontroller and sensors

Motor controllers and motors

Figure 5: Power system

We used a 120A circuit breaker for safety reasons because when lead acid batteries are completely charged, they could deliver more than 120A; thus, we used a circuit breaker to prevent any damage in the Nerdmobiles hardware. We used a Maxi fuse box able to hold 3 40A fuses so that the Victor 884, with a 40A limit, cannot be damaged in case the motors drew more than 40A. From the maxi fuse box, a 5V LM1084 was connected to maintain a constant voltage of 5V going to the main circuit board and the sensors. This voltage regulator can handle up to 8A of current draws. The microcontroller draws 250mA, the gyroscope 8mA, the accelerometer

12

0.7mA and the potentiometer 0.05. All of those electronics combined do not even draw 1A; thus, the LM1084 voltage regulator worked perfectly for the Nerdmobile. Sensors: The three sensors used in the Nerdmobile were a potentiometer, an accelerometer and a gyroscope. The potentiometer was mounted underneath the handle bar and attached to it. The accelerometer and gyroscope were mounted underneath the base.

Figure 6: Gyroscope and Accelerometer mounted underneath the base

Figure 7: Potentiometer mounted underneath handle bar

13

In order to assure a constant 5V for all three analog sensors, a LM1084 voltage regulator was used. (Please refer to the Power system section for more details) Gyroscope: In a gyroscope chip, the output signal is an analog voltage (always providing new information) proportional to angular rate about the axis normal to the top surface of the evaluation board (Refer to Figure 8). This device is also called a yaw-rate sensing device and it produces a positive going output voltage for clockwise rotation about the axis perpendicular to the top of the package. The following figure shows how RATEOUT (or the output signal) increases with clockwise rotation and decreases with counterclockwise rotation.

Figure 8: Rate out signal increases with clockwise rotation

The gyroscope used in the Nerdmobile was an ADXRS401 with a maximum angular rate sensing of 75 /s. The Nerdmobile team also considered other gyroscopes with higher maximum angular speeds: the ADXRS1501 150 /s and the ADXRS3006 300 /s, but they are

http://www.analog.com/UploadedFiles/Data_Sheets/ADXRS150.pdf

14

less precise than the ADXRS4012. All of the gyroscopes above cost $50 and they all come with evaluation boards which do not require any external components for operation. Besides that, they contain filtering circuitry, and they are not surface mount. The ADXRS150 and the ADXRS300 gyroscopes are used for tracking high angular speeds produced by machines such as airplanes or vehicles for stability control. Nevertheless, the Nerdmobile needed to track the angular speed produced by a human when leaning forward/backward. Thus, a gyroscope with lower maximum angular rate sensing, 75 /s which is half of the ADXRS150, would be fine for angular speeds produced by humans when leaning forward or backward. The following table shows the specifications of the ADXRS401 gyroscope:

Parameter Maximum angular rate sensed Scale Factor Output voltage range Power Supply Quiescent Supply Current
Table 3: ADXRS401 Characteristics

Value
75 /s 15mV//s 0-5V, 2.5 is neutral angular rate 4.75V 5.25V 6-8mA

For further information on how the gyroscope was used in the Nerdmobile, please refer to the Programming section. Accelerometer: An accelerometer was used in the Nerdmobile to calculate the leaning angle when motors are moving at a constant speed, i.e. motors are not accelerating. The following figure shows a platform tilted forward by and angle , but stationary (not accelerating horizontally).
2

http://search.analog.com/search/default.aspx?query%3Dangular%26contentType%3DProduct_Pages%26local%3Den

15

Figure 9: Accelerometer tilted forward, X axis senses some gravity

X-axis reads: (1g) sin(). By using small angle approximation: sin() . This works well (within 5%) up to = /6 = 30. Thus, the leaning angle = (Accel X axis output) / 1 g. For more info on how the accelerometer was used in the Nerdmobile, please refer to the Programming section. Different analog accelerometers where considered to use in the Nerdmobile: the ADXL203, the ADXL320, and the ADXL322. The following table shows the different characteristics of the accelerometers considered for the Nerdmobile:
ADXL3204 Yes Evaluation Board Yes $32.3 Cost $35 5g Max Range, X and Y 1.7g 174mV/g Sensitivity 1000mV/g 10% Sensitivity accuracy 6% 2.4-6V Voltage supply 3-6V 0.5mA Supply current 0.7mA Table 4: Characteristics of Accelerometers considered for the Nerdmobile ADXL2033 ADXL3225 Yes $44.93 2g 420mV/g 10% 2.4-6V 0.5mA

These three accelerometers where considered for the Nerdmobile because they all come with an evaluation board that has a filter circuitry, and do not require any surface mount equipment. However, the accelerometer used in the Nerdmobile was the ADXL203. This

3 4

www.analog.com/UploadedFiles/Evaluation_Boards_Tools/535395787ADXL203EB_0.pdf www.analog.com/UploadedFiles/Evaluation_Boards_Tools/43189285969913ADXL320EB_0.pdf 5 www.analog.com/UploadedFiles/Evaluation_Boards_Tools/669650958ADXL322EB_0.pdf

16

accelerometer was chosen because its sensitivity is twice as much as the other two. Furthermore, it provides better sensitivity accuracy than the other two accelerometers (6%). Even though the range of the ADXL203 is smaller than the other two, 1.7g, it still works perfectly for the Nerdmobile. The accelerometer senses from 0g (at a zero leaning angle) to 1g (at a leaning angle of /2rad or 1.57rad). If the accelerometer senses more than 1g, the angle cannot be calculated. Nonetheless, the maximum value coming from the accelerometer that the microcontroller will used is /6 or 0.523; therefore, this accelerometer worked fine for the Nerdmobile.

Potentiometer: The potentiometer was used for the steering mechanism of the Nerdmobile. A 100 Kohms linear potentiometer part number RV4NAYSD104A was used. The main reason to use a 100Kohms potentiometer was because the Nerdmobile group followed the guidelines provided by FIRST-kit6. Please refer to the Programming section for more info on how the potentiometer was used in the Nerdmobile.

www2.usfirst.org/2007comp/other/2007%20Guidelines_Tips_Good%20Practices_RevC.pdf

17

Microcontroller: The Microcontroller used in the Nerdmobile was a 16 bit dsPIC30F4013. Its operating frequency (time required for an instruction cycle) is 7.37 MHz which is of its clock speed of 30MHz7. This microcontroller offers the fastest available operating speed for dsPIC microcontrollers without using an external oscillator. This microcontroller is still very slow compared with 3 GHz Pentium 4 microprocessors and it is not adequate for retrieving real time data without special software techniques. Even though, the main characteristic that the Nerdmobile team was looking for in a microcontroller was speed, other factors were also considered. The following table shows the other reasons why this microcontroller was chosen:

Description $3.68 per unit*


*Nerdmobile team got free samples

Price

Equipment

Harding University has the necessary equipment to program this microcontrollers This microcontroller can programmed in high level language C using compilers such as MikroC and MPLAB C30 Four output compare channels*
*Nerdmobile needed two output compare channels to send Pulse Width Modulation to motor controllers

Programming Language

Output Compare Channels Program Memory

48 Kb*
*Nerdmobile code uses 5 Kb

Table 5: Reasons considered choosing the dsPIC30F4013 microcontroller

Because this microcontroller is very slow for real time acquisition of data, the nerdmobile team was challenged to implement different programming techniques for highly efficient code. One of those techniques was the right bit shift to approximate divisions avoiding
7

dsPIC30F3014/4013 Data Sheet (http://ww1.microchip.com/downloads/en/DeviceDoc/70138E.pdf)

18

floating point calculations. Another technique was the small angle approximation8 to speed up the acquisition of real time data coming from the sensors and process it fast enough in the microcontroller. The Nerdmobile has three sensors that report an analog voltage; thus, the microcontroller needs at least three A/D converters. The dsPIC30F4013 has 13 12-bit A/D converters 1 with a full range scale range of 0 4095 and a 0.00122V/step resolution. 12-bit A/D converters allow a broader range of values to use within software and also permit better resolution than 10-bit A/D converters which are limited to a full scale range of 0 1023 and 0.00457V/steps resolution for 5V reference voltage for logic high. In other words, by using a 10 bit A/D converter for the Nerdmobile, the limits set in code when reading the sensors would not have been as precise as it is by using a 12 bit A/D converter. Thus, the Nerdmobile team looked for the highest available A/D converter resolution and the 12 bit A/D converters in the dsPIC30F4013 offered the highest possible resolution for dsPIC microcontrollers. Programming: In order to program the dsPIC30f4013, a universal programmer from Harding Universitys Engineering Department was used. The ALL-11 universal programmer by HI-LO systems allows the programming of virtually all microprocessors that fit into the 40 pin DIP arrangement. The Compiler that was used was MikroC that allows code for the dsPIC30f4013 to be written in C and after compiling the code it generates a .hex file that is loaded into the microcontroller using the ALL-11 universal programmer. The other compiler that was considered to write the code was the MPLAB C30. However, the MikroC compiler offers many built-in functions that the MPLAB C30 does not such as Adc_Read(channel #), and

http://abrobotics.tripod.com/ControlLaws/small_angle.htm

19

Pwm_Start() that if using MPLAB C30 the manipulation of many registers would have been required. The MPLAB C30 compiler is available at www.microchip.com and the MikroC compiler is available at www.mikroe.com/en/compilers, both of those compilers are free. The Nerdmobile code implements right shift techniques to approximate divisions which take only one clock cycle and avoids floating point calculations that take 17 clock cycles which makes the processing of data faster. Furthermore, the code of the Nerdmobile implements a digital filter and a PID9 control by using the values coming from three sensors: gyroscope, accelerometer, and potentiometer. The PID control in software is what actually balances the Nerdmobile. The following algorithm shows the basics of what the Nerdmobile code does:

Figure 10: Basic algorithm of Nerdmobile code

http://team358.org/files/programming/PIDControlTheory_rev3.pdf

20

Reading analog sensors in code In order to determine the values from the sensors using the A/D converters and get those values in useful units, some adjustments are needed which require offset and scale. Thus, the actual value coming from any sensor is equal to (ADCValue Offset)*Scale. The ADCValue is the value read from the A/D converter with a resolution of 5V / 4096 step or 0.001V/step. The offset is the value that the sensor reads when the Nerdmobile is in the horizontal and stationary position. The Scale is the value by which to multiply to get the desired units (The scale factor for the gyroscope and accelerometer is given in the datasheet. For the potentiometer the Nerdmobile calculated that for each mm that the potentiometer moved, a 0.0301V was read in the microcontroller).
1. GyroscopeValue (/s) = (ADCGyroscopeValue - OffsetGyro)*ScaleGyro.

a. OffsetGyro = 2.26V = 1850 (as read by dsPIC30F4013 at horizontal stationary position) b. ScaleGyro = 0.081 /s/step (5V / 4096steps 15mV/ /s10). 2. AccelerometerXaxisValue () = (ADCAccelValue - OffsetAccel)*ScaleAccel. a. OffsetAccel = 2.53V = 2069 (as read by dsPIC30F4013 at horizontal stationary position) b. ScaleAccel = 0.07 /step ((5V / 4096steps 1000mV/ g11) * 180 / ).
i. (ADCAccelValue - OffsetAccel)(1*g) = (1 g) * sin() in radians.

ii. Using small angle approximation, sin() for /6, and canceling
out the gs ; then, (ADCAccelValue - OffsetAccel) = in radians.

iii. Multiply value by 180 / to get the units in degrees.


10

11

http://www.analog.com/UploadedFiles/Data_Sheets/ADXRS150.pdf http://www.analog.com/UploadedFiles/Data_Sheets/ADXL103_203.pdf

21

3. PotentiometerValue (mm) = (ADCPotenValue - OffsetPoten)*ScalePoten. a. OffsetPoten = 2.46V = 2016 (as read by dsPIC30F4013 at horizontal stationary position) b. ScalePoten = 0.04055 mm/step (5V / 4096steps 0.0301 V/mm) Calculating leaning angle in code Often in control systems for aerodynamics two sources are used to calculate one variable and the noise properties of those two sensors are such that one only works in the low frequency region and the other is good in the high frequency region. In order to calculate the leaning angle of the Nerdmobile two sources were used: a gyroscope and an accelerometer. The following figure shows how both the gyroscope and accelerometer were used to estimate the leaning angle:

Figure 11: Complementary filter to calculate Nerdmobile leaning angle

12

On the one hand, the gyroscope is only good in the low frequency region due to integration as shown in the figure above. Since it calculates /s, the values read by the A/D converter can be integrated over time to get an approximate of the angle. On the other hand, the

http://ocw.mit.edu/NR/rdonlyres/Aeronautics-and-Astronautics/16-333Fall-2004/012B55F1-36F4-48A7-996CA662D64CB885/0/lecture_15.pdf

12

22

accelerometer works well in the high frequency region with a constant speed or zero acceleration. The accelerometer senses the effect of gravity. When the accelerometer is horizontal it senses 0g. When it is tilted it senses g*sin(). However, small angle approximation (sin() for = /6) was used to avoid trigonometric calculations and save processing time. Thus, the accelerometer angle = AccelerometerXaxisValue / 1 g. In code, the Nerdmobile team performed a numeric integration and a small angle approximation to create a complementary filter: angle +=a* GyroscopeValue*dt ; angle += b* AccelerometerXaxisValue

o a = s / (s + 1) and b = 1/ (s + 1) or 1 - a. rs is the time constant percentage for both the high pass filter and low pass filter.
The Nerdmobile team tried different values for rs and found out the following:
s 90 92 97 98 99 Nerdmobile response Too sensitive, it was hard to ride it Still too sensitive and hard to ride it It was easier to ride it and it allowed a bit larger leaning angle Same as s = 97 Very smooth response, really easy to ride it

99.3

Not much sensitive, leaning angle was too big

Table 6: s values tried for Nerdmobile

From the table above, the Nerdmobile team found out that the best value for the time coefficient is 99 which gave the Nerdmobile a smooth performance and response. With s = 99, a = 0.99 and b = 0.01.

o dt = time interval between updates for which a counter in the microcontroller was used.
23

Calculating angular velocity and spinning direction The angular velocity was calculated using the gyroscope as mentioned above. Angular Velocity (/s) = (ADCGyroscopeValue - OffsetGyro)*ScaleGyro. The spinning direction was calculated using the potentiometer. If the potentiometer values read were from 1472 1965, the spinning direction of the Nerdmobile was to the right. If the potentiometer values read were from 1965 2458, the spinning direction of the Nerdmobile was to the left. Calculating motor speed and direction In order to control the Nerdmobile an angle PD (proportional/Derivative) control algorithm was used for which motor output = Kd * (Leaning Angle) + Kp * (Angular Velocity). Thus, four possible scenarios could occur when controlling the speed and direction of the motors. The following table shows those possibilities:
Motors Response Angle Positive Angular Velocity Positive Angle Positive Angular Velocity Negative Angle Negative Angular Velocity Positive Angle Negative Angular Velocity Negative Nerdmobile is leaning forward, motors must accelerate forward to catch up Nerdmobile is heading back toward being horizontal, motors must be slowed in advanced Nerdmobile heading forward toward being horizontal, motors must be slowed in advanced Nerdmobile leaning backward, motors must accelerate backward to catch up

Table 7: 4 possible scenarios for angular velocity and leaning angle

24

The Kd (proportional gain constant) acts like a damper and the Kp (derivative gain constant) acts like a spring for the Nerdmobile. The following figure shows what the Kd and Kp constants do to the Nerdmobile:

Figure 12: The PD control is like adding an adjustable spring and damper to the Nerdmobile

13

The Nerdmobile team found out the following results about the Kp and Kd .
Kp Kd Nerdmobile response Stable, but it was oscillating back and forth too much. The best value for Kp that reduced oscillation was 0.077 Too much pushing force at the wheels. Rider will be most likely to fall down Not enough pushing force at the wheels to accelerate and catch up This were the best values that gave the Nerdmobile a smooth performance and stability

0.02-0.09

0.4

0.077

0.4-0.9

0.077

0.1-0.2

0.077

0.32

Table 8: Nerdmobile response based on Kp and Kd values

13

http://web.mit.edu/first/segway/

25

The following code snippet implements the PD control for the Nerdmobile to control it when leaning forward or backward: motor += (0.077* angle) + (0.4 * GyroscopeValue); rmotor = lmotor = (Neutral Speed) + motor

o Neutral Speed is the PWM value at which Victor 884s send neutral speed to the motors which was 2768.

To make the Nerdmobile spin smoothly, the same idea of a PD control was used. Two constants were used: KS and KSL. KSL was used to reduce the velocity of the motors in case they are going too fast when leaning forward. KS was used to increase/decrease the spinning direction of the wheels depending upon the values read from the potentiometer. The following results were found for KS and KSL for the Nerdmobile:
Ks 3.5-5 Ksl 0.003 0.003 Nerdmobile response Spinning of the wheels was too fast, rider may fall down Best value for a smooth spinning was Ks =3 The bigger the Ksl value was, the faster the wheels spin in opposite directions which made the Nerdmobile unstable This was the best match of values for Ks and Ksl. They gave a smooth spinning performance to the Nerdmobile.

1-3

0.004-0.008

0.003

Table 9: Nerdmobile spinning response for Ks and Ksl values

26

In code, the turn value that will be added to one motor and subtracted to the other was done as follows: turn = (PotentiometerValue*3)*(motor*0.003); lmotor += turn; rmotor += turn;

This will make one motor slower and than the other one if potentiometer is being used for turning. Motor Controllers: The following table summarizes the criteria that the Nerdmobile team used to choose the motor controllers:

MOTOR CONTROLLERS
Max continuous Current Operational Voltage Price Fits Nerdmobile Budget Max controller current / 85A ratio ([Max controller / Stall motor] currents) Fits Nerdmobile Voltage Requirements (12V max) Maximum update speed

H-Bridge Robot Power


20A 12V $79.99 Yes 25.88%

Victor 883
60A 24V $149.95 No 70.59%

Victor 884
40A 12V $114.95 Yes 47.07%

Victor 885
120A 12V/24V $199.95 No 147.06%*
*It can handle more than 85A

Yes 20ms

No 1-2ms

Yes 1-2ms

Yes 1-2ms

Table 10: Characteristics of motor controllers considered for the Nerdmobile

27

The amount of current that the motor controllers needed to handle was up to 85A which is the stall current of the motors. Thus, the best motor controller for the Nerdmobile was one that can handle that much current. Because of the high current draws from the motors, the Nerdmobile team decided to buy motor controllers instead of building their own for safety considerations. H-bridges were the first option because of price, $79.99; however, the best Hbridges that were under $200 can only handle 22A continuously which are the Simple H-bridge from Robot Power. The other options were motor controllers from IFI Robotics: Victor motor controllers which are under $200. The best motor controller that was perfect for the Nerdmobile was the Victor 885 which can handle up to 120A of continuous current. However, a Victor 885 costs $199.95 and the Nerdmobile needed two of them which could not in the Nerdmobile budget. The other option was the Victor 883 which can handle up to 60A of continuous current. Nevertheless, it needed a 24V power supply and the Nerdmobile battery was 12V, and this motor controller was still very expensive $149.95. Thus, the last option was the Victor 884 controller which costs $114.95. Two Victor 884 speed controllers were used to drive the motors of the Nerdmobile. They can handle up to 40A of continuous current which is the closer motor controller capacity to 85A that still fits in the Nerdmobiles budget. This controller safely handles 40A of continuous current draws and high switching speeds of 1-2 ms ensuring the motors receive maximum power. According to IFI robotics, this motor controller provides significant improvements in acceleration, direction changes and lifting torque in contrast to its predecessor the Victor 88314 even though it does not handle as much current as the Victor 883.

14

http://www.ifirobotics.com/victor-884-speed-controller-robots.shtml

28

The following figure shows the layout of the Victor 884 speed controller.

Figure 13: Victor 884 Motor Controller

The PWM wire configuration is W: signal coming from the dsPIC30F4013, R: 5V, B: Ground. The wires coming from the battery and going to the motors must be #6 AWG and the PWM wires going to the microcontroller must be #10AWG. The Victor 884 motor controllers are designed to work with other IFI robotics components. Thus, the Nerdmobile team had to research how the motor controllers work so that they can be integrated with the dsPIC30F4013 microcontroller. In turned out that the Victor 884 controllers need a Pulse Width Modulation period of 17ms or 59Hz frequency. The commands to go forward, backward or stop are set by the duty cycle sent to the motor controllers. The following table shows the duty cycle percentage needed for the motors go backward, forward or reverse.

Duty Cycle

5.88% - 8.83% 1ms-1.5ms logic high out of the 17ms period Full Reverse to Neutral

8.83% 1.5ms logic high out of the 17ms period Neutral

8.83%-11.76% 1.5ms-2ms logic high out of the 17ms period Neutral to Full Forward

Command

Table 11: Duty cycle and command response of Victor 884

29

By using the table above, the Nerdmobile team created an algorithm to make the motors go forward, backward or neutral depending upon the feedback coming from the sensors. In other words, the duty cycle was set dynamically as the values from the sensors changed. The following flowchart shows how to set the microcontroller to control the Victor 884:

Figure 14: Manipulating Victor 884 with dsPIC30F4013 microcontroller

30

Testing

At the time of the midterm report, we had already been able to interface all of the sensors with the microprocessor. Our next step was to interface the motor controllers with the microprocessor and motors. Once this was completed, we attached all of the components to the base and started testing the entire system together. We started by testing the balancing algorithm by placing the Nerdmobile on blocks and manually tilting forward and backward to watch the direction and speed of the wheels spin. Once we saw that the wheels would spin faster the faster we tilted the base in a direction, we decided to attach the tower and set the scooter on the ground. The next milestone that we hit was that our scooter could move forward and backward when pushed in that direction. With more tweaking of the code, we were able to get the Nerdmobile to balance on its own; however, it would oscillate wildly if it was displaced too far from the centered position. After more testing, we decided that this behavior was due to slack in the wheels due to our initial mounting techniques (see Wheels section for more info). Once a rider was on the scooter, the oscillation was no longer noticeable since the rider could keep it under control by holding onto the tower. At only 60% of the full motor power, Pablo was able to ride the scooter forward and backward, as well as get on and off of it without any supports or help. He could also keep the scooter in a stationary position. A video of this can be seen by searching YouTube for the video Pablo rides the Nerdmobile or by following this link: http://www.youtube.com/watch?v=yDgqHv_vyL4 . Shortly after that test; however, our left motor stopped spinning and refused to function. When we took it apart, we saw that the mechanism connecting the outside leads to the inner parts of the motor had somehow broken
31

apart and was beyond repair. Because of this, we were no longer able to continue testing the balancing code. We then decided to test the runtime of the battery by having Pablo stand on it and have the single motor move the scooter back and forth. We had planned to do this for 30 minutes with our motor at maximum power, which would allow us to reach our requirement if our battery was at more than 50% capacity. Unfortunately, 20 minutes into the test the right motor suffered the same fate as the left motor and refused to operate. When we checked the battery capacity on our charger, it showed 80% remaining. We do not have an official, quantifiable test result, but extrapolating this test, we conclude that we reached our operating time requirement. In other words, one motor was running at full speed during 20 min with a 59 kilogram rider (Pablo) and at the end of the test the battery was at 80%. This would translate to riding a 118 kilogram rider for 10min and battery at 80%. Battery going from 100% to 0% would have run the Segway for 50min. As for the top speed requirement of 2 meters per second, the scooter can be seen moving at a rapid pace in the video, and that is only at 60% of the motor power. By watching the video in Youtube, we made some measurements and determine that it travelled around 0.5meters in less than one second even though the motors where only running at 60%. If running at 100%, the Nerdmobile could definitely reach the 2m/s requirement. For the maximum weight requirements, we had one of our classmates (Jon Banta) who weighs more than 113 kg stand on the scooter. The Nerdmobile showed no signs of stress or strain. For the weight of the scooter requirement, we placed it on a scale and found that including the battery and all other components, the Nerdmobile weighed 20 kg, which was much less than our requirement of 39 kg. Finally, with the wheels on, the scooter is still narrow enough to fit through a doorway easily.

32

Budget

33

Budget, contd

Clearly, we came very close to running over our budget with a final expenditure of $697. We had a few last minute costs, such as buying a replacement battery for an old, dead one, and having to buy new wheels. Weve calculated the cost to mass produce at roughly $575. To estimate this, we created orders on the vendors websites for quantities of 100, and then divided the final cost with shipping by 100. The biggest discounts come from reduced shipping prices when buying in bulk, as well as reduced prices for the sensors when purchased in bulk. Another reduced cost in bulk would be the miscellaneous costs such as wiring, screws, bolts, brackets, etc.

34

Schedule
Midterm Schedule:
Oct 2007 Nov 2007 Dec 2007 9/12 16/12 23/12 30/12 6/1 Jan 2008 13/1 20/1 27/1 3/2 Feb 2008 10/2 17/2 24/2 2/3 Mar 2008 9/3 16/3 23/3 30/3 6/4 Apr 2008 13/4 20/4 27/4

ID

Task Name

Start

Finish
30/9 7/10 14/10 21/10 28/10 4/11 11/11 18/11 25/11 2/12

1 2 3 4 5 6 7 8 9

Written System Design 10/1/2007 and Project Plan Formal Design and Project 10/1/2007 Plan presentation Formal Design and 11/30/2007 Analysis presentation Parts selection Microcontroller Programming Motors Gearbox Sensors 10/1/2007 2/4/2008 2/12/2008 1/28/2008 2/4/2008 1/28/2008 2/26/2008 2/4/2008 2/26/2008 3/24/2008 1/28/2008 4/14/2008 4/28/2008 2/4/2008 10/1/2007

10/8/2007 10/4/2007 12/6/2007 12/6/2007 2/22/2008 3/17/2008 3/11/2008 2/29/2008 2/13/2008 3/18/2008 2/22/2008 3/7/2008 4/4/2008 4/11/2008 4/28/2008 5/2/2008 4/18/2008 5/2/2008

10 Steering 11 Motor Controllers 12 Battery and Power Electronics

13 Structure 14 Initial Test 15 Integration / Testing 16 Finalize 17 Documentation 18 Project Managment

Figure 15: Midterm schedule

Final Schedule:

Figure 16: Final Schedule

35

In the final schedule we ended up spending more time on the programming than we have originally planned. Furthermore, the steering was moved a few weeks later because we were trying to improve the balancing when leaning forward and backward. Other than that, we stayed as planned with the schedule getting everything on time.

36

Appendix Nerdmobile code

#include<built_in.h> #define KP 0.077 #define KD 0.4 //If KD is high like 0.5, and KP like 0.077 //the oscillation gets worse //This values work but not enough damper force to cath up //#define KP 0.085 //#define KD 0.15 //#define KP 0.077 //#define KD 0.4 #define Accel_Offset 2069 #define Gyro_Offset 1850 #define Poten_Offset 2016 #define KS 3 #define KSL 0.003 void main() { signed int lmotor = 0, rmotor = 0, turn; //Analog values signed int Adc_Gyro, Adc_Accel, Adc_Poten; //Unit Values signed int Gyro_Vel, Accel_Deg, Poten_Side; //Loop time unsigned short dtmr; //Values output to LCD char GyroValue[7], AccelerometerValue[6]; float angle = 0, motor = 0; const int FullForward = 3690, StartNeutral = 2700, EndNeutral = 2835, FullReverse = 1935; unsigned PeriodRM, PeriodLM; int cnt = 0; /***************TIMER3 Configuration*******************/ //Enable internal clock T3CON = 0x0000; //Enable Timer3

37

T3CONbits.TON = 1; //Timer clock prescalar = 256 T3CONbits.TCKPS = 0b11; /*************ADC configuration*********************/ //All are digital channels, then assign the ones who are noe ADPCFG = 0xFFFF; //Gyroscope TRISBbits.TRISB9 = 1; //Accelerometer TRISBbits.TRISB10 = 1; //Potentiometer TRISBbits.TRISB11 = 1; /*********LCD CONFIGURATION************************/ //Port configuration Lcd8_Custom_Config(&PORTB, 7, 6, 5, 4, 3, 2, 1, 0, &PORTF, 4, 5, 6); //Clear LCD Lcd8_Custom_Cmd(LCD_CLEAR); //Disable cursor Lcd8_Custom_Cmd(LCD_CURSOR_OFF); //The frequency for the Victor 884 has to be 17ms ~ 59Hz PeriodRM = Pwm_Init(59, 1, 1, 2); PeriodLM = Pwm_Init(59, 2, 1, 2); //Channel 1 is for Pwm_Start(1); //Channel 2 is for Pwm_Start(2); Pwm_Set_Duty(2700, Pwm_Set_Duty(2700, while(1) { left motor right motor 1); 2);

dtmr = TMR3; TMR3 = 0x0000; //Read gyroscope analog value from AN9 Adc_Gyro = Adc_Read(9); //Read Accelerometer analog value from AN10 Adc_Accel = Adc_Read(10); //Read Potentiometer analog value from AN11 Adc_Poten = Adc_Read(11);

38

//Scale factor = (5/4096) / (15/1000) = dsPIC Resolution / Scale Factor of Gyro(15mV/deg/sec) Gyro_Vel = (Adc_Gyro - Gyro_Offset) * 5 >> 6; // 5/2e6(0.078) Approx = 0.081 //Multiply this value by 0.01 to get the actual value Accel_Deg = (Adc_Accel - Accel_Offset) * 31 >> 8; //20mm = 0.601 V, 1mm = 0.0301 //Scale Factor = (5/4096) / 0.0301 Poten_Side = (Adc_Poten - Poten_Offset) * 83 >> 11; //0.0001389 = 256 * 0.000000542741(clock perio = 4/7.37Mhz) angle = 0.99 * (angle + (float)Gyro_Vel* (float) dtmr * 0.0001389 ); //angle += 0.01 * ((float)Accel_Deg); angle += 0.01 * ((float)Accel_Deg); //with a = 0.97, and b = 0.03, KP 0.077 and KP 0.4 motor are //very strong but it is over ajusting //with a = 0.93, and b = 0.07, //worse! motor += KP 0.077 and KP 0.4 motors are

(KP * angle) + (KD * (float)Gyro_Vel);

//Build up to go forward //Apply power sonner if(motor <= -812) { motor = -812; } //Build up to go backward else if(motor > 812) { motor = 812; } //2768 This is the middle of StartNeutral rmotor = lmotor = 2768 - (int)motor; if(Poten_Side < 3 && Poten_Side > -3) { Poten_Side = 0; }

and EndNeutral

turn = (int)((float)Poten_Side*KS*(1.0 - motor*KSL)); lmotor += turn; rmotor -= turn;

39

if(rmotor >= FullForward) { rmotor = FullForward; } else if(rmotor <= 1987) { rmotor = 1987; } if(lmotor >= FullForward) { lmotor = FullForward; } else if(lmotor <= 1900) { lmotor = 1900; } if(0 == 1) { rmotor = lmotor = EndNeutral; motor = 0; } Pwm_Set_Duty(rmotor, 1); Pwm_Set_Duty(lmotor, 2); //Clear Watchdog asm{ CLRWDT } }

40

Maxi fuse box

Figure 17: Connecting all the electronics.

The figure above shows how the sensors are connected to the microcontroller. It also shows what pins of the microcontroller are used to send PWM to motor controllers and how a LCD was connected to the microcontroller for debugging purposes.

41

2 3300mF coupling caps in parallel

MController

1N5408 diode to avoid reverse polarity. It can handle 1A


5V regulator Receive values from sensors PWM to victor 884

Figure 18: Design of main circuit board.

The figure above shows the diagram that was used to etch the main circuit board.

42

Figure 19: Motor and Gearbox

43

Вам также может понравиться