Progress

 ^{* updated} 

26.08.15 - Updated communication Protocol

We changed the Signals that were sended to the Quadcopter from chars to bytes, to make sure that a probable bit-switch wont lead into a wrong command but just into an empty one.
We developed 12 different bytes that distinguish in at least 4 bit to get as much reliability as possible.

The new communication signals are the following:

23.08.15 - Remote switch implementation

Following the latest crash results, I think we should talk about some remote power-off function. Unfortunately I don't know in detail how to do something like that.

What I found out is that you can control some power circuit with a relay (see Wikipedia or Elektronik Kompendium). Maybe we can combine a relay with a remote switch or buy a built together remote switch like:

http://www.conrad.de/ce/de/product/130428/Funk-Sender-Empfaenger-Set-433-MHz-AM-Baustein-Sender-3-12-VACDC-Empfaenger-5-VACDC-Reichweite-max-30-m/?ref=detview1&rt=detview1&rb=2

or 

http://www.pollin.de/shop/dt/MjE0OTQ0OTk-/Bausaetze_Module/Bausaetze/Sensor_Funkuebertragung.html

or 

http://www.amazon.de/Anself-Wasserdicht-Intelligente-T%C3%BCrklingel-Reichweite/dp/B00P0GNDV2/ref=sr_1_5?s=ce-de&ie=UTF8&qid=1440276700&sr=1-5&keywords=funk+t%C3%BCrklingel+batterie

It would be great, if we'd discuss this topic together. 

22.08.15 - Old bootloader

According to a blog entry on http://www.desert-home.com/ the Arduino Mega 2560 had two fatal errors in it's bootloader, which came up, when using the exclamation marks like "Good Job!!!" somewhere in the code and when using the watchdog library. It is pointed out that there exists a new bootloader, which needs to be burned on the Mega. 

For the new bootloader, see the official git repository.

For using a seperate Arduino for burning the bootloader over the Arduino IDE there is a good article on Sparkfun.

Interesting pages for understanding the watchdog library are http://www.megunolink.com/... and http://www.nongnu.org/...

14.08.15 - Experiment

Start:			Attendees:
End:			apo	fma	lan	lpe
Protocol:	fma

Click here for details...

31.07.15 - Update: Potentially wrong potential

While working with different electronic devices, one has always to make sure, that all grounds are the same. 

Not knowing about this, we had some wasted hours today, trying to find out, why all of our sensors messed up their values. 

The problem was, that the sensors were powered by the quadcopter battery while the microcontroller was powered via USB by the computer, which itself ran on it's battery. To make the buildup work, we needed to make sure, that the microcontroller was also powered by the quadcopter battery and only the TXD and RXD pins werde connected to the computer. 

27.07.15 - Update*

After a long day of tinkering, everything is wired up and all 10 ultrasonic sensors are ready to be used (hopefully).

After three of the sensors were not working with the Arduino Nano, using all 8 analog pins and all 12 digital pins for the 20 connections (1 trigger pin and 1 echo pin per sensor), we found out, that the analog pins 6 and 7 can not be used via digitalWrite or -Read but only used for analogRead. By changing the order of the wires we will get around this problem. 

Update:

Unfortunately the reordering of the wires is not expedient. It is not possible to use the analogRead function for a proper signal determination in time. 

The next approach of rewriting the NewPing library for making it able to trigger two sensors at once and then wait for the two echoes on separate pins also didn't work because the Arduino Nano doesn't seem to be able to hold the 5 volts trigger signal reliably on both sensors' trigger pins.

This this leads to the final alternative of replacing the Nano with two Arduino Pro Minis, which have together enough pins to read out all sensors and to communicate with the Arduino Mega. As a side effect we will be able to get sensor data twice as often as with only one controller, because the waiting time is halved.

Updates coming...   

19.07.15 - Experiment

Start:	10:00		Attendees:
End:	12:00		apo	fma	lan	lpe
Protocol:	fma

Click here for details...

09.07.15 - Update: What needs to be done

Currently there is a big blocker in our way to success - we cannot fly, until the rotor protectors have been printed and the 3D printer is not printing due to an unknown error. Last stabilization approaches have been more or less successful but without any protectors we will ruin another motor, as we have already.

This is a small overview over the current tasks and their dependencies:

09.07.15 - Progress Simulation and Emergency Systems

Today, an important part of the simulation was added: The Distance Sensors!

Though...they are quite poor. I used a lot of approximations and simplifications, but they are still usable. It should be possible to effectively test the quadcopter to avoid crashing into walls. Hopefully. I won't go into detail of what I approximated here, but will go into that at a later date, when I explain the whole simulation in greater detail (soon! I promise).

On the other hand the communication has been updated and should work properly (haven't really tested it yet, but I see no reason why it shouldn't work anyways).  I will have to implement everything into the Arduino code soon, but I will need more help with the interfacing (as posted above).

30.06.15 - Added Direction Control

Today the current code was updated in the way the bluetooth commands were added so it is possible to give the quadcopter commands to fly in a given direction.

These commands require a fully functional PID controlling for all three axis.

Further I have found the Problem with the Bluetooth connection via smartphone. if the screen blacks out the bluetooth connection gets killed with the string Bluetooth Terminal disconnected. The 'e' character in this string ends the motors. Solution for this has to be found.

26.06.15 - Current Situation

Today we worked on the balancing of the quadcopter. It worked rather well (I think), and after some testing, we got values of about P = 0.055 and D = 0.057. The I-value is currently at 0.05, but we have no idea how to properly adjust the I-parameter. The quadcopter is flying rather stable, but is drifting to the sides quite heavily (probably I-parameter?).

We have not yet touched the yaw-values, since we were quite paranoid about crashing the copter and Steven wanted us to be more careful with the copter. He offered us to maybe try and fly the copter in more open spaces (i.e. the lobby), but only after 6 and with his (or Christians) supervision. Before doing that he wants us to have a safe landing mechanism though (as in: not complete shut off of the motors, but a slow descend - values of about 180-182 should be sufficient, dont know if Steven wants exactly that, but that is what I collected from talking to him).

Steven also emphasizes again, that we need more spare parts, if something goes awry! Maybe we should order more Motors or a new Frame for Steven. He also had the idea of soft buffers for the feet so the landing isn't as hard.

25.06.15 - Meeting

Start:	16:00		Attendees:
End:	17:30		apo	fma	lan	lpe
Protocol:	lpe

Click here for details...

10.06.15 - Simulation: Problems with variables

There were unknown variables for a few weeks in the simulation. Namely the drag coefficient, the lift coefficient and the inertia of the quadcopter body. No real solution has been found as of yet.

One the other hand, the simulation is pretty much finished. The movement of the quadcopter works as intended (if the unknown variables would be known). There is still uncertainty about the output though. It is important to know, if the output of the acceleration has to be in the direction of the body frame of the quadcopter or the direction of the inertial frame (in the direction the copter is nudged or the xyz-direction of the room the copter is in).

A missing feature is some form of object distance measurement (putting the copter into a virtual room and outputting the distances to the walls). This will hopefully be acomplished within the next week.

As for the missing variables, here is some information gathered which might help:

Inertia:

"What do you think of reducing the quadcopter to a spheric point mass with 4 point masses located distance l from the centre. So basically Ixx=(2m(r^2)/5)+2m(l^2),Iyy=(2m(r^2)/5)+2m(l^2) and Izz=(2m(r^2)/5)+4m(l^2). I was suggested a paper written by Randal Beard. This is how he calculates its. I cant actually do it experimentally because I need to simulate it before building."

-> http://www.engr.colostate.edu/~dga/mech324/Labs/Lab%2010/images/moment%20of%20inertia%20table.jpg
-> http://de.wikipedia.org/wiki/Tr%C3%A4gheitsmoment

Lift Coefficient & Drag Coefficient:

C= (L/A_l)/(0,5*p*V²)

mit     L  = Lift Force

    A_l = cross sectional area of the airfoil

    p  = Air density

    V  = wind speed

D = (D/A_d)/(0,5*p*V²)

mit     D  = Drag Force

    A_d = effective area of the airfoil in the drag direction

Source: http://mragheb.com/NPRE%20475%20Wind%20Power%20Systems/Aeorodynamics%20of%20Rotor%20Blades.pdf

Another nice read: http://www.technik-consulting.eu/Analyse/Quadrocopter.html

Yet these two formulas might not even help since both papers I'm currently working with say that the constants in their simulations are only dependent on the lift coefficient and the drag coefficient.

Theses my work is based on: http://num.math.uni-bayreuth.de/de/thesis/2014/Hoeger_Matthias/BA_Matthias_Hoeger.pdf and http://sal.aalto.fi/publications/pdf-files/eluu11_public.pdf

03.06.15 - Update: The Ultrasonic Problem

Measuring distances with an ultrasonic sensor poses an unexpected challenge - dealing with the speed of sonic.

02.06.15 - Update: First Movements

28.05.15 - Meeting

Start:	16:00		Attendees:
End:	17:00		apo	fma	lan	lpe
Protocol:	fma

Click here for details...

21.05.15 - Meeting

Start:	16:00		Attendees:
End:	17:00		apo	fma	lan	lpe
Protocol:	apo

Click here for details...

13.05.15 - Update*

For providing the ability of using the real sensors and actuators as well as the simulation to test the quadcopter, we decided to use some interface, which can both, communicate with the hardware or with the simulation.

Update (16.05.15):

A basic Arduino Sketch with description is published under the Software section, outlining all current challenges of the projects code.

12.05.15 - Update

Since the components are shipped with an unknown arrival date and for testing the interaction of the different sensors and actuators we will build an Arduino Lego Mindstorms setup on three wheels.

The NXT will therefor provide some basic navigation functions like goForwards, goBackwards, rotateRight, etc., as the software for basic flight is going to do later, too, and control the motors accordingly. The Arduino will be connected to the rest of existing components as usual. 

An NXT block is generally able to communicate over I²C as master to any slave device, for instance the Arduino. Via simple looped polling the NXT can ask the Arduino for drive commands.

To connect the Lego block to the Arduino a Mindstorms NXT cable is ordered, which will be cut open and linked to the microcontroller. For further understanding about wiring and I²C the LEGO MINDSTORMS NXT Hardware Developer Kit.pdf gives a good start. In addition the webpages of leJOS News and Dexter Industries seem to be quite helpful and even give some basic code example. Further information following...

11.05.15 - Update*

Ultrasonic sensors and bluetooth bridge have been delivered. Communication with Arduino is working.

Code:

/*
 * code partly from http://www.robodino.de/2011/12/ultraschall-distanz-sensor-hc-sr04.html
 */ 
 
#define trigPin 31
#define echoPin 33
 
void setup() {
  Serial.begin (9600);
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
}
 
void loop() {
  long duration, distance;
  // To trigger the sensor a 10us HIGH signal is needed.
  // Create definite LOW for 2us 
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  // Give it a HIGH for 10us
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  // LOW again
  digitalWrite(trigPin, LOW);
  // Measure the pulse width of the incoming signal
  duration = pulseIn(echoPin, HIGH);
  // Calculate the distance with given function
  distance = (duration/2) / 29.1;

 
  if (distance >= 400 || distance <= 0) {
    Serial.println("Out of range");
  }
  else {
    Serial.print(distance);
    Serial.println(" cm");
  }
  // Wait a microsecond to start again
  delay(1);
}

/*
 * code partly from http://www.arduino-hacks.com/adding-bluetooth-capability-project-arduino-hc-06/
 */
 
char blueToothVal;           
 
void setup() {
  // Start a bluetooth connection via Serial1 ports
  Serial.begin(9600); 
  // User the LED on pin 13
  pinMode(13,OUTPUT);
}
 
void loop() {
  // If data over Serial1 are received
  if(Serial.available()>0) {
    // Read the data
    blueToothVal=Serial.read();
  }
  // If the data equal the letter 'n'
  if (blueToothVal=='n') {
    // Switch LED on
    digitalWrite(13,HIGH);
  }
  // Else if the data equal the letter 'f'
  else if (blueToothVal=='f') {
    // Switch LED off
    digitalWrite(13,LOW);
  }
  // Wait 100ms
  delay(100);
}

#define trigPin 31
#define echoPin 33
char blueToothVal;
 
void setup() {
 Serial.begin(9600); 
 pinMode(trigPin, OUTPUT);
 pinMode(echoPin, INPUT);
}
 
long getDistance() {
  long duration, distance;
  digitalWrite(13,HIGH);
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  duration = pulseIn(echoPin, HIGH);
  distance = (duration/2) / 29.1;
  
  if (distance >= 400 || distance <= 0){
      distance = getDistance();
  }
  
  return distance;
}
 
 
void loop() {
  
  if(Serial.available()>0) {
    blueToothVal=Serial.read();
  }
  if (blueToothVal=='x') {
    Serial.print(getDistance());
    Serial.println(" cm");
  }
 
  // Reset blueToothVal to any letter but 'x'
  blueToothVal = 'c';
  delay(100);
}

The bluetooth module is found on the MacBook Pro as HC-06 in the list of available bluetooth devices. A connection can be established with Code '1234'.

Unfortunately the MacBook does not reconnect automatically after reset of the Arduino. The bluetooth module has to be unpaired and paired again to be usable again. Hopefully this will can be fixed somehow...

Update:

A much easier way of connecting via bluetooth is to use the Arduino Serial Monitor (Tools -> Serial Monitor).

It is now clear, how the module is handled by the MacBook Pro. Once paired, the HC-06 is always shown in the list of bluetooth devices as 'Not connected', unless an explicit connection is established. Establish a connection with a screen or the Serial Monitor. Once the connection is closed, HC-06 will be shown as 'Not connected' again. It is important to notice that the previous screen method has to be killed explicitly, not only closed, since there can only be one serial connection at once.

08.05.15 - Proposal Presentation

07.05.15 - Meeting

Start:	16:00		Attendees:
End:	18:00		apo	fma	lan	lpe
Protocol:	lan

Click here for details... 

30.04.15 - Meeting

Start:	16:00		Attendees:
End:	16:40		apo	fma	lan	lpe
Protocol:	lpe

Click here for details... 

26.04.15 - Meeting

Start:	17:30		Attendees:
End:	21:00		apo	fma	lan	lpe
Protocol:	fma

Click here for details... 

23.04.15 - Meeting

Start:	17:30		Attendees:
End:	18:30		apo	fma	lan	lpe
Protocol:	lpe

Click here for details...

23.04.15 - Meeting

Start:	16:00		Attendees:
End:	17:30		apo	fma	lan	lpe
Protocol:	lpe

Click here for details...