Pathfinder Generation #5 – Page 2

Auxiliary Panel Trade-Off Study

May 2, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Adolfo Jimenez (Manufacturing)

Verified By: Jordan Smallwood (PM)

Table of Contents

Introduction

Figure 1: Top View of Solar Panel Structure

One of the requirements for the pathfinder project is that the robot should be able to enter and exit a cocoon state via user input in the Arxterra app. This feature is reminiscent of the original Pathfinder Mars Rover which upon contact of the Martian surface, would emerge from its space pod and out of its cocoon state. The benefit this brings to our robot is that it will allow the storage of the rover in a relatively small space such as a cabinet. Currently, the front panels utilize a worm gear attached to stepper motor to articulate the butt and front panels. The Auxiliary back panels however, are attached to the front panels via a hinge and need to be manually opened and closed. Ideally, this process of entering and exiting the cocoon state would be completely autonomous. The following discusses several possible designs that could be implemented to expand/contract the back panels.

Worm Gear:

Figure 2: Illustration of Worm Gear Mechanism

As mentioned before, the side panels work by using a worm gear attached to a stepper motor. The worm gear rotates a spur gear fixed to a rod within the hinge that pivots the side panels around the base panel. This system, we decided, would be too bulky to be implement onto the back panels. Stepper motors work for the movement of the main panels as the motors are fixed to the base panel however, this would add weight to the front panels and thus more strain on our current stepper motors.

Sliding mechanism:

Figure 3: Illustration of Sliding Mechanism

One of our earlier designs involved a sliding mechanism using a rack and pinion gear assembly. This mechanism would have utilized a geared shaft along with a motor to spin and sit under one of the main wings. The system would extend and retract the panels similar to a CD-ROM drive found in a computer. The issue with this design was the amount of space this assembly would have added to the wings.

Linear actuator:

A continuation of the previous design was the use of a linear servo or actuator to push and pull the back panels. The servo/actuator would have been placed underneath the front panels and the rear panels would rest and slide on linear ball bearing side mounts like those found on the sides of cabinets drawers. The issue with this design is the cost, linear servos and actuators are unfortunately quite expensive.

Hinge servo:

Perhaps the simplest and most practical of our ideas was the use of a high torque servo to move a hinge as shown in the video below. The issue with this design is that the back panels would not sit perfectly flush with the front panels. A fix to this might be including a spring to the servo arm to allow the panel to fall by the force of gravity and to pull when needed to be opened.

Pulley and winch design:

Our most exciting design, and perhaps the one with the most “cool factor”, included the use of a winch and pulley system. To achieve the closing of the panels, a constantly closing hinge would have created a closing force that would want to maintain the panel in a shut position. To open the panels, a steel cable running through a series of pullies would be pulled and wrapped around a reel fixed to a motor shaft that would create a pulling force and pry open the panels. The motor would then slowly release tension to re-close the panels. During prototyping of this design, it was discovered that not much actual cable was displaced when pulled to warrant the use of a reel, therefore, a servo and arm attachment could be used to pull and hold the small amount of cable needed to open the panels. It was also discovered that in order to pull the panels open, the force pulling on the rear panel needed to be at an angle. This I because pulling parallel to the panel required a lot more force when compared to pulling at a slight angle. To fix this issue, two pulleys that would lift the cable at slightly an angle would be used on both panels to reduce the force needed to pull back the panel.

Figure 4: Pulley Design

Figure 5: Pulley Design Continued

Spring Hinge:

Figure 6: Spring Hinge Concept

The most rudimentary and cost effective of all our ideas was the use of a spring hinge to open the panels. Similar to the actual Mars rovers, the spring hinge would provide us with the one-time motion of opening the panels. These hinges would be like the hinges used in the previously mentioned pulley design however, these hinges would exert a force in the opposite direction. In order to maintain the panels closed some sort of latch mechanism needed to be included. Two magnets located on the ends of the panels could be used to maintain the panels closed after having them physically shut manually.

Conclusion:

Unfortunately, due to time and budget constraints, we realized after prototyping and research that we would not be able to afford to autonomously close the back panels. A review of our design requirements however, led us to discover that there was no actual requirement that specifically dictated that the system returning the rover into its cocoon state needed to be entirely autonomous. Because of this, our team decided to go with the solitary opening spring hinge design. We hope that future generations of the project however might find this post and our ideas useful to accomplish a fully automatic articulation of the auxiliary panels.

Ultrasonic Field of View Test

May 2, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (Project Manager and Electronics & Control)

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

In order to develop an object avoidance routine we needed to verify that the ultrasonic sensors would work for detecting objects. To verify the field of view a simple experiment was constructed that would determine the distance to an object. The experiment is as follows.

Parts Required:

HC-SR04 Ultrasonic Sensor
Arduino (Any will do)
Serial Monitor
Ruler or other measuring device
2 LED’s with CLR’s

Figure 1: Fritzing Diagram for FOV test

Setup:

The ultrasonic sensor has 4 pins: VCC, GND, Trig and Echo. Vcc and GND are for powering the device where as Trig and Echo are the signal pins. Trig is short for trigger, applying a pulse to this pin will emit an ultrasonic ping that travels from the transmitter. The echo pin is where you receive the ping coming off the object of interest. The time delay that takes place between these steps will determine how far away an object is. For our setup, Trig was hooked up to pin 13 and Echo was hooked up to pin 12 but any digital pins will work.

Next upload the code provided to get an output from the Serial Monitor showing the distance to the object.

Figure 2: Code for FOV test

Determining Field of View:

In order to determine the field of view of the object two rulers were set up to determine when we lost sight of the object. The object was recognized directly in front of the sensors at x = 16 cm and then moved up and down in the z-direction. The sensor lost sight of the object at about 6 cm above or below. The same situation took place when the object was moved along the y-direction. From this we can gather that the field of view is about 18 degrees.

Figure 3: Determining Safe Object Detection Distance

The distance L is the safe object detection distance. If we detect anything closer than that is when we lose overlap between the sensors which means that we could run into trouble if anything gets closer than that. The distance can easily be found as:

Figure 4: Determining Safe Distance L

Conclusion:

The Ultrasonic sensors are actually pretty impressive. I’ve never uploaded code and received immediate results, this was a first for me. I would put my hand in front of the sensor and compare the actual distance to find they were very comparable. With these sensors we can easily detect if an object is too close and from that we can implement some kind of avoidance strategy.

References

http://www.instructables.com/id/Simple-Arduino-and-HC-SR04-Example/

Ultrasonic Sensors – Field of View

BEAR-ings

May 2, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (Project Manager and Electronics & Control)

Approved By: Miguel Garcia (Quality Assurance)

Probably the coolest part in most mechatronic designs would have to be bearings. They’re simple but confusing and very amusing, at least for me. There are many different types of bearings in all different shapes, sizes, colors, and functionalities. The reason for this blog post is that one of the main issues with the Pathfinder build was the lack of knowledge when it came to constructing the rocker-bogie mechanism. Let me begin by saying that it is in no way previous semester’s fault for not understanding this since we are electrical engineering students.

There are two main types of bearings, thrust and radial, from those branch various specifications about each one in regards to size, forces, and speed. However, the scope of this post is to enlighten those who are concerned about which type of bearing to use.

Figure 1: Different Loads Acting on A Bearing

Thrust bearings are the type of rotary bearing that allow parts to rotate about the other but unlike their radial counterparts they are designed to support axial loads. Axial loads are forces that are applied in the direction of the shaft.

Figure 2: Example of a Thrust Bearing

Radial Bearings are the opposite and they support, wait for it, radial loads! These bearings are common and you have probably used them once or twice whether they were in your skateboard or roller blades.

Figure 3: Example of a Radial Bearing

The issue with the build of the Pathfinder is that the load on the rocker-bogie mechanism is axial and the type of bearing placed on them was a radial bearing. This radial bearing was essentially acting like a spacer between parts since they were making contact with both rotational elements. To improve the design we obtained some inexpensive thrust bearings off Amazon and they have solved the problem.

References

6 Wheel Electronic Differential

May 2, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (Project Manager and Electronics & Control)

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

Have you ever considered how a train makes a turn? Really try and think about it, it has two wheels on a track separated by a distance but when it turns it doesn’t fly off the track. It’s not very intuitive but if a train was making a right turn, going along a curve to the right, the left wheel is traveling a greater distance since it’s on the outer curve. However, the two wheels traveling along the track are joined by a steel shaft that doesn’t break. So, what is the explanation for this phenomenon?

Figure 1: Differential Explanation

Trains have conical wheels that allow for this freedom of motion at the track, they slide back and forth along the track allowing the train to tilt one way or the other. Now, the Pathfinder is not a train and will not be riding along tracks, but the same concept applies.

Encoders

The Pathfinder has 6 motors all connected to the same power source and in a perfect world if we supplied each of these motors with the same PWM command they would all go the same speed. However, this is not a perfect world and many factors can come into play when it comes to how fast the motor spins. First off, the whole premise behind the Pathfinder is that it can climb objects asymmetrically, that is each motor can be experiencing a different load which is one of the major reasons behind needing an electronic differential. Secondly, when we make turns we want to make sure the wheels are going at the speed we want them to account for the difference in distance traveled. And finally, due to natural mismatch in motor build we need to examine the difference in speed of the motors.

Herein lies the problem we have faced and have tried to come up with a solution for the past month or so. The motors on the Pathfinder currently do not have any encoders. We have looked at every possible type of encoder such as magnetic, optical, and any other possible type but we have finally realized that the only way of getting a truly good output from the encoder is by purchasing motors that already have encoders installed. The reason behind this is simply to achieve the greatest possible resolution with your encoders is to get your output prior to the gearbox. I can not stress that enough. If you ever have a project that you need encoders on make sure you either buy motors with an extended shaft or motors that have encoders included otherwise you might find yourself in the same situation. $200 later we now have our encoders.

Hall Effect Sensors

Now that we have motors with encoders connected prior to the gear-box we need to understand how they work.

Figure 2: Diagram of Hall Effect Sensor

In the presence of a changing magnetic field, a charged semiconductor plate will deflect the flow of electrons from one side or the other. Consequently, one side of the plate will become more negative while the other becomes more positive. This is the basic principle of how a hall effect sensor works. A magnet is placed perpendicularly to the sensor plate and the Hall Voltage on the plate is observed. This is typically found in many encoding applications. There are two different types of Hall Effect sensors available, one that is a measure of flux density and the other is compared against some threshold voltage. We will be utilizing the latter since we are only concerned with the count and not the distance to the magnet. Another great feature of hall-effect sensors is their ability to toggle between states which means that bouncing is not an issue.

The encoders that we have paired with our motors have 6 pins associated with them, they are as follows:

M1 (Motor Power Supply 1)
GND (Encoder Ground)
C1 (Encoder Channel 1)
C2 (Encoder Channel 2)
VCC (Encoder VCC)
M2 (Motor Power Supply 1)

For each revolution of the motor we will receive 11 counts per channel which results in 22 CPR overall. Depending on the gear-box reduction ratio, which in our case is 280 (14 RPM), we can calculate the resolution as follows:

Figure 3: Determining the Resolution of Shaft Encoders

Note that this is the maximum resolution and there is an included error from the motor manufacturers data sheet. Depending on the amount of precision you need you can always use both channels, also if you need to determine direction of the motors then you will need to use both channels. For our purposes though we will only need to occupy one channel since pin allocation has become something of an issue for us.

Implementation

To accurately and efficiently read the encoders we will be using interrupts. By using interrupts we can allow the code to progress as normal and minimize the amount of time outside of the main loop. In order to make this 6 wheel differential work we have two options.

We can set a desired speed that the robot travels and make all 6 wheels track that speed, or try to stay within a certain margin of that speed.
We can set one of the motors to a certain PWM value that we are comfortable with and force the other 5 motors to follow that speed.

The issue with the second option is that even though we are sending a constant speed to one motor, it could fluctuate about some speed and that can cause issues with our control scheme. There is much less error when tracking a step input rather than a varying signal. Therefore the plan of action will be to set a desired speed, within capable limits of the motors, and make each motor follow that desired state.

In order to realize this we are going to need to design a controller that can follow this input. In my experience one of the easiest types of controllers to implement would be a proportional controller. Proportional control is relatively simple and comes at a low cost to the memory of our MC.

After running some experiments and playing with the gain we can figure out exactly how to implement this type of controller. For our purposes we will have 6 controllers, one for each of the motors. The input will be a constant velocity and the output from the encoders will be fed back to the summing junction to compare with the set point.

Software

Reading the Encoders

To efficiently read the encoders we will need to set up some interrupt service routines, specifically one for each motors encoder channel. This will be done similar to the following code:

Figure 4: Code for reading the encoders

To get more information on how to set up interrupts like this please refer to the blog post regarding them HERE.

To verify that the output from the ISR was correct I applied a test voltage from a power source and found that the elapsed time between pulses was about 1450 microseconds for the 14RPM motors. After playing with the values and factoring in the gear ratio and CPR values the no-load speed of the 14 RPM motor was approximately 13.4 RPM which verified that these encoders are providing good feedback.

Control

Knowing the limitations of your control is important when it comes to implementing a design. For example, we know that these motors can spin without any load at a maximum of about 14 RPM. So, we want to travel at a speed that will allow for the system to adjust for disturbances such as changing loads, error in sensor readings, and anything else that might present itself. Therefore, we will set the desired speed to a comfortable 10 RPM, this will allow the system to adjust in both directions.

We can include different equations in our ISR to calculate the speed but it would be easier if we just returned the delay between pulses and let the control track that instead. For a speed of 10 RPM it can be shown that the delay is about 1,950 micro seconds. If the actual speed of the motor is greater than 10 RPM then the delay would be less and if the motor was traveling slower the delay would be greater. Also, if we wanted to apply a gain to the controller we would need to come up with something that makes sense. If one of the motors was traveling faster than the set point by 1 RPM then that would translate to about 100 microseconds so if we wanted to allow the controller to respond aggressively to large errors a gain of about 4 would do the trick. With all of that in mind we can construct the controller as follows:

Figure 5: Code for Speed Controller

References

Pin Change Interrupts

May 1, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (Project Manager and Electronics & Control)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

If you think back to your days of EE 346 you’ll remember the daunting feeling of dealing with interrupts. While we barely skimmed the surface, they’re really not that troublesome. The thing to note is that there are two types of interrupts, hardware & software. Hardware interrupts take place externally from the chip such as a physical button being pressed or any kind of input changing state. Software interrupts occur internally and most likely will be the result of a timer. Hardware interrupts can be further broken down into two more categories: external interrupts and pin change interrupts. Although pin change interrupts are technically external the difference with these is that they are not pin specific, the ISR corresponding to that pin will be called any time the condition is met from any pin on that port tied to the ISR. This can be more difficult to work with than the regular external interrupts which are pin specific but the advantage of using this type is that for most AVR boards any pin can be configured as a PCINT.

For our purposes we needed six interrupts, one for each of the motors encoders and although the ATMega 2560 has 6 external interrupts two of them were on the same pin as the I2C pins SCL and SDA which meant we needed to learn something new. Which leads us to a brief discussion of PCINT.

STEP 1: Turn on Pin Change Interrupts

To turn on PCINT’s you need to configure the PCICR (Pin Change Interrupt Control Register) according to your specific purposes. This can be done the following way:

Figure 1: Pin Change Control Register and description

Since we will be routing all of our encoders to PCINT23:16 it makes sense that we should enable PCIE2. To do so we will include the line of code: [PCICR |= 0x04]. This can be done many ways but the idea is that we set that pin to 1 while keeping the other bits unchanged.

STEP 2: Pin Selection

Although any pin mapped to PCI2 will run that ISR, that is only if we set their masked bits in the Pin Change Mask Register. We only need to use 6 of the 8 pins mapped to PCI2 so we can still use the other analog-in pins if we need to later.

Figure 2: Pin Change Mask Register 2 Description

Again, we only will be wiring encoders to PCINT 16:21 so we will need to include the following line of code: [PCMSK2 |= 0x3F;].

STEP 3: Write the ISR

Now that you have configured your interrupt control registers and decided which pins are going to actively set the ISR all that is left is to tell the computer what to do when it reaches this state. Any time you ever write an ISR you should keep it as short as possible and when declaring variables make sure to make them of type volatile so it is never optimized. To define the ISR just include the following:

ISR(PCINT2_vect){} // Port K, PCINT16-PCINT23.

Finally, you will have something like this:

Figure 3: Pin Change Interrupt Example

References:

https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/

Buck Converter Efficiency

April 27, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Mohammad Yakoub (Mission, Systems, and Test)

Verified By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)

A Buck converter is a DC-to-DC power converter which steps down voltage (while stepping up current) from its input to its output. Switching converters such as buck converters provide much greater power efficiency as DC-to-DC converters than linear regulators, which are simpler circuits that lower voltages by dissipating power as heat, but do not step up output current. That is why we considered to use it to step down the output of our main battery to a voltage that can work for our Arduino board. The efficiency of the buck converter is extremely high reach 90% efficiency and higher in some cases. However from my experience with the buck converter the efficiency of the buck converter seems to decrease as the difference between the input and output increases. Fortunately, for the purposes of our build we are stepping from 12v volts to 9v, which puts us at 91% efficiency. The efficiency testing the power of the input vs the power of the output under different step down ratios. The input voltage is 12v, different output voltages that were tested. Starting from 1v to 12v, and each step I measured the power of the input and the power of the output and from there I was able to calculate the efficiency of the buck converter at different step down ratios.

Figure 1: Plot of Buck Converter Efficiency at Various Step-Down Ratios

References:

Custom Commands – Bluetooth Communication

April 12, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

One of the many benefits of working with the Arxterra App is the ability to create custom commands and communicate with your robot over Bluetooth. Although many of the necessary commands have been predefined there is still plenty of room to create custom user defined commands to make navigating and controlling your robot a breeze.

In this blog post we will examine the MOVE command which will allow the user to control the robots speed and orientation using the D-Pad on the Arxterra App. We will walk through how to set this up step-by-step to ensure that future semesters can focus on other aspects of their project.

Parts Required

Wheels with electric motors (Pathfinder has 6)
Motor Driver (Pololu VHN 5019)
Microcontroller (Arduino Mega2560)
Bluetooth Device (HM-10)
Android or iOS Device with Arxrobot App (iPhone 6)
Power for Electronics (12V Lead Acid Storage Battery)
Robot3DoT Library

Step 1: Physical Connections

First and foremost, you will need to wire everything up, that is motors to motor driver(s) and motor driver to the microcontroller. This can be done by looking up the data sheet for your specific motor driver and wiring accordingly. Also, you will need to connect your Bluetooth device to the microcontrollers serial port as well ensuring that TXD -> RXn & RXD -> TXn.

Step 2: Downloading the Arxterra App

In order to gain access to the Arxterra App you will need to get in contact with Jeff Gomes. The app is available for both android and iOS devices, however, it is easier to get the app onto an android device. There is one additional step when it comes to installing the app on an iPhone. Since the App store is a little bit more selective as to what they offer, the Arxrobot app is still considered to be in beta testing and you will need your specific Apple user ID to get access.

Step 3: Import the Robot3DoT Library

This is where you will find a lot of the code that will make your life a million times easier. This library can be found here. In order to import this library you will first need to download the library, leaving it in its .zip format. Once you have downloaded it you can import it into the Arduino IDE by opening your computers file folder and dropping that file into the library file within your Arduino folder.

Step 4: Including and using the Robot3DoT Library

After you have imported the library you will need to open a new script within the Arduino IDE. Now you will want to include this library in the sketch you have created and you should see at the top of your code the library include statements. If you would like to get a better understanding of how the code works you can view the libraries by finding them in the Arduino folder under libraries and selecting the libraries .cpp file. This can be very beneficial as you can make sure this code works for your specific purpose and if not then you can make modifications as needed.

Now you will need to insert the following lines of code to be able to use the command handler properly. All of these are entered before your setup code.

Robot3DoTBoard Robot3DoT; // Instantiate as Robot3DoT at end of class header
const uint8_t CMD_LIST_SIZE = 1; // total number of custom commands
void moveHandler(uint8_t cmd, uint8_t param[], uint8_t n);
Robot3DoTBoard::cmdFunc_t onCommand[CMD_LIST_SIZE] = {{MOVE,moveHandler}};

Note that for custom commands you will need to define the specific ID for that command. For example, the MOVE command is already associated with ID 0x01 and does not need to be redefined.

Within the setup code you will want to insert the following:

Serialn.begin(9600); // This opens up the serial port that your Bluetooth device is connected to.
Robot3DoT.begin(); // This is a predefined setup function within the Robot3DoT Library
Robot3DoT.setOnCommand(onCommand, CMD_LIST_SIZE);

In the main loop make the call:

Robot3DoT.loop();

Now you’re ready to write your command handler functions. The MOVE function already has functions that are associated with it but you are able to write your own functions if you’d like. For our purposes we wanted a simple move function to control it’s direction at a specified speed. The directional pad has four buttons: up, down, left and right. They all have their own unique ID associated with them and by processing the data sent to the Arduino we can assign their values accordingly. For example:

Figure 1: Implementation of a command handling function, Credit: Mark Huffman

Step 5: Verify Bluetooth Connection

This is perhaps the most troublesome step. When I was setting all this up I could not seem to get any sort of communication with the app and the Arduino. After wasting hours of changing serial ports, examining the libraries and looking up troubleshooting methods I discovered three key issues.

The HC-06 device we had from a previous semester was defective. I discovered this while looking up troubleshooting methods. A simple way to determine if your device is defective is by creating a “transmission loop”. This is done by shorting the RXD and TXD pins on the device and making sure it is turned on (If it doesn’t even turn on that’s your first clue). Download the free app Bluetooth terminal on your iPhone or Android and connect to it. Once you are connected you can send the device ASCII characters and it should send back exactly what you sent. If you are getting no response then your device is most likely defective.

There are different kinds of Bluetooth technology. iPhones only operate with BLE communication whereas Androids can use a variety. If you plan on using an iPhone to control your robot make sure you have an HM-10 or HM-11 device to connect to. Also, make sure that within the Arxrobot app phone configuration settings you have selected the proper Bluetooth connection.

For some reason the Arduino Mega will not allow you to upload code if you have Bluetooth connected to the Serial port. In which case I moved the Bluetooth to the Serial1 port. Since I changed the serial port physically and not within the software there was no established communication line. Let this be a reminder to make sure the serial port you are using is being called within the code otherwise this can be a nightmare.

Hopefully future semesters can learn from my shortcomings and not have to struggle with this aspect of their project.

Step 6: Drive Around or Something

Now that you have setup Bluetooth communication, defined your motor functions and wrote the code to establish communication between the app and your device you can literally do anything you want from blinking an LED to autonomous GPS navigation. Just know that all of your commands are going to be in this type of format and you can extract whatever information you want and do with it what you will.

References

Rocker-Bogie Suspension System

April 12, 2018/in Pathfinder Generation #5, Uncategorized/by Jordan Smallwood

By: Adolfo Jimenez (Manufacturing)

Verified By: Jordan Smallwood (Project Manager)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction:

In order to mimic the suspension capabilities of the rovers sent to Mars by NASA, our rover will incorporate the same rocker bogie suspension system utilized by the Mars rovers to traverse an extreme desert-like terrain. This suspension system, introduced with the original Mars Pathfinder project, is the same design preferred by NASA for nearly all the Mars rovers. The main advantage of this type of suspension system is that the load on each wheel is nearly identical and thus allows an equal distribution of force regardless of wheel position. Taking into consideration the harsh terrain found on Mars this type of suspension system provides a better alternative to that of the common 4-wheel drive soft suspensions found on most automobiles.

Figure 1: View of Differential Gearbox System without Box

Design enhancements:

For our project, since we are mainly building upon the design of previous semesters, we can utilize the things they did correctly and build upon things they may have overlooked. The main design difference, as it pertains to the suspension system, is the addition of a differential gear box. Whereas previous semesters utilized a barely functioning differential bar, or no differential at all, this semester we decided to remove the bar entirely and replace it with a much more functional differential gear box. This addition of a differential gear box will offset the wheel assemblies by about .8 Inches on each side and raise the main platform about .38 inches higher from the ground. Upon further research of rover suspension systems our group discovered a helpful blog on a website called Beatty Robotics. The website provides many helpful blogs describing the design and creation process for many custom Mars rovers and other robots. The particular blog post that helped us meet our needs pertained to a differential system used for a custom Spirit II Mars rover. Feedback on the blog pertaining to the parts used lead us to the website McMaster-Carr where we were able to order the parts to assemble our own Differential.

Suspension- Wheel Assembly:

Figure 2: Wheel Assembly

The wheel assemblies contain a total of 6 wheels with a symmetric build for both sides. Each side contains 3 wheels which are connected to each other by two links. The main linkage called the rocker has two joints, one affixed to an axel forming the differential mechanism and the other connected to the remaining two wheels. This linkage from the rocker to the other linkage between the two wheels is known as a bogie (hence the name rocker bogie). To go over an obstacle, the front wheel is forced against the obstacle by the center and rear wheels. The rotation of the front wheel then lifts the front of the vehicle up and over the obstacle. The middle wheel is then pressed and pulled against the obstacle by the rear and front wheels respectively until the wheel is lifted up and over the obstacle. Finally, the rear wheel is pulled over the obstacle by the front two wheels.

Suspension- Differential Gear Box:

Figure 3: Differential Gear Mechanism Close-up

The differential is composed of three identical beveled gears situated 90-degrees from each other at the center of the rover. Each gear is affixed to a 6-inch steel drive shaft that is mounted to the rover body by 2 mounted sleeve bearings. One gear connected to the left, one gear connected to the right, and the last gear assembled onto the main platform. The two rods facing opposite of each other on the left and right of the robot help serve as axels for the wheel assemblies. The axils are connected to the wheel assemblies by 2 parallel aluminum tubes that make up the rocker bogie suspension system. The inclusion of this differential insures that the robot’s body and pitch angle are always adapted even if one side of the rover steps over an obstacle. If one leg goes over an obstacle, an opposite force is applied to the other leg. So, if one leg goes up, the other leg goes down. This downward force onto the opposite leg helps the robot maintain traction in the leg assembly that is still on the ground. The way this works is when one side changes in pitch, say for instance one side begins climbing over an obstacle, this mechanism rotates the main body around the rocker joints by the average rotation angle of the two sides. For this differential mechanism, all gear ratios are the same. That means if the left gear rotates 10 degrees and the right gear rotates 20 degrees, the main platform will rotate 10 + 20 = 30/2 = 15 degrees or the averaged amount. This keeps the main box more level (less tilted) than it normally would be when going over large, uneven obstacles.

References:

Pathfinder Preliminary Design Blog Post – Spring 2018

April 12, 2018/in Pathfinder Generation #5/by Jordan Smallwood

By: Jordan Smallwood (PM), Diane Kim (E&C), Mohammad Yakoub (MST), Adolfo Jimenez (Manufacturing)

Approved by: Miguel Garcia (Quality Assurance)

Table of Contents

Project Overview

By Jordan Smallwood

Project Objective:

The Pathfinder is a project that has been passed down from generation to generation. The originators built the chassis and original idea back in the fall semester of 2016. A rover like this does not make its way into the EE department that often since the lot of us don’t typically have much experience with welding and fabrication. Luckily enough for our group we will be picking up the slack where the previous teams had left off. It seems as though every semester that attempts this project faces failure in one way or the other whether it is the differential rocker-bogie mechanism or leaving wires exposed to short the 12V golf cart battery. Either way, the overall aim of this project is to finally finish what other groups have started and that will be defined in the following sections of this report.

Mission Objective:

By Jordan Smallwood

The Spring of 2018 Pathfinder will follow the path laid down by previous Pathfinders. The mission will begin in front of the CSULB library where the rover will exit its cocoon state. The rover will then proceed to begin its journey through campus, a 0.09 mile journey to its charging station. There will be 10 predefined GPS checkpoints along the way and the rover will traverse a flight of stairs. Once the rover has arrived at the charging station it will begin to track the sun and provide the Arxterra user with up to date battery level conditions. Specifically the Pathfinder will demonstrate the following:

Custom solar panels capable of tracking the sun and exhibiting optimum orientation so that battery charge takes the least amount of time.
The rover will be able to enter and exit a cocoon state. The term cocoon state implies that the solar panes will fold up so that in the event of a dust storm the solar panels will not become damaged. This state will be entered if the rover is in launch, a dust storm or whenever the rover is operating over steep terrain.
The rover will be able to communicate with the Arxterra app providing information like battery level, panel angles, panel voltages and charging current.
The solar panels will have a form factor identical to those of the Spirit and Opportunity Mars Rovers.
The rover will exhibit a 6-wheel slip differential for turning and traversing rough terrain. Since the robot will be climbing over random objects, some wheels will not require the same speed as other wheels and this needs to be considered while operating the rover.
Demonstration of GPS navigation with obstacle avoidance.
The course mapped out by F’16 and S’17 will be the same course for S’18.
There shall be no modification to the rover that stands in the way of high desert operation.

Project Requirements

By Jordan Smallwood

Level 1 Requirements

The pathfinder will travel a 0.09 mile course. This course includes going up a set of 3 stairs at a 70 degree incline and another set of 3 stairs with a decline of 70 degrees.
Pathfinder shall launch from a cocoon state
The Pathfinder will enter and exit the cocoon state by Arxterra app user input.
Pathfinder shall allow the user to enter the “articulate state” program module which will be available once the Pathfinder has exited its cocoon state. This sequence will direct the solar cells at the proper orientation to allow max charge of the battery.
The Pathfinder will update the user with information about panel angles, GPS location, battery level and charge current when in the “Articulate state”.
The overall solar panel system will consist of two side panels, a rear panel and a base panel.
The solar panel design will be identical to those of the Spirit and Opportunity Mars Rovers.
A 6-wheel electronic slip differential shall be implemented
Wheels under a no-load condition will be considered and power to that motor will be decreased.
The Pathfinder shall demonstrate obstacle avoidance while making its journey through campus.
Any modifications made to the Pathfinder shall not inhibit the rover’s ability to operate in high desert condition.
Rocker bogie mechanism shall be improved by implementing a differential gear-box system as opposed to the differential bar.

Level 2 Requirements

By Jordan Smallwood

Course Duration
- The power budget of our overall design will determine the duration of our course, once this has been completed the actual distance traveled will either be verified by this or will have to be changed to a shorter distance.
- In order to travel up these stairs our mass report along with our motor mock up will verify that this can be accomplished.
Cocoon Launch
- To perform the cocoon state function the solar panels will be mounted to worm gears attached to DC stepper motors to ensure smooth operation.
Enter/Exit Cocoon State
- The Pathfinder shall communicate via Bluetooth with the Arxterra user and will have an interface allowing the user to enter/exit the cocoon state.
Articulate State
- The articulate state module will adjust the positions of the solar cells using a proportional controller.
- The proportional controller will accept the charge rate as an input and will output changes in orientation.
Telemetry
- While communicating with the user via Bluetooth on the Arxterra app the Pathfinder shall respond with packets of information related to this information.
Solar Panels
- These four panels will be constructed of aluminum such that the rover can operate in the harsh desert conditions typical of Mars.
- The side and rear panel’s will be capable of position orientation to enter and exit the cocoon state and also optimize battery charge
Solar Panel Form Factor
6-Wheel Electronic Slip Differential
- A coded differential will be used ensuring that the wheels are spinning at the same rate.
- IR range sensors will be mounted to the motors to determine the velocity of the wheels
- Current sensors will be used to determine the load on the wheels
No Load
- To conserve energy, the rover will stop rotation of a freely moving wheel using the current sensors
Obstacle Avoidance
- Ultrasonic sensors will be used to determine if an obstacle is in its path.
- An obstacle avoidance routine shall be implemented.
- The rover will not make any attempt to climb an object that it is unable to clear
Modifications
Rocker-Bogie Mechanism
- The differential gear box will be constructed of three miter gears, three machined shafts, six mounted bearings and shaft collars
- This mechanism will be mounted below the Pathfinder and enclosed in an aluminum box with the electronics.
- This box shall be easily removed for inspection and maintenance.

Work Breakdown Structure

By Jordan Smallwood

Figure 1: Work Breakdown Structure for Pathfinder Project

Product Breakdown Structure

By Mohammad Yakoub

Verified By: Jordan Smallwood

Figure 2: Product Breakdown Structure for Pathfinder Project

Resource Reports

By Mohammad Yakoub

Verified By: Jordan Smallwood

Power Report:

Figure 3: Preliminary Power Budget

Mass Report:

Figure 4: Preliminary Mass Report

Cost Report:

Figure 5: Preliminary Financial Report

System Block Diagram

By Mohammad Yakoub

Figure 6: Preliminary System Block Diagram

Interface Matrix

By Jordan Smallwood

Figure 7: Preliminary Interface Matrix

Software Design

By Jordan Smallwood

Obstacle Avoidance: In order to make sure that the Pathfinder does not fail the mission, ultrasonic sensors will be used in the front of the rover to verify that an object is not too large for Pathfinder to climb over. This routine will take place within the software and more information will be provided at a later time.
GPS Checkpoint Navigation: Pathfinder will use GPS location information from the on-board iPhone or Android device and follow the course as defined in the mission objective. This will involve some type of digital controller and will be implemented in software. Again, these are preliminary concepts and not much has been constructed as of now but will be provided as the semester continues.
Motor Functions: Pathfinder will perform very basic motor functions such as go straight, turn around, turn left, turn right and stop.
Read Encoders: To determine the speed that each wheel is spinning this function will examine the current speed of each wheel by counting the pulse trains given from the IR sensors mounted to the wheels.
Stop Motors Under No-Load: By examining the current associated with each motor we can make sure we are not spending energy for nothing. This will most likely be a conditional statement and if the current state of the motor is under a no-load condition, then the power supplied will be cut off. Reinitializing the motor speed once a load is present will have to be tested though.
6-Wheel Differential: When making a turn the speeds of each motor needs to be considered since they may be traveling along different paths but need to arrive at the destination at the same time. By examining the speeds of the motors we can modify the PWM signal applied to ensure that we are traveling smoothly.
Exit Cocoon/Articulate Solar Panels: When the user decides to either exit or enter the cocoon/articulate state the microcontroller will apply the functions necessary to do so.

Fritzing Diagram

By Diane Kim

Verified By: Jordan Smallwood

Figure 8: Fritzing Diagram

The components inside the chassis contains the following: batteries (2), dual motor drivers (3), ultrasonic sensors (2), servos (2), IR sensors (6), motors (6), and the Arduino Mega 2560 (1). Unlike the previous version which only had 1 battery, we will be using 2 batteries to power up the motor to decrease the size. The ultrasonic sensors are used to navigate the rover. The IR sensors are to be placed beside the wheels to measure the RPM by toggling the signal whenever the spoke of the wheel passes by. The VNH2SP30 dual motor drivers is used to control the speed of the motors thus the wheels. The servos are used for the pan tilt. All the peripheral systems are connected to the Arduino Mega 2560 to input and output signals.

Mechanical Design

By Adolfo Jimenez

Verified By: Jordan Smallwood

2D Drawings (Dimensions all in inches):

Rear and Top Side View:

Side View (left):

Figures(9,10,11): 2D Layouts of Physical Structure

For the pathfinder project, since we are mainly building upon the design of previous semesters most of the dimensions and physical parts will remain the same. The main design difference for the time being is the addition of a differential gear box. Whereas previous semesters utilized a barely functioning differential bar, this semester, we decided to remove the bar entirely and replace it with a much more functional differential gear box. This addition of a differential gear box will offset the wheel assemblies by about .8 Inches on each side and raise the main platform about .38 inches higher off the ground.

Differential Gear Box

Figures(12,13,14): 3D Layouts of Physical Structure

Two planar aluminum tubes for the rocker boogie suspension system are connected to each other by a differential mechanism. When one side changes in pitch say for instance one side begins climbing over an obstacle, this mechanism rotates the main body around the rocker joints by an average angle of two sides. Gear A connected to the left, gear B connected to the right and gear C is assembled on the main platform. In differential mechanisms, all gear ratios are the same. That means if gear A rotates 10 degrees and gear B rotates 20 degrees, the main platform will rotate 15 degrees.

Verification and Validation Plans

By Mohammad Yakoub

Verified By: Jordan Smallwood

Figure 15: Verification and Validation Part 1

Figure 16: Verification and Validation 2

Test

By Mohammad Yakoub

Verified By: Jordan Smallwood

3.3.1 Final Run

Description: The Pathfinder will follow a course That is 0.9 miles in length. The course will includes going up a set of 3 stairs at a 70 degree incline and another set of 3 stairs with a decline of 70 degrees. The robot will start the course in a cocoon state and will deploy solar panels.

Test Environment: Outside the classroom

3.3.2 Proportional Controller

Description: The Pathfinder will adjust solar cells using proportional controller.