Pi Zero Drone: Part 4

Quad Zero Post #4: Calibrations

              In-between post there have been multiple snags in getting the quad copter in the air. Each are listed below in order of headaches:

1.       Power Sources: I would like to thank Ohms Law to convincing me that overloading the Pi Zero with too much voltage will indeed fry the voltage regulator. This will cause the PCB to smoke and make your board useless. DO NOT CONNECT THE POWER MODULE AND THE 2A POWER SUPPLY AT THE SAME TIME. I blame my lack of attention and ignorance for this mistake. My solution is to order a new Raspberry Pi Zero but in the mean time I will continue the build using a Pi 2 B+. This does have its advantages in more CPU power and faster processing. I will like to compare the two computers for future builds.

2.       ESCs: My original ESCs were HiTech 18Amp with no BEC power connection which became important in powering the ESCs for ultimate control. I then traded them for 12A Afro ESC.

3.       Wi-Fi Dongle: This part of the project had me researching network protocols and taught me a lot about specific IEEE protocols that help me pick the appropriate adapter. Because of the Wi-Fi hotspot on the PXFmini emitting a 5 GHz band and my failure of creating a similar frequency band, I choose Netgear AC600 Dual Band wireless AC adapter. This adapter is capital of emitting 2.4GHz and 5GHz frequency band.

Once these changes were made the Wi-Fi hotspot from the PXFmini was visible and I was able to connect using APM Mission Planner 2.0. Once the connection was made the accelerometers and gyroscopes were active and receiving positioning from the quadcopter.  Steps to configure the copter along with the radio controller and ESC can be found on the link:

http://ardupilot.org/copter/docs/configuring-hardware.html

Rotor Direction:

              To successfully control the quadcopter the Rotors have to spin in two different directions (Clockwise – C & Counter Clockwise – CC.) The figure below indicates what motors spin in the desired direction. 

 To test this without the propellers attached, I placed small sticker tabs on each rotor and determined the rotation. To change the direction switch any two leads and double check the direction. Now is time to test!

Michael Perry

Virtual Reality R/C Car: Part 5

There are a couple of parts of this project that I am currently trying to tie together but am not quite there yet on each of them. The three things that I have been working on are running the Atmega328P micro-controller without the jump board, changing the R/C Car being used, and integrating the head tracker with the rest of the project.

Changing out the R/C cars has actually been in the making for some time now. The 3D printed truggy had been in the shop when I got here but was not functional. The first issue that I had while working on this car was the differential gears that were make out of PLA the mesh was tough to get right and I had some problems with parts breaking. To fix this I decided to order metal parts for the drive train. I got this idea from a great thing on thingiverse here is the link:

http://www.thingiverse.com/thing:162810

I printed the extra parts, mainly the pinion and spur gears, out of Hatchbox PLA. Soon after the car got a new set of electronics. The motor and ESC that I am currently using are the Traxxas Titan 12T DC motor and the Traxxas XL-5 electronic speed controller. This set up worked temporarily but the spur and pinion gear failed quickly here is a video of the test below.

Since they failed so quickly I decided to try ABS instead. Here is a picture of the new spur and pinion set up.

And here is a picture of the new center differential. These gears should be able to hold up much longer than their PLA counterparts. However some part of the drive-train seems to be sticking. I still need to investigate this issue further. 

The next part of this project that I want to talk about is running the Atmega328P chip without the Arduino board. This is what will allow for a printed circuit board to be made for the receiver and transmitter in the future along. This should make the entire design more sleek and durable long term. To do this I started out following the tutorial for using the Atmega328P chip standalone found on Arduinos website. Here is a link:

https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard

This is basically a way to run the micro-controller on a breadboard by itself while using the arduino only as a power source and FTDI programmer. The tutorial also explains how to burn the bootloader using the ArduinoISP to burn the firmware. This process allows the chip to understand the code that you write in the Arduino IDE on your computer and upload to it.  However, this tutorial did not work for me. I was double and triple checking my wires but nothing seemed to work. In the tutorial it says to select either the Nano or Duemilanova board and then select the Atmega328P option. While doing this the IDE would try to upload the code but eventually time out while trying to connect to the chip. The way that I fixed this was by selecting the Uno/Genuino as the board and then uploading as usual. I am not sure if the tutorial is just wrong or if the board selection that they recommend would work if you also flashed the bootloader using the ArduinoISP. Here is a picture of the working set up.

In this picture I was just testing to make sure I could upload code to the chip and turn on an LED. This will eventually just be the power LED on the board. The connections to the board are Tx and Rx for programming and 5V and GND to power the chip. 

After I figured this out the next move was to prototype the entire system on a breadboard and have it run totally independently. While doing this I also want to integrate the head tracker and pan/tilt/roll camera mount. I have most of the receiver and transmitter wired on a breadboard here are pictures of the two. 

Receiver Circuit

 Transmitter Circuit

I still need to rework the code before testing these two circuit. The main three changes that need to be made are adding one part of the IMU code to the transmitter, the other part to the receiver, and redo all the pin numbers in the code. The reason i have to redo all the pin numbers is because the pins on the standalone chip do not exactly match up with the software. The way that I tell which pin is which is this diagram:

This diagram is really a lifesaver when it comes to working with the UNO it lets you easily see the multiple uses of each pin.

The Pi Zero Drone Part 3: Connecting the PXFmini

Pictured below is the setup of the PXFmini RPi-0 shield. You can notice the lead pins go straight into the Pi and must be shouldered to ensure a good connection.

The PWM output pins will be used to connect the ESC and rotors. From the Erle Robotics website the diagram of the connections are pictured below.

 

There are also multiple ways to power the controller, I used a Power Module that plugs into the power port on the shield. Power from the lipo is used to power the board as well as the ESC. When I am developing language on the Pi’s terminal, I use a 2A power supply into the power port on the Pi. Both cases are shown below. 

To connect using a RC transceiver, the 9^th pin is PPM enabled, that is Pulse Position Modulation. This allows multiple PWM signals to be used using one input. If you take a look on the previous post you can see the connection pins schematic, I used this to connect the ESCs. With the vast number of radio controllers at the Boca Bearing Workshop, not one is PPM enabled. Any of the controllers can be used if a PPM encoder is used to convert the PWM signal to a one wire PPM signal. These are cheap and easy ways to use any radio controller that you are comfortable with.  To date, I am still waiting on my encoder and once it comes in I will post a video of everything connected with a flying quadcopter. 

Virtual Reality R/C Car: Part 4 Adding The Head Tracker

After some testing, we realized that only looking forward is very limiting. Almost everyone who drove the car was tilting their head one way or another in order to try and look around. After doing a little more research on Fatshark's Trinity Head tracking Module I realized that it would be easier to just use another IMU. This was because the trinity is meant to be used with one of the store/online bought R/C remote controllers. However I did order a roll, pan, and tilt camera mount for the FatShark 700L CMOS V2 Camera you can find it here:

http://www.getfpv.com/fatshark-pan-tilt-roll-camera-mount-servos.html?utm_source=google_shopping&m=simple&gdffi=747627bc7e464db68e5f529d971aacf3&gdfms=5072B314B330484BA513E58972DCB359&gclid=CKGevMjpos4CFQsehgodZjQPjA

After looking around online for a bit I chose to use Adafruit's 9DOF IMU Breakout board. You can find it here:

https://www.adafruit.com/product/1714

Adafruit has lots of documentation on all their boards and that makes it much easier to use their products. Once we got the board the next step was to get it hooked up and to learn how it worked. Some information about how to connect the board can be found here:

https://learn.adafruit.com/adafruit-9-dof-imu-breakout/connecting-it-up

Basically what that page translates to is this:

Arduino            IMU
5V        <<-->>  Vin
GND    <<-->>  GND
A5        <<-->>  SCL
A4        <<-->>  SDA

Also I connected pins 3, 5, and 6 to the signal pins of the pan, tilt, and roll Servos on the camera mount.

After I connected everything up it was time to start downloading libraries and putting the test code together. I found all my information on how to set up the code for this chip from here:

https://learn.adafruit.com/adafruit-9-dof-imu-breakout/software

The key thing is that you have successfully downloaded all four of the libraries they mention in the articles above. The LSM303DLHC and L3DG20 libraries are there to read the information from the gyro and accelerometer/magnetometer. The unified sensor library combines all of this information and the 9DOF library makes this information extremely easy to interpret. On Adafruit's Github they even have an example sketch to help get you started which I have adapted to print some more debugging information and to control the servos. This code that I used to test both the IMU and the camera mount can be found on my Github here:

https://github.com/lukebocabearings/VRRC/blob/master/IMU_TEST

And a video of the code in action:

So now that I know how to use the IMU to control the camera mount the next step will be to add the IMU to the board to the transmitting Arduino connected to arcade motorcycle and to add the camera mount to the receiving Arduino on the car. Also I want to make the step towards running the ATMEGA328p micro-controllers totally separate for the Arduino boards. This will help make the wiring cleaner, the design more durable, and also with the help of CircuitMaker (a PCB design software) the design easier for anyone to recreate. Here are the schematics that I have drawn up to include the IMU and servos for the camera mount.

Receiver Diagram

Transmitter Diagram

Racing Power Wheels Part 11: Fixing the Caster for Stable Steering

So the next thing to work on was fixing the instability of the steering at high speeds. After doing some online research on steering geometry, I found that the caster plays a very important role in the stability of a vehicle. The current caster of the Power Wheels had negative caster. Negative caster is when the kingpin is leaning forward at the top. Below is a picture of the negative caster on the Power Wheels.

Below is a diagram of positive and negative caster that I found online.

Negative caster causes a vehicle to become unstable at higher speeds while positive caster causes a vehicle to be more stable at higher speeds. But having too much positive caster can cause the Power Wheels car difficult to steer at higher speeds. The current caster on the Power Wheels has a caster of -7 degrees. I measured it by using a level as my vertical axis and measuring the angle of the spindle bracket from the level. From doing some online searching, I found that a good amount of caster is +10 to +15 degrees. These numbers were for gas powered go karts. I found most of this information from diygokarts.com. There I found caster can be generally set to 10 to 15 degrees of positive caster.

The Pi Zero Drone Part 2: Construction of the Frame

With the correct thrust calculations from the Gartt 2300KV motors being done. I can now begin the design of the quadcopter. I would like to include that I have no real quadcopter experience other than cheap micro-copters and have spent a lot of time breaking props and arms with those. Any information from design has been from online sources in forums and experience in engineering projects from classes and extra-curricular clubs. This would be a great build for anyone excited about learning new skills and not afraid to break a couple of plastic parts along the way.

Virtual Reality R/C Car Part 3

So the next step on this project is really what sets this project apart from your typical R/C build. In order to make the driver feel like they are actually driving the car we added a FatShark FPV system to the car. In order to mount this system on the car I created a self contained box for the radio receiver, small LiPo battery, and the FatShark camera. If you have a 3D printer and a FatShark set up at home here is a link to the STL Files:

http://www.thingiverse.com/thing:1683678

Here is the case assembled and mounted on the car:

To put the case together I used 4 2.5mm screws and two #10 x 5/8 screw and nuts. I purchased the on/off switch from amazon at this link:

https://www.amazon.com/Yueton-Blovess-Rocker-Toggle-Control/dp/B011U1NU90?ie=UTF8&*Version*=1&*entries*=0

The goggles that we are using for the system are the FatShark Teleporter Model. Which work pretty well. The main drawback of the setup currently is that the camera is fixed facing forward on the car. While driving you want to be able to look around. Its kind of like trying to drive a car that only has a windshield. It works but it does not feel totally intuitive. In the future I would like to add some sort of moving camera mount that follows the head motion of the driver. Either with an accelerometer, two servos, and an Arduino or with some technology from FatShark. I know FatShark makes a Trinity Head Tracker Module so this may be a good route to go.

Also I have made a slight change to the code as well. The car now has two modes determined by the position of a switch. There is Easy Mode (Shown above) and Sport Mode. The difference is in easy mode the cars speed is limited. However in sport mode the more you turn the throttle the faster the car will go. It is harder to control that way but once you get used to it, it is very worth it. I will post a video soon of a test of this change. I have Highlighted the changes I made in the code to do this below:

#include <SoftwareServo.h>
#include <SPI.h>  
#include "RF24.h"


RF24 radio(9, 10);
SoftwareServo steering;
SoftwareServo gogojuice;

byte addresses[][6] = {"1Node", "2Node"}; // These will be the names of the "Pipes"

struct dataStruct {
  unsigned long _micros;  // to save response times
  int throttle;          // The Joystick position values
  int handBreak;
  int bikeTilt;
  bool pushButton;          // The Joystick push-down switch
} myData;                 // This can be accessed in the form:  myData.Xposition  etc.        


void setup()  
{
  Serial.begin(115200);  
  pinMode(6,INPUT);
  pinMode(3, OUTPUT);
  pinMode(5, OUTPUT);
 
  radio.begin();          // Initialize the nRF24L01 Radio
  radio.setChannel(108);
  radio.setDataRate(RF24_250KBPS);

  radio.setPALevel(RF24_PA_HIGH);

  // Open a writing and reading pipe on each radio, with opposite addresses
  radio.openWritingPipe(addresses[1]);
  radio.openReadingPipe(1, addresses[0]);

  // Start the radio listening for data
  radio.startListening();
  steering.attach(3);
  gogojuice.attach(5);
  gogojuice.write(40);
}


void loop()  
{
  if ( radio.available())
  {
    while (radio.available())   // While there is data ready to be retrieved from the receive pipe
    {
      radio.read( &myData, sizeof(myData) ); // Get the data
    }

    radio.stopListening();                     // First stop listening so we can transmit
    radio.write( &myData, sizeof(myData) );    // Send the received data back.
    radio.startListening();                    // Now resume listening so we catch the next packet
  }
    double Mode;
    if (HIGH == digitalRead(6))
    {
        Mode = 0.01;
    }
    else 
    {
        Mode = 0;
    }
    SoftwareServo::refresh();
    int drive;
    int bikeTiltRecieved = myData.bikeTilt;
    int handBreakRecieved = myData.handBreak;
    int throttleRecieved = myData.throttle;
    int tilt = map(bikeTiltRecieved, 0, 1023, 0, 180);
    if (throttleRecieved > 100 && handBreakRecieved < 100)
    {
      drive = 96 + throttleRecieved*Mode;
    }
    if (throttleRecieved < 100 && handBreakRecieved > 100)
    {
      drive = 85;
    }
    if (throttleRecieved > 100 && handBreakRecieved > 100)
    {
      drive = 90;
    }
    if (throttleRecieved < 100 && handBreakRecieved < 100)
    {
      drive = 90;
    }
    steering.write(tilt);
    gogojuice.write(drive);
    Serial.println(drive);
}