Antenna Matching

Written by Zachary de Bruyn (Electronics & Control)

Purpose

The PeteBot chassis team is unique in that it is utilizing two PCBs which operate on two different MCUs; the first being the heritage 3DoT v5.03 board which uses the ATMega32U4, and the second being the SAMB11, which incorporates the ATSAMB11. One significant different between the two boards is that the SAMB11 has a transceiver module. Because the SAMB11 can operate with the incorporated Bluetooth (BLE), an antenna network was needed to be designed to utilize the BLE transceiver. Because an antenna network was needed to be constructed with minimal input from the SAMB11 reference design, many steps were required to be performed in order to ensure that the SAMB11 could operate at the 2.4-GHz BLE frequency.

Antenna Selection

The first step in the overal process of incorporated a matching network is selecting a proper antenna based on the needs of the system. To reiterate, the operating frequency of BLE is 2.4-GHz. Along with frequency requirements, there are also size requirements. Our antenna therefore was required to operate at the BLE frequency, to be small enough to fit on a PCB, and to operate the PeteBot chassis. These requirements alone narrowed the possibilites of two types of antennas: PCB or chip antennas. With the PCB antennas, one antenna that looks promising is the meandered inverted-F antenna (MIFA). The chip antenna resembles a 0805 resistor or inductor. The two antennas are shown below:

Figure One – MIFA (Source: Cypress)

Figure Two – Chip Antenna (Source: Cypress)

Analyzing both types and data sheets of antennas, we discover that both antennas have an isotropic radiation pattern, meaning that the frequency of the antenna can be picked up equally from almost every direction. This is ideal for our applications due to the fact that the PeteBot will be required to operate via RC mode by an operated. A few other important antenna parameters are: return loss, gain, and bandwidth. Return loss is essentially how much of the power being transmitted is reflected due to the mismatch of the antenna’s imepdances. The standard for impedances is usually 50-Ohms. A return loss greater or equal to 10-dB is considered ideal for operation [1]. Referring to the following equaltion for return loss:

Equation (1)

At a return loss of 10-dB which translates to 90% of power transmittered going into the antenna, return loss of 20-dB translates to 99%. The gain is a measure of ow strong the radiation field is compared to the ideal omnidirectional antenna. For isotropic antennas, like that being applied to the PeteBot, gain is measured as dBi. The “i” simply indicates that the gain is measured frerence to an istropic antenna. While the MIFA antenna has a gain of about 5-dB depending on the plane of radation, the chip antenna has a peak gain of 0.5-dBi. The bandwidth requirements for the antennas requires that the BLE frequency is capable of interception, which was 2.4-GHz. The chip antenna has a frequency range of 2.4- to 2.5-GHz, which translates to a bandwidth of 100-MHz. The MIFA antenna operates a a comparable frequency range, and therefore has an equivalent bandwidth.

With comparable operational characteristics, an antenna selection for our purposes was based upon flexibility, in which the antenna can be used in a variety of configurations for the SAMB11 board. In the case of the PeteBot SAMB11 PCB, the chip antenna is the best candidate.

Matching Network

The purpose of an antenna matching network is to allow the most power to be delivered to the load. The load in the case of transcievers, like the SAMB11, is dependent on whether the antenna is transmitting or receiving. If the antenna is transmitting, then the antenna is the load, whicl the SoC SAMB11 is the load if the system is receiving. It is common practice to design a load with 50-Ohm impedences for RF traces [1]. As a review, the term impedance is mathematically defined as the magnitude of resistance and reactance. It is typically denoted by the letter “Z.”

Equation (2)

Equation (3)

In Equations (2) and (3), R denotes resistance, and X for reactance. Both values are measured in Ohms.

Now that impedance is defined and the typical characteristic impedance is defined as 50-Ohms, this information can be used in collaboration with the helpful tool called a Smith Chart.

Smith Chart

It is a graphicaly tool used to help plot complex impedances and used to define a matching network. It is also helpful in determining many important RF parameters, including VSWR, return loss, reflection coefficient, and transmission coefficients. Using this chart can design a matching network.

Figure Three – Smith Chart (Courtesy of Wikipedia)

There are a lot of reference towards using Smith charts on YouTube that will explain how to find the difference parameters.

The best usage of the Smith chart is to be able to measure the input impedances going into a load, where the input impedance is defined as Z_in. Character impedance is Z_0 and the load impedance is Z_L.

As an example, let’s say that the measured Z_in was 100-j100-Ohms. The first step would be to normalize the input impedance by dividing Z_in by Z_0, which would result in 2-j2-Ohms. This opint can be located on the Smith chart, and from this point (2-j2), you can use a combination of inductors and capacitors to move the impedance to the necessary location on the Smith chart, which is the center of the chart where the red dot is in Figure 3. The table below helps better understand how each component affects the impedance of the matching network.

Table One

Using any combination of passive elements can be used to get measured impedance as close as possible to the center of the Smith chart for optimal performance. If we refer to the matching newtorks in Figure 4 and Figure 5, we can see that the matching network consists of the passive elements described in Table One.

Figure Four – Chip Matching Network Antenna Reference Design

Figure Five – SAMB11 Matching Network Reference Design

Figure Five depicts the matching network reference design for the SAMB11 where the resistance network shown in the dotted square is omitted from the final design PCB. Also omitted was the capacitor laveld DNI (Do Not Include).

References

[1] Reference One

[2] Reference Two

[3] Reference Three

[4] Reference Four

Acknowledgements

Thank you for Dr. Densmore, Dr. Rezvani, and Dr. Haggerty for help in contributing to understanding the matching network.

Gear Studies

Written by Railan Oviedo (Manufacturing)

Objective

For the Pete-Bot’s (P-Bot) method of movement, our project has implemented a
planetary gear system that incorporates the incline gear as the wheel and 3 planetary gears. The top planetary gear will be the driving gear that is connected to the GM6 motor, while the other two planetary gears will have ball bearings inserted into them—effectively making their presence their solely for the purpose of properly spacing the incline gear. In order to ensure the whole structure stays together, washers will be placed to prevent them from touching the chassis, and a triangular gear holder will be utilized to prevent the system from popping off the chassis.

Preliminary

For a planetary gear system to work, specific parameters must be made in order to ensure the gears can smoothly spin together. The equations to ensure this are as follows:

Equations (1) to (3) to determine the number of teeth for the gears and pitch diameter

“N” represents the number of teeth for the incline gear ring, the planetary gears, and the sun gear. As stated in the introduction, the sun gear will not actually be implemented, but it is still necessary for designing purposes. The variable “r” is for the ratio of revolutions between the sun gear and the incline gear.

The Pitch Diameter “PD” is the effective diameter of the gears, and it is determined by multiplying the number of teeth by the gear module “M.” The modules must be the same for all the gears in the system in order for them to operate smoothly.

Test 1

The initial “r” value chosen for the system was 3, so the sun gear would spin 3 times for every spin of the incline gear. The modules have been set to 1, so the number of teeth also determines the pitch diameter in millimeters. For the first trial, the incline gear was chosen to have 40 teeth – thus resulting in a 40 mm pitch diameter – with an outer diameter of 45 mm. From the equations, the other parameters were found as the following:

Equations (4) & (5) that show the number of teeth calculated

With this, SolidWorks was used in order to generate a simulation for the gears.

Image One – Initial Gear System

Because of the ball bearings, the lower planetary gears will have an increased inner diamater of 1/4 of an inch. This system was laser cut in order to rapid prototype with the P-Bot chassis.

[Video Link will be inserted soon]

Image Two – Initial Wooden Gears

Gear Holder

The gear holder was made to fit the shape of the first gear system. The design is shown in the picture below:

Image Three – Gear Holder

The measurement numbers are given in centimeters. The 4 cm diameter circle represents the pitch diameter of the incline gear, and the 5 cm diameter circle reqpresents the total diameter of the wheel including the tire treads.

Test 2

After testing how the ring actually functions on the chassis, it was seen that the planetary gears for the ball bearings are incredibly flimsy. Furthermore, the wheel is not large enough to surpass the bottom of the chasis, as shown in the picture below:

[Image Four will be inserted soon]

Due to this, a new system that utilizes a 42-teeth incline gear with “r” equal to 4 was used in order to increase the diameter of the wheel. From the equations, the other gears’ teeth were found as:

Equations (6) & (7) show the new number of teeth determined for the new gear system

Since the planetary gears will now have a wider pitch diameter, this should eliminate the issue of their stability for the ball bearings. Using this, another SolidWorks model was made, and these were also laser cut for rapid prototyping.

Image Five – Second Gear System

Image Six – Second Set of Wooden Gears

ModWheels 3DoT v 5.03 Integration and Test

By: Lucas Gutierrez (Project Manager)

 

Introduction

To fulfill the customer’s request, ModWheels will incorporate the 3DoT as its choice for a micro-controller.  As of 11/15/2017, the most recent EE 400D class, the 3DoT v 5.03 was available for in-class testing.  When the 3DoT v 5.03 becomes available for long term usage, a more thorough blog post will cover its the testing and integration with respect to the ModWheels project.

ModWheels Custom Command and Telemetry

By: Lucas Gutierrez (Project Manager)

 

Introduction

An important aspect in fulfilling ModWheel’s mission requirements is integration with the Arxterra platform, both with the phone application and web based application.  To tailor and customize the user experience of the Arxterra applications to the ModWheels project, a few custom commands and telemetry will be incorporated

Custom Commands

  • A slider for servo control when in RC mode.
  • A room selector when in RC mode (to be used in conjunction with EE 400D’s maze).

Telemetry

  • Battery level indicator.
  • Robot orientation (when using web based application).
  • Direction (when using web based application).
  • Current room (when using web based application).

PeteBot Requirements

(Written by Elizabeth Nguyen (Project Manager) & Melwin Pakpahan (Missions, Systems, & Test)

Objective

The requirements for the PeteBot (3DoT Chassis) are defined at two levels and provide the team with direction and to determine what shall be accomplished. Verification and validation are also outlined.

Current Status:

At this time, not all requirements have been confirmed and are pending approval. Some of the requirements listed below are different from the requirements listed in the PDD.

Level One Requirements

Program Requirements

  1. PeteBot shall be completed by Wednesday, December 13, 2017.
    1. This requirement coincides with the last day of class.
    2. This is the projected demonstration date for all toy robots.
  2. PeteBot shall cost no more than $200 as projected by the customer.
  3. PeteBot will be a toy robot.
    1. This requirement is defined through the customer expectations.

Project Requirements

  1. PeteBot shall use the PBX11 which is an alternative microcontroller to the 3DoT Board that utilizes the SAMB11 chip instead of the ATMega32U4 chip.
    1. In case the PBX11 board is inoperable, the 3DoT Board shall be used in its place.
  2. PeteBot shall navigate through a maze with remote control through the ArxRobot App or the Arxterra Control (based on Project and Mission Objectives).
  3. PeteBot shall be no larger than 4 x 3.5 x 3 inches.
    1. These measurements were taken at the widest dimensions of the chassis since it tapers at the bottom.
  4. PeteBot shall be able to memorize a path through the maze that is taught by the user (based on Project and Mission Objectives).
  5. PeteBot shall be able to autonomously travel down the path that was memorized (based on Project and Mission Objectives).
  6. PeteBot should be able to navigate the maze and avoid collisions when multiple robots are in the maze.
    1. The Rules of the Maze for the avoidance algorithm have been defined.
    2. Line following will be implemented if the motoer encoders are funtional.
  7. PeteBot shall have a chassis that is 3D printed.
    1. This is derived from a customer expectation.
  8. The total 3D print time of PeteBot’s chassis shall not exceed 2 hours (based on Project and Mission Objectives).
  9. The main body (chassis) of PeteBot shall be of one solid piece.
  10. PeteBot shall be assembled per the guidelines of Disassembly and Reassembly.
  11. The PeteBot Paper Shell shall resemble the CSULB mascot, Prospector Pete.
    1. This is a customer expectation.
  12. The PeteBot shall be able to perform all functions as programmed by the Arxterra app.
    1. This includes custom commands.

Level Two Requirements

System Requirements

  1. PeteBot shall operate for no less than 20 minutes using a fully charged battery.
  2. PeteBot shall attain an operating speed no slower than 3 centimeters per second.
    1. This speed is referenced from Mission Duration.
  3. PeteBot shall utilize the Generic Color Sensor Shield for line-following.
  4. The PBX11 board shall fulfill the requirement to be a custom PCB.

Subsystem Requirements

  1. PeteBot shall be powered by a RCR123A Lithium Polymer battery.
  2. PeteBot shall use a planetary gear system.
  3. The Generic Color Sensor Shield shall be located at the front of the PeteBot.
  4. PeteBot shall have a castor wheel under the Generic Color Sensor Shield to support the mobile phone.
  5. PeteBot shall utilize two GM6 brushed DC motors with an extended D-shaped shaft.
  6. PeteBot shall utilize two shaft encoders for line following.

Generic Color Sensor Requirements

Written by Charles Banuelos (Manufacturing and Design;Division Manager)

& Muhannad Al Mohamed (Electronic & Control Division Manager)

Worked on by Charles Banuelos (Manufacturing and Design;Division Manager) & Muhannad Al Mohamed (Electronic & Control Division Manager)

 

 

The Color Sensor Shield shall provide measurements from two color sensors with different I2C addresses.

The Color Sensor Shield shall be compatible with any Fall 2017 400D robot. (Specifically to avoid the caster wheel of PBot )

The Color Sensor Shield will use a generic 90 degree pin header to interface with the microcontroller.

The Color Sensor Shield shall use parts of 0603 (imperial) package size or larger.

The Color Sensor Shield will be compatible with any version 5.03 3Dot board.

The Color Sensor Shield will be 55 mm in length.

The distance from the outer edge of a color sensor IC to the other outer edge of the second IC will be 40.249 mm.

The White LEDs will be 2.76 mm away from each color sensor IC edge to edge.

The Color Sensor Shield will be 10.85 mm in width.

Generic Color Sensor Board Dimensions

 

 

Arxterra 3DoT Training Telerobotic Mode

Written by Nornubari Kanabolo MST DM and Muhannad Al Mohamed E&C DM

Arxterra Client-Server “Community” Mode

Training for telerobotic mode included understanding how “Community Mode”works. This can seen by the diagram below

Community mode is communication between several parts of the Arxterra environment. This includes between the ArxRobot mobile app and Arxterra Control panel through a server and between the ArxRobot mobile app and ATmega32U4 microcontroller.

Choosing Community Mode

1. Click on Community Mode in the ArxRobot App. This is

2. Do not change any of these default settings

Creating Name for Project

In order to create a name for the project, type in your robot name as seen below. For example, for the Goliath project, you would put “Goliath” in the “Robot name” area. For “Pilot name or names” you would put your individual birth name such as “Nornu”.

Access the Arxterra Desktop Control Panel

To access the Arxterra Control Panel, go to arxterra.com and click on “Launch Now!” in the control icon.

Now you log in to the control panel using your Arxterra username(assuming you already registered for an account) and password for Arxterra.

Communication with your Project

Once in community mode and logged into the control panel you should be able to see your robot on the map. It is signified as a colored location marker. Click this and it will show the name of the robot and a “beam me up, Scottie!” icon. Click this icon to switch to Pilot mode.

 → 

Now you should be able to see what your phone camera sees. The interface created through the ArxRobot mobile app should be visible now as can be see below. To change the view of the camera through the app go to the settings>>phone configuration>>camera for streaming video.

Custom Commands and Telemetry

The process of creating Custom Commands & Telemetry in Community Mode is exactly similar to the process in creating them in RC Mode. It has the same 7 options the users can choose from (Boolean, Select, Byte, Unsigned Byte, Short, Unsigned Short, Header/Separator). However, Instead of only enabling the commands to show up in RC Mode the user would enable it to show on the Client Server Mode.

User Interface on the Control Panel

The user interface has 7 windows to show data:

  1. Lounge: shows the position of the project on a map
  2. Live Cast: If camera is enabled, it will show live broadcast from the phone that has the ArxRobot App.
  3. Telemetry: This window shows whatever commands were set for telemetry. Gauges and values of data packets would be shown in this window.
  4. Custom Controls: similar to the RC mode, this window shows the custom commands made by the user to interact with 3DoT Board.
  5. Controls: Also similar to the RC Mode, this window shows the D-pad that can be used to move motors of projects.
  6. Orientation: this window would show the position of the robot if the motion were enabled in the ArxRobot App.
  7. Messages: This window would show any emergency messages and notifications enabled by the user through custom commands. For example the user can have an alert message be sent and shown on this window if a Servomotor went to a specific position.

Telemetry

Telemetry is an automated communications process by which measurements and other data are collected at remote or inaccessible points and transmitted to receiving equipment for monitoring data.

The data packets sent from the 3DoT to the ArxRobot App can be displayed in the telemetry window by enabeling either Telemetry State or Telemetry Stream for custom Commands.

Predefined telemetry can also be shown in the window if enable in the Robot Capabilities Configuration.

ModWheels Power Budget

By: Andrew Yi (Mission, Systems, & Test Engineer)
Approved By: Lucas Gutierrez (Project Manager)

Introduction

The 3DoT Board is comprised of key components that each draw current from the battery.  The boost receives input from the battery directly, and in turn provides power to the LDO. The power report has been updated per the Division Manager and modified to each individual project.
2 Color sensors and 2 shaft encoders are being used on our toy robot and the totals have been placed in the spreadsheet.  The motors and the servo will be pulling most of the current from our system, but levels tested pose no issue to the overall power of the system.
The margins for the LDO, Boost, and battery allow for a large margin for additional components.  Power Budget 4.png shows the estimated battery run time of our toy robot.  With current components, the ModWheels robot has the power capabilities to accomplish the mission.

Calibration Of The Laser Cutter

Written By: Lucas Gutierrez (Project Manager; ModWheels)

Worked On By: Charles Banuelos (Design & Manufacturing; Division Manager) & Lucas Gutierrez (Project Manager; ModWheels)

 

Calibration Method

After an initial configuration of the system, on Friday (11/03/2017) at 1 pm, a calibration of the laser cutter was completed.

This calibration consisted of aligning each of the three mirrors to match the guide red guide laser to the power laser (used for cutting), and to confirm that the focal length depth was at the correct setting.

The calibration was done by placing thermal paper onto the first mirror, firing a test burn, then confirming or realigning the red guide laser to the burn spot. This process was repeated for the extremes of the placement of the laser on the relative axis. This was performed on each mirror and was confirmed by a test cut.

Configuring Laser Cutter for Power Up

Written By: Lucas Gutierrez (Project Manager; ModWheels)

Worked On By: Charles Banuelos (Design & Manufacturing; Division Manager) & Lucas Gutierrez (Project Manager; ModWheels)

 

Introduction

After an verification of components, on Friday (11/03/2017) at 10 am, an initial configuration of the subsystems and the laser cutter was done.

Configuring Subsystems

Air Filter

After materials verification, we connected the power to the laser’s dedicated power source for the air filter. Later, the ducting for the air filter was installed on the air filter itself and the laser cutter’s exhaust port.

Air Pump

After materials verification, we connected the power to the laser’s dedicated power source for the air pump. Later, the air hose for the air pump was installed on the air pump itself and the laser cutter’s air pump intake. After testing, it was confirmed that there will be no need for noise dampening during the laser cutter’s operation.

Water Cooler

After materials verification, we connected the power to and external surge protector, which also provides power for the laser cutter itself. After a rinse of the internal water storage tank, the internal water storage was filled up with distilled water.  To insure no contaminant were introduced to the laser cutter, a closed loop filtering was performed on the water cooler.

Later, the water hose for the water cooler was installed on the water cooler itself and the laser cutter’s water cooler intake and outtake, with the use of additional clamps.

Configuring the Laser Cutter

After initial subsystem configuration, the laser cutter was powered on to verify that all subsystems were function properly.