Difference between revisions of "F17: Vindicators100"

Revision as of 21:19, 19 December 2017

Grading Criteria

Project Title

Abstract

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

• Sameer Azer
  • Project Lead
  • Sensors
  • Quality Assurance
• Kevin Server
  • Unit Testing Lead
  • Control Unit
• Delwin Lei
  • Sensors
  • Control Unit
• Harmander Sihra
  • Sensors
• Mina Yi
  • DEV/GIT Lead
  • Drive System
• Elizabeth Nguyen
  • Drive System
• Matthew Chew
  • App
  • GPS/Compass
• Mikko Bayabo
  • App
  • GPS/Compass
• Rolando Javier
  • App
  • GPS/Compass

Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Parts List & Cost

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

In this section, we provide details on hardware design for each component - power control systems, drive, sensors, app, and GPS.

Power Management

We used an EV-VN7010AJ Power Management Board to monitor real-time battery voltage. The power board has a pin which outputs a current proportional to the battery voltage. Connecting a load resistor between this pin and ground gives a smaller voltage proportional to the battery voltage. We read this smaller voltage using the ADC pin on the SJOne Board.

From battery voltage, it is split up into two 5V rails, an analog 5V (servos) and a digital 5V (boards, transceivers, LIDAR, US sensors, etc.). We're using two buck converters to step the voltage down from battery voltage. There is also a battery voltage rail which goes to the drive system, which they then PWM to get their desired voltage level.

There is also an LM7805 regulator which is used just to power some of the power management chip's control signals.

Block Diagram for whole power management system.

Drive

The hardware components for drive consists of the motor driver, the servo for steering, and the motor.

Diagram of Drive System

Sensors

We are using two sets of sensors - a lidar and 4 ultrasonic sensors.

Sensors System Hardware Design

Lidar

Our lidar system has two separate hardware components - the lidar and the servo. The lidar is mounted on the servo to provide a "big-picture" view of the car's surroundings. The image below shows the pin connected between the lidar and servo to the SJOne board. The bottom portion in red is our servo and mounted on top is the lidar.

Lidar and Servo Interface with SJOne Board

The lidar was connected to the SJOne board using the i2c2 pins (P0.10 & P0.11). As per the datasheet's instructions, a 680 uF capacitor was added across the Vcc and GND lines. The servo is driven using the PWM1 pin on the SJOne board (P2.0). A level shifter between the servo and the SJOne board was necessary since the SJOne board outputs a 3.3v signal, but the servo works with a 5v signal.

Lidar Mount Base

Ultrasonic Sensors

Ultrasonic Sensor System

App

ESP8266 Interface with SJOne Board

GPS

Compass and GPS Interface with SJOne Board

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Power Management

The EV-VN7010AJ has a very basic control control mechanism. It has an output enable pin, MultiSense enable pin, and MultiSense multiplexer select lines. All of the necessary pins are either permanently tied to +5V, GND, or a GPIO pin on the SJOne Board. The MultiSense pin outputs information about the current battery voltage. The MultiSense pin is simply connected to an ADC pin on the SJOne board.

Drive

Motor Driver & Propulsion Motor

The motor driver is used to control the propulsion motor via OUTA and OUTB. It is driven by the SJOne board using a PWM signal connected to pin P2.0. The PWM frequency is set to 20,000 kHz.

Steering Servo

Our steering servo is driven via a PWM signal as well. The PWM frequency is set to 50 Hz. However, since we are already using a PWM signal for the motor, we used a repetitive interrupt timer (RIT) to manually generate a PWM signal using a GPIO pin for the steering servo. The RIT had to be modified to allow us to count in microseconds (uS) since the original only allows to count in ms. To do this, we added an additional parameter uint32_t time. These time values are using to calculate our compare value which tells us how often to trigger the callback function. Since we wanted our function to trigger every 50 us, we essentially need to calculate how many CPU clock edges we need before the callback is triggered.

For example, we wanted to trigger our callback every 50 us. Thus, our prefix is 1000000 (amount of us in 1 second) and our time is 50 (us). This will give us the number of 50 us in 1 second in terms of us, which is 20000. When we take our system clock (48 MHz) and divide it by the number we just calculated and it gives us the number of CPU cycles we want before the callback is triggered.

// function prototype
void rit_enable(void_func_t function, uint32_t time, uint32_t prefix);
// Enable RIT - function, time, prefix
rit_enable(RIT_PWM, RIT_INCREMENT_US, MICROSECONDS);
// modified calculation 
LPC_RIT->RICOMPVAL = sys_get_cpu_clock() / (prefix / time);

We used pin P1.19 as a GPIO output pin to generate our PWM signal. In our RIT callback, it brings the GPIO pin high or low. The algorithm to generate the signal is as follows:

1. Initialize a static counter to 0
2. Increment by 50 on each callback (we chose 50 us so as not to eat up too much CPU time)
3. Check if counter is greater than or equal to our period (50 Hz)
   1. Assert GPIO pin high
   2. Reset count
4. Check if counter is greater than or equal to our target
   1. Bring GPIO pin low

NOTE Our target has to be in terms of us since all of our calculations are in us. We get the target for our RIT by obtaining a target angle from control. We use a mapping function to generate our target in us from the desired angle. The initial value for the mapping function calculation was done by using a function generator with our steering servo.

• We found the min and max values in terms of ms and converted it to us.
• We then used these min and max values to move the wheels and mark it at each extreme on a sheet of paper.
• Using the marks, we calculated the angle and used the midpoint of the angle as 0°. That means that the minimum is a negative angle value and maximum is a positive angle value.

We were then able to generate a simple mapping function to map angles in degrees to us using: (uint32_t) (((angle - MIN_STEERING_DEGREES) * OUTPUT_RANGE / INPUT_RANGE) + MIN_MICRO_SEC_STEERING);

LCD Screen

Headlights

Our driver for the headlights uses pin P2.5 to generate a PWM signal turn our headlights on or off. We are using the same frequency as our motor driver (20,000 kHz) since we can only have one PWM frequency for all PWM pins on our SJOne board.

Sensors

Ultrasonic Sensor Interface

Lidar and Servo Interface

The lidar communicates via i2c. Typically, when executing a read operation, there is a write and then a read. It writes the device address and provides a repeat start. However, the lidar expects a stop signal and does not respond to a repeat start, as shown in the Lidar Read Timing Diagram.

Lidar Read Timing Diagram

Thus, we utilized a modified version of the i2c driver that does two completely separate write and read operations. This provides the proper format expected by the lidar.

The lidar driver is as follows:

• Begin with initialization

lidar_i2c2 = &I2C2::getInstance();
lidar_i2c2->writeReg((DEVICE_ADDR << 1), ACQ_COMMAND, 0x00);
lidar_servo = new PWM(PWM::pwm1, SERVO_FREQUENCY);

Initialize lidar to default configuration

    // set configuration to default for balanced performance
    lidar_i2c2->writeReg((DEVICE_ADDR << 1), 0x02, 0x80);
    lidar_i2c2->writeReg((DEVICE_ADDR << 1), 0x04, 0x08);
    lidar_i2c2->writeReg((DEVICE_ADDR << 1), 0x1c, 0x00);

• Write to reg via i2c 0x04 to 0x00 to indicate a measurement is to be taken
• Check the status register 0x01 until the least significant bit is set
• Send the register value 0x8f where the measurement is stored
• Read the value sent back from the lidar and store it in an array
• Shift the contents of index 0 to the left 1 byte and or it with the contents of the array in index 1

return (bytes[0] << 8) | bytes[1];

The driver for the servo simply uses the PWM functions from the library provided to us to initialize the PWM signal to our desired frequency. In our case, we used a 50Hz signal. We also used the set(dutyCycle) function to set the PWM pin to output the desired pattern based on the duty cycles.

GPS

The GPS (uBlox NEO M8N) uses UART to send GPS information. We've disabled all messages except for $GNGLL, which gives us the current coordinates of our car. The GPS then sends parse-able lines of text over its TX pin that contains the latitude, longitude, and UTC. The SJOne board receives this text via RXD2 (Uart2).

The GPS can be configured by sending configuration values over its RX pin. To do this, we send configurations over the SJOne's TXD2 pin and save the configuration by sending a save command to the GPS.

Compass

We made a compass using the LSM303 Magnetometer. To do this, we first had to configure the mode register to allow for continuous reads. We also had to set the gain by modifying the second configuration register. The compass can then be polled at 10Hz to read the X, Y, and Z registers, which are comprised of 6 1-byte wide registers. From this, we can calculate the heading by atan2(Y,X). We chose to completely neglect the Z axis as we found that it made very little difference for our project.

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

CAN Communication

243.dbc

VERSION ""

NS_ :
    BA_
    BA_DEF_
    BA_DEF_DEF_
    BA_DEF_DEF_REL_
    BA_DEF_REL_
    BA_DEF_SGTYPE_
    BA_REL_
    BA_SGTYPE_
    BO_TX_BU_
    BU_BO_REL_
    BU_EV_REL_
    BU_SG_REL_
    CAT_
    CAT_DEF_
    CM_
    ENVVAR_DATA_
    EV_DATA_
    FILTER
    NS_DESC_
    SGTYPE_
    SGTYPE_VAL_
    SG_MUL_VAL_
    SIGTYPE_VALTYPE_
    SIG_GROUP_
    SIG_TYPE_REF_
    SIG_VALTYPE_
    VAL_
    VAL_TABLE_

BS_:

BU_: DBG SENSORS CONTROL_UNIT DRIVE APP NAV

BO_ 100 COMMAND: 1 DBG
 SG_ ENABLE : 0|1@1+ (1,0) [0|1] "" DBG

BO_ 200 FRONT_SENSORS: 2 SENSORS
 SG_ ULTRASONIC_SENSOR : 0|12@1+ (1,0) [0|0] "mm" CONTROL_UNIT

BO_ 123 DRIVE_CMD: 3 CONTROL_UNIT
 SG_ steer_angle : 0|12@1- (0.1,0) [-45|45] "degrees" DRIVE
 SG_ speed : 12|6@1+ (0.1,0) [0|5] "mph" DRIVE
 SG_ direction : 18|1@1+ (1,0) [0|1] "" DRIVE
 SG_ headlights : 19|1@1+ (1,0) [0|1] "" DRIVE

BO_ 122 SENSOR_CMD: 2 CONTROL_UNIT
 SG_ lidar_zero : 0|16@1+ (0.1,0) [0|360] "degrees" SENSORS

BO_ 121 GPS_POS: 8 NAV
 SG_ ns_axis : 0|1@1+ (1,0) [0|1] "" APP
 SG_ latitude : 1|31@1+ (0.01,0) [0|90] "degrees" APP
 SG_ we_axis : 32|1@1+ (1,0) [0|1] "" APP
 SG_ longitude : 33|31@1+ (0.01,0) [0|180] "degrees" APP

BO_ 146 GPS_HEADING: 3 NAV
 SG_ current : 0|9@1+ (1,0) [0|359] "degrees" APP,CONTROL_UNIT
 SG_ projected : 10|9@1+ (1,0) [0|359] "degrees" APP,CONTROL_UNIT

BO_ 124 DRIVE_FEEDBACK: 1 DRIVE
 SG_ velocity : 0|6@1+ (0.1,0) [0|0] "mph" CONTROL_UNIT
 SG_ direction : 6|1@1+ (1,0) [0|1] "" CONTROL_UNIT

BO_ 243 APP_WAYPOINT: 8 APP
 SG_ ns_axis : 0|1@1+ (1,0) [0|1] "" CONTROL_UNIT
 SG_ latitude : 1|31@1+ (0.01,0) [0|90] "degrees" CONTROL_UNIT
 SG_ we_axis : 32|1@1+ (1,0) [0|1] "" CONTROL_UNIT
 SG_ longitude : 33|31@1+ (0.01,0) [0|180] "degrees" CONTROL_UNIT

CM_ BU_ DBG "Debugging entity";
CM_ BU_ DRIVE "Drive System";
CM_ BU_ SENSORS "Sensor Suite";
CM_ BU_ APP "Communication to mobile app";
CM_ BU_ CONTROL_UNIT "Central command board";
CM_ BU_ NAV "GPS and compass";

BA_DEF_ "BusType" STRING ;
BA_DEF_ BO_ "GenMsgCycleTime" INT 0 0;
BA_DEF_ SG_ "FieldType" STRING ;

BA_DEF_DEF_ "BusType" "CAN";
BA_DEF_DEF_ "FieldType" "";
BA_DEF_DEF_ "GenMsgCycleTime" 0;

BA_ "GenMsgCycleTime" BO_ 256 10;
BA_ "GenMsgCycleTime" BO_ 512 10;
BA_ "GenMsgCycleTime" BO_ 768 500;
BA_ "GenMsgCycleTime" BO_ 1024 100;
BA_ "GenMsgCycleTime" BO_ 1280 1000;

Power Management

The MultiSense pin on the EV-VN7010AJ board outputs real time voltage information. It's connected to an ADC pin on the SJOne Board.The ADC reading is converted in software from a 0-4095 range to the actual voltage.

Drive

The drive software is separated into 2 main sections: drive methods and LCD library.

The drive methods handles all functions, classes, and defines necessary to drive.

Ultrasonic Sensors

Lidar

Our Lidar class contains a reference to the instance of the PWM class (for the servo) and to the I2C2 class (for communication with the lidar). It also contains an array with 9 elements to hold each of the measurements obtained during the 90° sweep.

During development, we found that the lidar takes measurements far faster than the servo can turn. Thus, we had to add a delay long enough for the servo to position itself before obtaining readings. To accomplish this, we created a separate task for the lidar itself called LidarTask so as not overrun the periodic tasks. This is because we have the ultrasonic sensors and battery information running in the task that would have been most suitable for the lidar. The delay value was obtained from the servo's datasheet that indicated how many degrees it can turn in a specific amount of time.

Lidar Position Diagram

The basic process for the lidar is that it sweeps across a 90° angle right in front of it, as shown in the Lidar Position Diagram. We have a set list of 9 duty cycles for each position we wish to obtain values for. The duty cycles were obtained by calculating the time in ms needed to move 10°. This is covered in further detail in the Implementation section. The basic algorithm is as follows:

1. Iterate through the list of positions in ascending order
   1. Set position of servo
   2. Wait long enough for servo to position itself
   3. Take measurement and store it
2. When ascending order is complete, give the semaphore to send lidar data via CAN
3. Set increment flag to false
4. Iterate through the list of positions in descending order
   1. Set position of servo
   2. Wait long enough for servo to position itself
   3. Take measurement and store it
5. When descending order is complete, give the semaphore to send lidar data via CAN
6. Set increment to true

Control Unit

The control unit does the majority of its work in the 10Hz periodic task. The 1Hz task is used to check for CAN bus off and to toggle the control unit's heartbeat LED. The 100Hz task is used exclusively for decoding incoming CAN messages and MIA handling.

The 10Hz and 100Hz tasks employ a state machine which are both controlled by the STOP and GO messages from APP. If APP sends a GO signal, the state machine will switch to the "GO" state. If APP sends a STOP signal, the state machine will switch to the "STOP_STATE" state. While in the "STOP_STATE" state, the program will simply wait for a GO signal from app. While in the "GO" state, the 10Hz task will perform the path finding, object avoidance, speed, and headlight logic and the 100Hz task will begin decoding incoming CAN messages.

Path Finding

For path finding, NAV sends CONTROL_UNIT two headings: projected and current. Projected heading is the heading the car needs to be facing in order to be pointed directly at the next waypoint. Current heading the direction the car is pointing at that moment. These two values are used to determine which direction and of what severity to turn.

Object Avoidance

Object avoidance is broken into multiple steps:

1. Simplify ultrasonic readings to whether the sensor is "blocked" or not.
2. Simplify lidar readings to whether the reading is "blocked", "getting close", or "safe".
3. Determine what direction to turn based solely on lidar.
4. Determine what direction to turn based solely on ultrasonics.
5. Determine final steering angle based on path finding and lidar and ultrasonic direction calculations.

Speed

Because the maximum speed of our car is about 2mph, speed modulation is relatively simple and can be simplified into stop, slow, and full speed. When lidar detects something is "getting close", the speed will be "slow". The speed will also be set to slow when the car is performing a turn or reversing. If all ultrasonic sensors are blocked (including the rear sensor), the car will stop.

Headlights

If the light value received from SENSORS is below XXXXXXXXX then CONTROL will send a signal to drive to turn on the headlights.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

PCB Final Design

-- write about integration of entire car here --

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

Technical Challenges

Single frequency setting for PWM

Using PWM on the SJOne board only allows you to run all PWM pins at the same frequency. For drive, we required two different frequencies - one for the motor and one for the servo. We solved this issue by generating our own PWM signal using a GPIO pin and a RIT (repetitive interrupt timer).

Inaccurate PWM Frequency

When originally working with PWM for drive, we found that the actual frequency that was set was inaccurate. We expected the frequency to be 20kHz, but when we hooked it up to the oscilloscope we found that it was much higher. It was consistently setting the frequency to output about 10 times the expected value. We came to the realization that since we had been declaring the PWM class as a global, the initialization was not being done properly. We are not sure why this is the case, but after we instantiated the PWM class in the periodic init function, the frequency was correct.

Difficulties with Quadrature Counter

We had issues getting the quadrature counter to give us valid numbers. Our solution was to use LPC's built-in counter instead of having an extra external component.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

• Vindicators100 GIT LAB

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.