Spring 2016 Pathfinder: Project Tango Module#5 – Android to Arduino Via Bluetooth

amarino_905

By:

Xiong Lee (Missions, Systems and Test)

Table of Contents

Objective:

The objective of this test is to be able to send data from Android OS (Java, android studio)  to the Arduino via Bluetooth. We use a simple open source code found on github to see if we can send data to the Arduino. The mission of this experiment is to move us closer to sending data from the Google tango (the Google tango is an Android OS device, therefore it uses java/Android studio) to the Arduino via Bluetooth.

Tools:

  1. Android Studio
  2. Arduino IDE
  3. Bluetooth Module (we used the HC-06)
  4. Arduino Uno / Mega
  5. LED
  6. Breadboard
  7. Android Phone with usb cord.

LED Test Java Code:

The Java code that is on github should work when you import it to Android studio. After importing the code into android studio, you have to wait and let android studio build the project. This will take from seconds to minutes. Once the gradle has been built, you can run the app. Before you run the app, you have to make sure your android phone is in debug mode (if you don’t know how to get it to debug mode, just google it with your version of phone) so you can connect it to android studio. Once your phone is connected to android studio, you can run it and choose your phone so the app can be on your phone. When have the app on your phone, then you need to go to the Arduino code. If you want to know more about the code, I suggest that you read and run through the code yourself to get an idea of how this app works.

The sample code can be found here

LED Test Arduino Code:

The Arduino code is also on github. It is at the bottom of this page here. Just copy and paste it to Arduino ide. Once you have it, go through the code so you know where to connect everything on the Arduino. Once you have connected everything the right way, verify the code and upload it to your Arduino. (Note: There are sometimes problem uploading code to the Arduino when the Bluetooth module is connected on the Arduino at the same time it is uploading. So to get over this problem, simply just take the Bluetooth module out before uploading the code and put it back on when the code has successfully been uploaded to the Arduino.)

 

The first LED is connected to pin 9 and ground. The second LED is connected pin 2 and ground. The third LED is connected to pin 3 and ground. The RX on the Bluetooth module is connected to pin 11 and the TX is connected to pin 10. On the picture above, the button “Light Up” were pushed and as you can see, all the LEDs lit up.

Results:

When you have both the Java code and Arduino code, you should be able scan and find your Bluetooth module on the app. Once connected, turn on the LED lights by sliding the bars to the right or pressing all light up. Below is a picture showing how it should look like when you are lighting up the LED. In the end, we were able to send data from java to Arduino via Bluetooth. To take this a little further, we successfully move our pathfinder prototype with the app.

1

Changing just bits and pieces of the code, we were able to make the rover go forward, backwards, and turn. The java code that was changed was only the button name. The  main change that made our rover move was changing the Arduino code. We sent the data to the motors instead of LED.

Making the LED App Control Motors:

The main thing that we changed in this code was the serial port, and adding the motor shield code. We changed the serial port that we use to send data to the Arduino. Since we are using the Arduino Mega, we use serial port 2 instead of pins 10 and 11 as above. In the first LED case, we made the rover go forward. The second LED made our rover turn right and the third LED made it go in reverse. On the Java code side, we didn’t change anything from the code, we just changed names of LED1, LED2, and LED3 to forward and reverse.

The demo video can be found here

Moving Rover Arduino Code:

The the code highlighted below is what was changed from the code given in the link above. These code were added so we can move the motors of our pathfinder.

 

#include <SoftwareSerial.h>

#include <stdio.h>

#include <DualVNH5019MotorShield.h>

DualVNH5019MotorShield md;

 

int ledONE = 2;

int ledTWO = 9;

int ledTHREE = 4;

int bluetoothTX = 11 ;

int bluetoothRX = 10 ;

char receivedValue ;

 

SoftwareSerial bluetooth ( bluetoothTX, bluetoothRX );

void setup()

{

 Serial2.begin(9600);  

 Serial2.println(“console> “);

 

 pinMode(ledONE, OUTPUT);

 pinMode(ledTWO, OUTPUT);

 pinMode(ledTHREE, OUTPUT);

 

//  bluetooth.begin(115200);

//  bluetooth.print(“$$$”);

//  delay(100);

//  bluetooth.println(“U,9600,N”);

//  bluetooth.begin(9600);

}

 

void loop()

{

int brightness = 0;

int led = 0;

signed int data = 0;

 

//if( bluetooth.available() )

  if (Serial2.available())

 {

   //data = (int) bluetooth.read();

   data=(int) Serial2.read();

   Serial2.println( data );                 // for debugging, show received data

 

     if(data == 26)

     {

       allDown() ;

     }else if(data == 89)

     {

       allUp() ;

     }else{

     led = data / 100;                     // which led to select ?

     brightness = data % 100 ;             // 0 – 25 , LED brightness ( * 10 ) for actual value

 

   switch(led)                             // Now, let’s select the right led.

   {

     case 0  : setLEDthree ( brightness * 10 );  break;

     case 1  : setLEDone ( brightness * 10 );    break;

     case 2  : setLEDtwo ( brightness * 10 );    break;

     default : setLEDthree ( brightness * 10 );  break;       // DO NOT know what to do ? must be led 3

   }

     }

 

   //bluetooth.flush();                       // IMPORTANT clean bluetooth stream, flush stuck data

 }

}

 

// SHUT DOWN all leds

void allDown()

{

   digitalWrite(ledONE,  LOW ) ;

    digitalWrite(ledTWO,  LOW ) ;

     digitalWrite(ledTHREE,  LOW ) ;

}

 

// ALL up now 

 

void allUp()

{

   digitalWrite(ledONE,  HIGH) ;

    digitalWrite(ledTWO,  HIGH ) ;

    digitalWrite(ledTHREE,  HIGH ) ;

}

 

void setLEDone(int brighteness)            // move rover foward

{

   int m1Speed = brighteness; // left motor

 int m2Speed = brighteness ;// right motor

 md.setSpeeds(m1Speed, m2Speed);

//analogWrite(ledONE,  brighteness*16 ) ;

}

void setLEDtwo(int brighteness)     // turn rover to the right

{

      int m1Speed =  brighteness; // left motor

 int m2Speed = -brighteness ;// right motor

 md.setSpeeds(m1Speed, m2Speed);

//analogWrite(ledTWO,  brighteness*16 ) ;

}

 

void setLEDthree(int brighteness)   // move rover in reverse

{

     int m1Speed = -brighteness; // left motor

 int m2Speed = -brighteness ;// right motor

 md.setSpeeds(m1Speed, m2Speed);

//analogWrite(ledTHREE,  brighteness*16 ) ;

}

Conclusion:

In conclusion, we were able to send data to the Arduino from Android OS via bluetooth. We then tried to control the our motors by changing up the code to light up LEDs to control the left and right motors on the pathfinder. The next step is to implement this code to the Google tango point cloud app and see if we can extract the depth and send it to the Arduino.

Source Materials:

  1. Sample code:       https://github.com/hishriTaha/AndroidLEDcontrol
  2. Demo video:        https://www.youtube.com/watch?v=G-8PoH8V9-Q
  3. Image:                  http://payload71.cargocollective.com/1/7/248583/3734433/amarino_905.png

 

 

Spring 2016 Pathfinder: Project Tango – Interactive Visualization of data from Tango using Paraview

2

 

By:

Tuong Vu (E&C – Sensors, Actuators and Power)

Peiyuan Xu (Project Manager)

Table of Contents

Introduction:

Google tango tablet can perform depth perception by using point cloud app, however, the  source code of  point cloud app is written in Java with different  modules. This  blog post assumed the reader has no experience in Java  programming, yet they can still extract data out from point cloud app. Paraview is an program on PC that offers alternate method to manipulate point cloud data, while the other method would involve  changing the Google tango Source code.

Paraview and VTK:

Paraview is a program run on the foundation of C, python,  and Java language. Paraview  version 4.01 was  design  for google tango  project. VTK (Visualization Toolkit) is used  to create digital filter in order to exclude any  unnecessary point  cloud data gather by Paraview.

For reference of how to set up Paraview on both PC and Tango tablet, see here

Testing Results:

Screenshot_2016-05-02-00-03-16

The above picture is a screenshot of Paraview Tango Recorder App. On the left side, There is a scroll button “record” that can be turned on and start recording the point cloud image.

Screenshot_2016-05-02-00-05-21

Then turn on the “Auto Mode” button, it will start scanning the area and capturing point cloud images. The “Take Snapshot” button will only take one image.

 

Screenshot_2016-05-02-00-05-43

Once the “Record” button turned off, the app will save the files in VTK format and send them via Bluetooth or through Wi-Fi to emails or Google Drive. In order to process the data on PC, we choose to save to Google Drive and then import the files to Paraview program.

1

In the Paraview program, you can 3D view the point cloud data. if you record the data in “Auto Mode”. you can enable the animation view and see the video. Paraview has some build in filter that you can use to filter out the point cloud data, however, most of the filter applications are designed for 3D indoor mappings. Next step for us is to research into VTK library and learn to build our custom filter to filter out the irrelevant data and only leaves a single point or an area that we are interested.

Task for future semester

 After paraview and VTK  filter all  points, the specific point needed to be transferred to  Arxterra  app.  Arxterra app will use the depth information from point cloud to drive pathfinder.

VTK example code :

#include <vtkSphereSource.h>
#include <vtkPolyData.h>
#include <vtkSmartPointer.h>
#include <vtkPolyDataMapper.h>
#include <vtkActor.h>
#include <vtkRenderWindow.h>
#include <vtkRenderer.h>
#include <vtkRenderWindowInteractor.h>

int main(int, char *[])
{
 // Create a sphere
 vtkSmartPointer<vtkSphereSource> sphereSource =
   vtkSmartPointer<vtkSphereSource>::New();
 sphereSource->SetCenter(0.0, 0.0, 0.0);
 sphereSource->SetRadius(5.0);

 vtkSmartPointer<vtkPolyDataMapper> mapper =
   vtkSmartPointer<vtkPolyDataMapper>::New();
 mapper->SetInputConnection(sphereSource->GetOutputPort());

 vtkSmartPointer<vtkActor> actor =
   vtkSmartPointer<vtkActor>::New();
 actor->SetMapper(mapper);

 vtkSmartPointer<vtkRenderer> renderer =
   vtkSmartPointer<vtkRenderer>::New();
 vtkSmartPointer<vtkRenderWindow> renderWindow =
   vtkSmartPointer<vtkRenderWindow>::New();
 renderWindow->AddRenderer(renderer);
 vtkSmartPointer<vtkRenderWindowInteractor> renderWindowInteractor =
   vtkSmartPointer<vtkRenderWindowInteractor>::New();
 renderWindowInteractor->SetRenderWindow(renderWindow);

 renderer->AddActor(actor);
 renderer->SetBackground(.3, .6, .3); // Background color green

 renderWindow->Render();
 renderWindowInteractor->Start();

 return EXIT_SUCCESS;
}

1

This  code  filters  the pixels  to make white  sphere and green background. The idea of this approach is trying to use the image processing and filtering method to get the point cloud data we want and on some level avoid Java Programming and modifying the point cloud app.

Source Materials:

  1. VTK example code:                                                                                              http://www.vtk.org/Wiki/VTK/Examples/Cxx/GeometricObjects/Sphere
  2. Paraview Setup:                                                                                                      https://blog.kitware.com/interactive-visualization-of-google-project-tango-data-with-paraview/
  3. Image:                                                                                                                                          http://ngcm.soton.ac.uk/blog/images/training/2015-06-24-VTK-logos.png

 

 

 

Spring 2016 Pathfinder: Current Drawn Test

2

by:

Tuong Vu (Electronics & Control – Sensors, Actuators and Power)

Table of Contents

Introduction:

            This blog post will be explaining the total current drawn from the batteries by the motors. The amount of currents drawn from the batteries are resulted of the wheels experiencing at different friction forces. Different friction forces  correlated to different terrains that the pathfinder traveled on. For example, rocky  or sandy  terrains  required the pathfinder to exert more torque on its wheels in order to move which corresponds  to more current  being drawn from the batteries. The friction force is much larger on sandy or rocky terrains compare to smooth cement terrains. The  more  currents  being  drawn by the pathfinder lead to shorter batteries life (refer the previous blog post about batteries life).

Test  procedure:

Components:

  • R.S.E.717 Multimeter
  •  Samsung S7 cell phone
  • Motors :  Pololu motors

Using  the DMM in series with the motors shield would allow currents  drawn from the batteries by the motors  to be observable.  As the pathfinder conducts its route, collecting the currents being drained from the  batteries is an issue. A smartphone was  attached in the back of the pathfinder to  record the  currents  being drawn  from the batteries as  the pathfinder goes through its route.

Current  drawn:

  • Moving back and forward  do  not  require  high  amount of  pressure  on the wheels  which  current was  drawn was  the low,  refer to figure.1.

1

Figure 1

  • Turning left and right required more than the average current drawn,so the battery life is shorter, refer to figure 2.

2

Figure 2

Different  load &  road environment :

Torque  is the ( N*M)  as  N is the force  and  M as  mass  of the total load. Amps is the current  drawn by  the motors. As  the  pathfinder  undergoes a  route through rocky  terrain, more torque  is required to turn its wheels.  Travelling on rocky terrain deplete the batteries much  faster than travelling on smooth surface, current drawn from the motor is linear proportional to the motor torque, refer  to figure 3.

3

Figure 3

Conclusion:

The amount of currents drawing from the batteries is related to the terrains that the wheels of the pathfinder travels upon. Rocky and sandy  terrains require the pathfinder to exert more torque on its wheel in order to move which corresponds  to more current  being drawn from the batteries,so turning left and right draw more current than going forward and backward.

 

Sources:

  1. http://curriculum.vexrobotics.com/curriculum/speed-power-torque-and-dc-motors/dc-motors              DC Motors

 

Spring 2016 Pathfinder Design and Manufacturing – Tilt System Finalized Design

 

17

by:

Lindsay Levanas (Design and Manufacturing)

Table of Contents

Introduction

As previously detailed in the Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design blog post, the tilt system will contain a base that will hold the tablet, phone, and tilt servo.1 While a prototype of this base has already been designed, it was around the measurements of the pan servo as the tilt servo had not yet been acquired. This report will serve to document the new tilt system base as designed around the measurements of the new tilt servo. Also mentioned will be the addition of cord holes in the previous design. Note that the final product will be constructed of 3D printed, ABS plastic parts.

Google Tango Tablet Encasement Improvement

In view of one of Pathfinder’s Level 1 requirements, an enclosed environment for a Google Tango tablet was designed.2 However, this design did not take into account the fact that the tablet will need to be continuously charging, as it has a shorter battery life then our Project’s required duration.3 Therefore, the position of the charging port was documented, and a cut-out was added to the previously designed tablet box.

1

 

Tilt Servo Measurement Process

In order to redesign the tilt system for the new servo, the servo first had to be measured and modeled. To begin with, the tilt servo’s basic dimensions (height, width and depth) were measured. Below illustrates the depth measurement as an example.

2

Note that with the servo horn, the depth is 1.744in (illustrated below), and with the fan attachment, it is 1.881in.

3

Similarily, multiple height and width measurements were taken as needed from varing reference points.

Next, the diameter of the servo horn was measured and found to be .236in.

4

The placement of the servo horn was based on the midpoint of the circle it is located on. Note that this circle has the same diameter as the width of the servo.

5

To assist in the tilt servo mounting design, the position of the screw flaps were also measured. These included the distance from the edge of the screw flaps to the other side of the screw holes, the thickness of the screw flaps (illustrated below) and the distance of the screw flaps from the back of the servo.

6

Lastly, the position of the power and controlling cord was documented to allow for a cord hole to be added to the previous design.

Following a similar process to the one demonstrated above, combined with a few calculations where needed, the servo fan was dimensioned as well.

Completed Tilt Servo and Fan 3D Model

For size and position reference, the above parts were modeled in Solidworks.
78

 

Tilt Servo Base Measurement Process

Combining the modeling process of the tilt servo detailed above, with the previous design of the tilt system base1 the previous base was modified to accommodate the new tilt servo. While a variety of measurement calculations were performed, only the main few will be detailed below.

To start with the tilt servo’s total depth of 1.881in meant that the tilt system base width changed from its original width of 10.98in to 11.19in.

9

The position of the servo horn changed the height of the servo encasement box supports from 4.29in to 4.98in.

10

To allow for proper mounting of the tilt servo, the original base design was modified to give room for the servo’s mounting screws. This was done by thinning the front of the servo support strut and servo encasement lid in alignment of the servo’s mounting flaps, as dimensioned above, so that screw holes can be drilled there later.
11

Next the position of the tilt servo’s cord was noted and a hole was added to the bottom of the servo encasement box.

12

Note that in view of the final selection of LED headlights,4 the previous tilt system base’s headlight holder design was removed. A safe adhesive method will be used for the future design.

13

Lastly, to accommodate the size of the 3D printer Spring 2016’s Pathfinder will be using, the design of the tilt system base was cut in half and a square connector bracket was added to connect the two pieces.

14

Conclusion and Future Plans

In conclusion, Spring 2016 Pathfinder’s new tilt system has been modified to fit the new tilt servo and to account for charging cords that are required by components of the system. LED mounting will be detailed after the new tilt system has been fabricated.

1516

17

Sources:

  1. Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design, Tilt Base, 3/9/16 http://arxterra.com/pathfinder-design-and-manufacturing-tilt-system-design/
  2. Spring 2016 Pathfinder Preliminary Design Documentation, Level 1 Requirement, 2/19/16 http://arxterra.com/spring-2016-pathfinder-preliminary-design-documentation/
  3. Spring 2016 Pathfinder: Project Tango Preliminary Research                             http://arxterra.com/spring-2016-pathfinder-project-tango-preliminary-research/
  4. Spring 2016 Pathfinder: LED Headlights                                                             http://arxterra.com/spring-2016-pathfinder-led-headlights/

Spring 2016 Pathfinder: LED Headlights

1

by:

Juan Acosta (Electronics & Control – MCU Subsystem & Firmware)

Table of Contents

Introduction:

One of our requirements is to have the Pathfinder explore the CSULB campus at night. In order for us to accomplish this objective, we will need a way of maintaining a visible line of sight for the Tango Tablet and Android Phone. So we decided that we would give the Pathfinder bright headlights that would allow us to see a maximum of 4 meters or about 12 feet ahead of the pathfinder.

 

Materials:

  • HC-06 bluetooth Module
  • Ar 2560 or Arduino UNO
  • Jumper Wirduino MEGAes (4)
  • 6 Piranha 5V Led Light Panel Board White Night Lights Lamp Super Bright (2)
  • Laptop with Coolterm application

 

Fritzing Schematic and Steps:

2

 

  • Wire GND of the HC-06 to GND on the arduino
  • Wire VCC of the HC-06 to 5V on the arduino
  • Wire RXD of the HC-06 to TX0 on the arduino
  • Wire TXD of the HC-06 to RX0 on the arduino
  • Wire 5V of the LEDS to PIN52 on the arduino
  • Wire GND of the LEDS to GND on the arduino
  • Upload arduino code provided. (Notice: Be aware that the HC-06 must be unplugged while uploading code to the arduino, otherwise you may run into functionality issues.)
  • Initially you will have to pair the HC-06 with the laptop through bluetooth (Password for HC-06: 0000 or 1234)
  • Manually control the LEDS through Coolterm by sending a ‘0’ for off, or ‘1’ for on.

 

Arduino Code:

// The following code was written, tested and debugged by Juan Acosta for

// testing the LED Headlights operation using the HC-06 to implement commands

// being sent from the COOLTERM application from a laptop or phone to the arduino.

// Group: Pathfinder Spring 2016

// Electronics and Control:  Juan Acosta (MCU Subsystem and Control Firmware)

///////////////////////////////////////////////////////////////////////////////

// following are connections required for HC06 module:

// connect BT module TX to RX0

// connect BT module RX to TX0

// connect BT Vcc to 5V, GND to GND

///////////////////////////////////////////////////////////////////////////////

// following are connections required for LED Headlights:

// connect 5V to Pin 52 of the arduino MEGA

// connect GND to GND

///////////////////////////////////////////////////////////////////////////////

void setup() {

pinMode(52,OUTPUT);       // initialize pin 52 as output for LED Headlights

Serial.begin(9600);       // set the data rate for the Serial Port

}

char a; // stores incoming character from other device (phone, tablet, or laptop)

void loop() {

if (Serial.available()){        // if text arrived in from hardware serial…

a=(Serial.read());

if (a==’1′){

digitalWrite(52,HIGH);     // turn the LED Headlights on (HIGH is the voltage level)

}

if (a==’0′){

digitalWrite(52,LOW);      // turn the LED Headlights off

}

if (a==’?’){

Serial.println(“Send ‘0’ to turn LED Headlights on”);

Serial.println(“Send ‘1’ to turn LED Headlights off”);

}

// you can add more “if” statements with other characters to add more commands

}

}

Video Demonstration

Conclusion:

We were able to meet the requirement of having a distance of at most 4 meters or 12 feet lit up. These LED lights will definitely help illuminate the path for the pathfinder as it traverses through CSULB at night. Even though these LED lights are super bright, they should not be relied on as the primary source of lighting aid, we are using these in conjunction with the lighting from all the lamp posts around campus. After we confirmed that the LED Headlights were working through bluetooth, we can then transfer what we applied over to arxterra so we can control the LED Headlights through the arxterra control panel through custom commands.

Sources:

LEDs:

http://www.ebay.com/itm/181941929073?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Coolterm:

http://freeware.the-meiers.org

 

Spring 2016 Pathfinder: Project Tango Preliminary Research

projecttangologoblack

by:

Peiyuan Xu (Project Manager)

Nicholas Lombardo (Project Assistant)

 

Table of Contents

Introduction:

This spring 2016 Pathfinder project will use Google’s Project Tango as a platform to test and implement SLAM (Simultaneous Localization and Mapping) technology for autonomous vehicles. Project Tango uses computer vision to give device the ability to know the position in the relative 3D space as well as the distance from the surrounding objects to the device itself.

 

Physical Description

tango_specs1

The Tango tablet has a physical dimension of 119.77 x 196.33 x 15.36mm.

The weight is 0.82 lbs (370g)

Tango_hw

On the back of the tablet, it has a fisheye camera placed in the middle with an IR projector on the right and a RGB-IR camera on the left. The IR projector and RGB-IR camera work together with IMU (Inertial Measurement Unit) sensors to perform the features of Motion Tracking, Depth Perception and Area Learning.

 

Key Features

  • Motion Tracking

The IMU is used to give feedback on the device orientation and spatial displacement from a reference point. The Motion Tracking feature is usually achieved by integrating readings from orthogonally placed gyroscopes, magnetometers, and accelerometers.

Learn more about Motion Tracking

  • Depth Perception

Tango’s Depth perception can provide feedback on distances between the device and nearby solid objects. Tango uses an approach called structured light sensing where a pattern of light is cast and the size and shape of the pattern seen by the camera is used to determine the distance.

Learn more about Depth Perception

  • Area Learning

Tango’s Area Learning feature helps with motion tracking by correcting drift and helps with navigation of indoors applications. It uses image processing of visual features in a virtual environment to recognize a previously-visited location.

Learn more about Area Learning

 

Limitations:

  • The IR sensors for depth perception is generally restricted to indoor environments (sun and incandescent IR light can drown out structured light sensing). Therefore, in order to accomplish the requirements for both solar panels implementation (under direct sunshine) and Tango applications (without sunshine), the mission course is changed to be at CSULB campus during night time.

 

  • Range of IR sensors practically limits its use to nearby obstacle detection rather than long-range path creation. The range of the IR sensor is from 0.5 meters to 4 meters based on Project tango’s website.

 

Power Test For Tango Tablet

IMG_3208 IMG_3210 IMG_3215

The purpose of this test is to gain the power specs while running point cloud App, screen on, bluetooth on, WiFi on for worst case. 

The result shows that it takes about 2 hours and 16 minutes to run the battery from fully charged (100%) to 14%. In which case, it dose not meet our level 1 requirement of running for 4 hours. Also it is recommended to use a high-power 2A USB hub to charge the Tango Tablet.

Therefore, in order to meet the level 1 requirement, an extra portable charger (Power output: 5V, 2A) with Micro USB cable will be used to charge Tango tablet continuously during the mission.

Reference:

 

Get started with Project Tango

Notice that Project Tango offers APIs in C and Java, and a SDK for Unity. For developers who are already familiar with Android studio and Java development, the Java API is the one to use. Developers who want to be able to write apps with the Android NDK (Native Development Kit) should use the C API, which enables more flexibility on the native and system level. The Unity SDK is good for game development in 3D virtual environment.

Learn more on API Overview

Tutorials can be found here:

Once you have downloaded the sample code and successfully installed the App. you will see a window like this:

Screenshot_2016-04-07-22-38-12

This is the Point Cloud version of a person standing in the Hallway. On the top left, It states that “Average depth(m): 4.352” which means that person is about 4 meters away from the tablet.

On the right side, there are 4 buttons. The first “Bluetooth” button is the custom button that I made in order to connect the tablet to Arduino through BlueTooth while running the Java Point Cloud App. Below the “Bluetooth” button, there are the three buttons that can switch from different orientation and give different point of view of the Point Cloud data.

After we have done that, now it is important to understand how the system should work between Project tango and Arduino and then eventually implement the software modules on Arxterra.

 

Project Tango System Block Diagram

tango_system
Above is the Project Tango System Block Diagram that provided by Professor Hill. The diagram is  divided into two parts. In the Android Operating system, commands will be sent by Arxterra to WiFi Manager API and decoded in Tango Android OS. Then the main point cloud App will process the coordinates and position information from Sensor Event API and Tango XYZij structure and send feedback telemetry back from WiFi Manager API to Arxterra. In the Arduino part, Java Point Cloud App will send command sequence through bluetooth to UART subsystem decoder and then to Arduino board. Then the microcontroller (Arduino mega) will send serial read/write to command decoder to command handler and then to GPIO to control the Ultrasonic sensors, H-bridge motors and servos. From that, our team develop the software modules and tasks breakdown to accomplish the system design.

 

Software Modules and Task Breakdown

Module 1:   Sending commands to WiFi Manager API (Through “cool term”)

Module 2:  WiFi Manager API sending telemetry out to Arxterra

Module 3:  Tango SDK or NDK (Translate XYZij to Tango)

Module 4:  SensorEvent API (IMU)

Module 5:  BlueTooth API to HC-06 Module to Arduino

Module 6:  Arduino to HC-06 to BlueTooth API

Module 7:  Arduino Command Decoder to Command Handler

Module 8:  Arduino Command Handler to GPIO Output to Motors and Servos Control

Module 9:  GPIO Input to Telemetry Send Packets to UART Receiving Subsystem to Android OS

Module 10  Java App Command Sequence Development

 

More on IMU and Coordinate System

Module 3 requires to understand the IMU (Inertial Measurement Unit) and Project Tango Coordinate Frames. The links below explain the Tango Coordinate System Conventions

Coordinate System Convention

The next link explains Android devices IMU sensors in general that includes Tango Tablets as well

Sensors Overview

Research into PCL and ROS

Module 10 requires knowledge of processing point cloud data. This may be as easy as importing a library and using the defined classes/methods for data manipulation.

The PCL (Point Cloud Library) and ROS (Robot Operating System) are both open sources that offers libraries and tools to analyze point cloud data. Many companies and developers are working on building application with PCL or ROS for Project Tango. Some useful Tips and tutorials can be found here:

How to build applications with PCL for Android

Getting Started with Tango and ROS

PCL Documentation

 

Conclusion

The use of Project Tango tablet is ambitious since it is fairly new and requires extensive knowledge of Android App development and Java Programming. In this semester, our team is able to attempt and finish some of the Project Tango modules, that includes  “BlueTooth API to HC-06 Module to Arduino (Blinking LED and Motors Control)”, “Extract Point Cloud Data from Tango and process with Paraview software”. We will have upcoming blog posts to explain and show the steps of how these modules can be done. We hope the research work we have here can benefit the future groups or individual who wants to continue work on Project Tango.

Source Materials:

Spring 2016 Pathfinder Solar Panels Implementation


13421

By:

Tuong Vu (Sensors, Actuators and Power)

Table of Contents

Introduction:

        Based on the requirements from the customer, the pathfinder must be able to self – charge its batteries using solar panels. This document explains the requirement for the solar panels and physical implementation based on batteries. The  customer  wants  the  pathfinder  to be  able to run for four  hours and  self-charge for eight  hours. Our mission required the pathfinder to  navigate around  CSULB  with the assistance  of Google Tango  Tablet.

Batteries:

        The Batteries  from  older design  are  being used in order to  power  the  motors  system,  pan and  title system, and sensor system.  These Batteries  are Gens ace 7.4V 10000mAh Pd Based  on the the test we  conducted, these batteries are sufficient to support the pathfinder for the mission. The pathfinder draw an  average  of  1.43A  while  operating  at  full load in moving forward and backward, turning left and right, and  stopping.  Equation .1  shows  the  total  time the pathfinder can operate with these batteries.

1

 

2

A DMM is measuring the average current drawn by the motors when the pathfinder is conducting a forwards, backwards,  stop, and start maneuvers.

Calculation:

According to  the  batteries that we  planning to use, the current supplied  by  the  solar panels must be about 640 mA to charge our  batteries from 0V, batteries are drained,to 7.4V.  Fortunately, the batteries  will never be totally  drained to  0V,  but our solar panel are adequate to  charge the batteries from  1V to  3.2 V within 8 hours refer to equation 2 and equation 3.

e2

e3

Solar Panel:

Requirement:

12 Voltage

700 mAh

 

·         ECO-WORTHY 10W Solar Panel 10 Watt 12 Volt PV Solar Module, Solar Cell Panel

·         22 Voltage output

·         450 mAh

  2 X

·         NPower Amorphous Solar Panel Battery Maintainer Kit – 2.5 Watts

·          2.5 Watt, 167 mAh maximum power output

·          22 V output

 

Pathfinder  will utilize both  two NPower Amorphous Solar Panel Battery and ECO-WORTHY 10W Solar Panel 10 Watt 12 Volt PV Solar Module as its charging  mechanism, and  the total current  supply by the solar panels is about 640 mA ( max). Modifying  the solar panels placement on the pathfinder to resemble  the Arxterra logo; allow the pathfinder to be more efficient in obstacle avoidance.

 

logo

Image.1 Arxterra Logo

( Solar Panel  Configuration  will  closely  resemble  the  Arxterra Logo to  reduce  collisions)

 

Source Materials:

  1. https://www.batterystuff.com/kb/articles/solar-articles/solar-info.html ( Tutorial  website for uderstanding the  mechanic ofhow solar panels  function )
  2. http://www.amazon.com/ECO-WORTHY-Solar-Panel-Watt-Module/dp/B00OZC3X1C ( solar panel  website  for physical  dimesions and electrical  )
  3. http://www.amazon.com/NPower-Amorphous-Solar-Battery-Maintainer/dp/B00A2OJ55U/ref=sr_1_1?s=lawn-garden&ie=UTF8&qid=1459759847&sr=1-1&keywords=NPower+Amorphous+Solar+Panel+Battery ( solar panel  website  for physical  dimesions and electrical  )
  4. https://www.arxterra.com/ ( Solar panels implemenation.)

Spring 2016 Pathfinder Design and Manufacturing – Rocker Bogie Suspension System Design

Simplified double size rocker bogie

By: Lindsay Levanas (Design and Manufacturing)

Table of Contents

Introduction

The goal of Spring 2016’s Pathfinder is to harbor a Google Tango tablet, phone, solar panels, pan and tilt system and self-contained electronics.1 To support this a rocker bogie suspension system2 will be used. As a purchasable rocker bogie suspension system could not be found to fit the size requirements of the tilt system design3 the suspension system will be built from scratch. This report shall document the design process.

 

Rocker Bogie Suspension System Design

To start with, a general design for the rocker bogie suspension system (hereafter referred to as suspension system) needed to be selected. To guarantee that basic proportions were kept, ServoCity’s Bogie Runt Rover4 was used as a model. To fit the requirements mentioned in the introduction, this model will be simplified and doubled in size.

Rocker Bogie Suspension System Measurement Process

ServoCity’s Bogie Runt Rover consists of six part types that require Solidworks modeling for Spring 2016’s Pathfinder design. To obtain accurate dimensions the individual parts were measured with digital calipers.

f1

Placement and dimension of screw holes were also measured.

 

f2 f3

These measurements were then marked on rough sketches to allow for easy reference for the Solidworks model.

f4

Where necessary, simple calculations were done to translate the digital caliper’s measurements into dimensions Solidworks requires.

f5 f6

For parts that were difficult for the digital calipers to measure, trace marks were made on paper and measurements were taken from there.

f7

 

Rocker Bogie Suspension System Model Alterations – Size

After measuring and modeling all of the parts required for the suspension system design, a thickness needed to be selected. To start with, .25in was used, as this was the thickness in the original Runt Rover design. From there, the Solidworks model was doubled in size. The thickness however, was kept at .25in.

f8

 

Material Selection

Now that the suspension system parts are completely modeled, a material needed to be selected for their fabrication. ABS plastic and aluminum were considered. While ABS plastic has a density of .0376 lb/in^3, compared to aluminum’s density of .0983 lb/in^3,5,6,7 the 3D printers available to Spring 2016’s Pathfinder at this time are not large enough to print the suspension system’s enlarged parts. Therefore, the suspension system will be made out of aluminum.

 

Rocker Bogie Suspension System Model Alterations – Simplification

To assist in the fabrication process, the suspension system parts will be simplified. As the aluminum fabricator currently available to Spring 2016’s Pathfinder is limited to drilling holes and cutting straight edges, the parts will be squared off where necessary. Their crucial measurements however, will be kept the same.

f9

 

Rocker Bogie Suspension System Weight and Strength Check

Having modeled all of the parts, the next step was to check the weight and strength of the system as a whole. By setting the material of the parts in Solidworks, the weight of a part can be obtained. Alloy 6061 was used, as it is both a commonly used type of aluminum, and can be welded.

f10

f11

Above specified the weight of the swivel bar (the part illustrated in the previous section).  Following this procedure for all of the parts, the total weight of the suspension system totaled 10.65lbs for .25in thick aluminum, and 5.34lbs for .125in thick aluminum.

Keeping the weight in mind, the strength of the legs and top plate were then calculated. Stress and bending distances were solved for and listed in the below two charts respectively.8

f12 f13

Note that the length used for the legs (17.89) was found by calculating the diagonal of the 10.84in by 14.23in rectangle illustrated below.

f14

While all three thicknesses considered passed the stress test (it takes 6061 alloy aluminum 40,000psi to misshape beyond repair9) the amount each thickness would bend in the legs ranged from .6 to 4.7 inches. To compromise between the weight, stress, and bending tolerance, a thickness of .1875 was selected for the final design.

 

Conclusion and Future Plans

In conclusion, Spring 2016’s Pathfinder will consist of a rocker bogie suspension system where all parts are simplistically modeled after ServoCity’s Bogie Runt Rover and their measurements follow the procedure documented above. The material used will be alloy 6061 aluminum of thickness .1875in. The complete suspension system is illustrated and dimensioned below and in the future will hold a pan and tilt system, electronics enclosure box, and solar panels on it’s top surface.

f15 f16 f17

 

Source Material

  1. Spring 2016 Pathfinder Preliminary Design Documentation, Level 1 Requirement, 2/19/16 http://arxterra.com/spring-2016-pathfinder-preliminary-design-documentation/
  2. Rocker Bogie, Design, 2/29/2016 https://en.wikipedia.org/wiki/Rocker-bogie
  3. Spring 2016 Pathfinder Design and Manufacturing – Tilt System Design, Tilt Base, 3/9/16 http://arxterra.com/pathfinder-design-and-manufacturing-tilt-system-design/
  4. Bogie Runt Rover https://www.servocity.com/html/bogie_runt_rovertm__637162_.html#.VvmvlJGprwI
  5. Metals and Alloys – Densities http://www.engineeringtoolbox.com/metal-alloys-densities-d_50.html
  6. ABS Material Datasheet http://teststandard.com/data_sheets/ABS_Data_sheet.pdf
  7. kg/m^3 to lb/in^3 https://www.google.com/search?client=safari&rls=en&q=kg/m%5E3+to+lb/in%5E3&ie=UTF-8&oe=UTF-8
  8. Bending Stresses for Simple Shapes http://atcpublications.com/Sample_pages_from_FDG.pdf

ASM Material Data Sheet http://asm.matweb.com/search/SpecificMaterial.asp?bassnum=MA6061t6

Spring 2016 Pathfinder CSULB Wi-Fi Mapping

lower

By Xiong Lee            (Mission, Systems, and Tests)

Table of Contents

Introduction:

For us to finish our objective, we will need to be able to access the Wi-Fi from CSULB campus. One of our requirements is to have the pathfinder explore the campus and since we need Wi-Fi, we will have to map out the best Wi-Fi signal we have here at CSULB. Using the Wi-Fi Maximiser app, we were able to map out the Wi-Fi at CSULB.

Steps:

  1. First, we need to download the Wi-Fi Maximiser app on your phone here.
  2. Next, we need to be connected to the network that we want to map out. (for us, it is the beachnet +)
  3. After that, we need to have a map of CSULB because we are mapping out the campus here.
  4. Once we import the picture to the app, we can walk around campus clicking on the map every time we want to see the Wi-Fi signal we receive. (Note: we can only click on the map 20 times, then we’ll need to do another map)
  5. After we finish mapping out the Wi-Fi, we can generate the map with details and send to our email.

Results:

These are the results we got from walking around CSULB. We first did the lower campus and then the upper campus.

Lower Campus

lower

If you look at the dots on the map, it is labeled by a letter at the upper right of the dot going in alphabetical order from A to T (we can only scan 20 points at a time hence, A-T). These are the data received from the app which tells us the ping, lost packets, received packets, and whichever network we’re on at each location we monitored. Point A starts at the rec center and then we walked around in a clockwise direction ended up at point T (which is at the Pyramid). (The green spots are where we can received the best signals and red spots are the poorest signals.)

Wi-Fi details for lower campus:

Point A

Signal: 74%

Lowest ping response: 26 ms

Mean ping response: 26 ms

Median ping response: 10 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point B

Signal: 0%

Lowest ping response: 26 ms

Mean ping response: 26 ms

Median ping response: 0 ms

Received packets: 0

Lost packets: 16

Packet size: 1000

Network Name: beachnet+

 

Point C

Signal: 88%

Lowest ping response: 9 ms

Mean ping response: 9 ms

Median ping response: 8 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point D

Signal: 79%

Lowest ping response: 23 ms

Mean ping response: 23 ms

Median ping response: 10 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point E

Signal: 94%

Lowest ping response: 7 ms

Mean ping response: 7 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point F

Signal: 100%

Lowest ping response: 5 ms

Mean ping response: 5 ms

Median ping response: 5 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point G

Signal: 1%

Lowest ping response: 237 ms

Mean ping response: 237 ms

Median ping response: 237 ms

Received packets: 1

Lost packets: 15

Packet size: 1000

Network Name: beachnet+

 

Point H

Signal: 0%

Lowest ping response: 237 ms

Mean ping response: 237 ms

Median ping response: 0 ms

Received packets: 0

Lost packets: 16

Packet size: 1000

Network Name: beachnet+

 

Point I

Signal: 26%

Lowest ping response: 54 ms

Mean ping response: 54 ms

Median ping response: 42 ms

Received packets: 11

Lost packets: 5

Packet size: 1000

Network Name: beachnet+

 

Point J

Signal: 88%

Lowest ping response: 9 ms

Mean ping response: 9 ms

Median ping response: 8 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point K

Signal: 100%

Lowest ping response: 5 ms

Mean ping response: 5 ms

Median ping response: 4 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point L

Signal: 4%

Lowest ping response: 774 ms

Mean ping response: 774 ms

Median ping response: 825 ms

Received packets: 8

Lost packets: 8

Packet size: 1000

Network Name: beachnet+

 

Point M

Signal: 100%

Lowest ping response: 12 ms

Mean ping response: 12 ms

Median ping response: 5 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point N

Signal: 94%

Lowest ping response: 7 ms

Mean ping response: 7 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point O

Signal: 94%

Lowest ping response: 9 ms

Mean ping response: 9 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point P

Signal: 88%

Lowest ping response: 15 ms

Mean ping response: 15 ms

Median ping response: 8 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point Q

Signal: 50%

Lowest ping response: 21 ms

Mean ping response: 21 ms

Median ping response: 25 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point R

Signal: 75%

Lowest ping response: 13 ms

Mean ping response: 13 ms

Median ping response: 11 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point S

Signal: 45%

Lowest ping response: 3 ms

Mean ping response: 3 ms

Median ping response: 3 ms

Received packets: 5

Lost packets: 11

Packet size: 1000

Network Name: beachnet+

 

Point T

Signal: 30%

Lowest ping response: 72 ms

Mean ping response: 72 ms

Median ping response: 70 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

university music and dance department:

Music&Dance

On this map, we only monitor 4 points which can give us the details below. As said above, the points are labeled from A to D. We started from the left near the pyramid then went to the right towards parking lot 12. The generated heatmap shows us the best Wi-Fi spot in the area that we monitored. (Green is where we received the best signal and red is the poorest signal.)

Wi-Fi details for Music/Dance department campus:

Point A

Signal: 79%

Lowest ping response: 15 ms

Mean ping response: 15 ms

Median ping response: 10 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point B

Signal: 94%

Lowest ping response: 25 ms

Mean ping response: 25 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point C

Signal: 100%

Lowest ping response: 4 ms

Mean ping response: 4 ms

Median ping response: 3 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point D

Signal: 94%

Lowest ping response: 7 ms

Mean ping response: 7 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Upper Campus:

Upper

Above is the generated heat map for the upper campus at CSULB. The point A is started at the FA-4 building going around in a clockwise direction. This map has 20 points and as said above, the poorest signal is where the map is red and the best signal is the green area.

Wi-Fi details for upper campus:

Point A

Signal: 94%

Lowest ping response: 33 ms

Mean ping response: 33 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point B

Signal: 75%

Lowest ping response: 39 ms

Mean ping response: 39 ms

Median ping response: 11 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point C

Signal: 54%

Lowest ping response: 15 ms

Mean ping response: 15 ms

Median ping response: 14 ms

Received packets: 13

Lost packets: 3

Packet size: 1000

Network Name: beachnet+

 

Point D

Signal: 74%

Lowest ping response: 13 ms

Mean ping response: 13 ms

Median ping response: 10 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point E

Signal: 83%

Lowest ping response: 17 ms

Mean ping response: 17 ms

Median ping response: 9 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point F

Signal: 100%

Lowest ping response: 25 ms

Mean ping response: 25 ms

Median ping response: 4 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point G

Signal: 63%

Lowest ping response: 273 ms

Mean ping response: 273 ms

Median ping response: 12 ms

Received packets: 14

Lost packets: 2

Packet size: 1000

Network Name: beachnet+

 

Point H

Signal: 77%

Lowest ping response: 10 ms

Mean ping response: 10 ms

Median ping response: 9 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point I

Signal: 63%

Lowest ping response: 3 ms

Mean ping response: 3 ms

Median ping response: 3 ms

Received packets: 7

Lost packets: 9

Packet size: 1000

Network Name: beachnet+

 

Point J

Signal: 17%

Lowest ping response: 27 ms

Mean ping response: 27 ms

Median ping response: 21 ms

Received packets: 5

Lost packets: 11

Packet size: 1000

Network Name: beachnet+

 

Point K

Signal: 88%

Lowest ping response: 6 ms

Mean ping response: 6 ms

Median ping response: 7 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point L

Signal: 83%

Lowest ping response: 16 ms

Mean ping response: 16 ms

Median ping response: 9 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point M

Signal: 88%

Lowest ping response: 7 ms

Mean ping response: 7 ms

Median ping response: 7 ms

Received packets: 15

Lost packets: 1

Packet size: 1000

Network Name: beachnet+

 

Point N

Signal: 94%

Lowest ping response: 7 ms

Mean ping response: 7 ms

Median ping response: 7 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point O

Signal: 36%

Lowest ping response: 3 ms

Mean ping response: 3 ms

Median ping response: 3 ms

Received packets: 4

Lost packets: 12

Packet size: 1000

Network Name: beachnet+

 

Point P

Signal: 88%

Lowest ping response: 13 ms

Mean ping response: 13 ms

Median ping response: 8 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point Q

Signal: 34%

Lowest ping response: 49 ms

Mean ping response: 49 ms

Median ping response: 35 ms

Received packets: 13

Lost packets: 3

Packet size: 1000

Network Name: beachnet+

 

Point R

Signal: 23%

Lowest ping response: 71 ms

Mean ping response: 71 ms

Median ping response: 36 ms

Received packets: 9

Lost packets: 7

Packet size: 1000

Network Name: beachnet+

 

Point S

Signal: 88%

Lowest ping response: 26 ms

Mean ping response: 26 ms

Median ping response: 8 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

 

Point T

Signal: 83%

Lowest ping response: 13 ms

Mean ping response: 13 ms

Median ping response: 9 ms

Received packets: 16

Lost packets: 0

Packet size: 1000

Network Name: beachnet+

Conclusion:

As you can see on the generated maps, the green area are where the best Wi-Fi signal is. On  the  other hand, the red is where the poorest Wi-Fi signal is. The green area is where we want to launch our pathfinder and explore the area for 4 hours. These maps are not done to a 100 percent accuracy but, it will do because we just want to know the general area we can explore.

Sources:

Telstra Wi-Fi Maximiser

CSULB Campus

Wi-Fi image

Spring 2016 Pathfinder: Bluetooth Communication with the Arxterra App

Bluetooth

By: Xiong Lee (Systems Engineer)

Table of Contents

Introduction to Arxterra App:

We first had to download the Arxterra App by emailing Jeff Gomes to give us the invitation to download Arxterra. The app has two modes we can access. The first one is remote control and the other is community. The remote control mode allows us to control the movement of the pathfinder from the Arxterra app on your phone. The community mode allows us to control the pathfinder through the control panel online found here. For our purpose, we wanted to be able to communicate with app via bluetooth so we used the remote control mode to show Bluetooth connection. To learn more about the features of the app, the video is shown here.

Code:

The code that was used to test the Bluetooth connection to the Arxterra app is found here. This code was the latest code we could find that was used for this pathfinder. There was trouble having the code work. The first problem we came up with was not having all the library files so the code could not compile. The files that we needed in the library was found on GitHub and was implemented into our Arduino IDE library. The libraries on GitHub can be found here. To add libraries to the arduino, you can go here.

Debugging the code:

     if (cmd == MOVE) {

       /***********************************

       * motion command = 0x01

       * motordata[3]   left run    (FORWARD = index 1, BACKWARD = index 2, BRAKE = index 3, RELEASE = index 4)

       * motordata[4]   left speed  0 – 255

       * motordata[5]   right run   (FORWARD, BACKWARD, BRAKE, RELEASE)

       * motordata[6]   right speed 0 – 255

       * example

       * forward half speed  0x01, 0x01, 0x80, 0x01, 0x80 0101800180

       ***********************************/

       /*

       WARNING

       WARNING ONLY THE TB6612FNG HAS BEEN UPDATED WITH NEW INDEX ADDRESSES

       WARNING Typically all you need to do is add 2 to the index (1 -> 3, 2 -> 4, etc.)

       */

 

         // Pololu VNH5019 motorshield (Pathfinder)

//          move_VNH5019(data);

 

    

       //collisionDetection = (data[1] == 1) || (data[2] == 1);  // set to true if any motor is moving forward

     }

 

After finding all the libraries that we needed, we uploaded the code to the microcontroller. When testing the code, it did not move at all. From the picture above, we can see that the app is sending command packets to the arduino, but it is still not moving. So in conclusion, we knew that the code was not decoding the commands correctly and had to run over the code and debug it.

 

While running through the code, we found out that the move command was not being called in the command tab. When going to the move command, there was no command there to tell the pathfinder what to do because we have the pololu VNH 5019 motor shield on the pathfinder. The move routine was commented out and not calling the pathfinder to move. So after uncommenting this command (the code highlighted in red above), we also needed to uncomment the move subroutine on the first tab (arxrobot firmware).

 

//void move_VNH5019(uint8_t * motordata)

//{

//  int m1Speed = dirArray[motordata[1]] * motordata[2]; // left motor

//  int m2Speed = dirArray[motordata[3]] * motordata[4]; // right motor

//  md.setSpeeds(m1Speed, m2Speed);

//}

 

Another problem with the code was in the move_VNH5019 routine. The motordata[ ] should be in the order of 3,4,5,6. So instead of the code you see up there, it should be

 

 int m1Speed = dirArray[motordata[3]] * motordata[4]; // left motor

 int m2Speed = dirArray[motordata[5]] * motordata[6]; // right motor

 md.setSpeeds(m1Speed, m2Speed);

 

Bluetooth connection on Arduino board:

Their Bluetooth chip (HC-06) was connected on the previous pathfinder’s custom  PCB. In the code, the ports that the Bluetooth chip is reading on the Arduino board was the serial port 2. This means that the Bluetooth chip need to be connected to the RX2 and TX2. Since the chip was on the PCB, we couldn’t tell if it was connected to the right port and so we decided to disconnect the PCB and jump wire the Bluetooth to the ports using a breadboard instead.

 

Conclusion:

Another error came into factor when we still couldn’t get it to work. The other error was that the batteries were low and couldn’t run the motors. So we charged the batteries and after doing all the debugging and rewiring, we finally got the arxterra app to work via bluetooth. We made the pathfinder move using the remote control mode. The things we learned were to not expect the codes to work right away. We had to learn how the commands were transferred through the app and how it was decoded. We had to assume the bluetooth chip was not connected to the RX2 and TX2 pin because we couldn’t tell if their custom PCB was working properly. In the end, we were able to get the Bluetooth connection to work with the Arxterra App.

 

Source Materials:

http://arxterra.com/control-panel/  

https://www.youtube.com/channel/UCJXZGMpv8GqxkOi6W02GzoQ

https://github.com/arxterra

http://arxterra.com/pathfinder-axterra-gps-communication-part-three/

https://www.arduino.cc/en/Guide/Libraries