Bob, if you have the means to do that, buy a Spektrum radio which supports a AR6100 or AR6200 receiver and use the older Aeroquad code. It seems to me that more problems arose after the Aeroquad code was updated for use with any receiver and the 400Hz update rate. That's just my thought.

Wow bob, sounds kinda like your quad is haunted!

Just goes to show how awesome quads are though. Can you imagine the damage a heli would have caused to itself and you?

Originally Posted by saturnine

I have newer code, but again, it's far from finished, so you just use it to experiment with and toy with. While arming/disarming, motor driving, mixing, receiving, and the ACC module all work, it still lacks any gyro code (thus wouldn't fly well, if at all), so really it's use to you is educational only at the moment. I will post it a bit later.

Damon


"@Saturnine : could you put a zip of your up-to-date compiled code online, I would like to test it (unless it's the same you posted a while back)."

ok saturnine, understood, and thanks for the reply.

Originally Posted by kaldak

Wow bob, sounds kinda like your quad is haunted!

Just goes to show how awesome quads are though. Can you imagine the damage a heli would have caused to itself and you?

definately, and that's the exact reason why I decided to move my AP to a Quad.
Helis are far too dangerous to be flown anywhere else than remote open fields.

update about the crash damage, worse than what I first thought :
- 4 propellers
- 1 dome
- 1 CF arm
- 1 esc (but got fixed, wire got pulled off from board)
- at least 2 motors, probably three (they did not appreciate being slammed on the concrete from 20 feet high)

Arghhhhhh, gotta make a new order in Hong-Kong and pay lots of shipping and taxes (but still cheaper than buying here in France)

@Mikro : thanks for all the info
- I will try to use servotimer2 and see what happens with crackling noises and speedups
- I will try to put delay in the main loop if I ever find it, any clue to help me?
- about weight, are you saying that lighter Quad are more prone to drifting and instability?

Originally Posted by bob.titus

well, I tried a few times to point this out...since about 3 or 4 weeks now...

Hi bob. There is no way for us to know if your issues are due to the quad code or your Futaba radio untill someone else gets Futaba working as well. I figured your current issues were because of your Futaba radio untill I experienced similar results. Even if we experience similar results there is no way for us to know if your Futaba radio is amplifying the issues. Especially since we don't yet know exactly how you got it working good, assuming that it is.

Originally Posted by bob.titus

...but my feedback and questions remained completly ignored, I just got made fun of my poor troubleshooting

We must be reading different threads or I'm misunderstanding this as your questions have been continually answered and rather quickly from what I have seen

We are not making fun of your debugging abilities. It just makes helping you more involved and time consumming, with very little return for us sometimes, than there other wise would be. Just means we have to work with each other more without getting too frustrated too quickly.

I suggest going with the OMM/Spectrolutions board, UAVP, or MicroKopter, or TT copter if you need a "ready to fly" quad right away. You might be able to use your quaduino sensors on the UAVP sensorless board? Hope you stick with this project as well but it does require us to be able to sit back and enjoy the long development cycle at times.

Originally Posted by bob.titus

...
I could fly the Quad, it seemed more stable and docile than in "+" configuration, only a very slow oscillation at first, gradually increasing, but nothing too bad, so I decided to change the settings and landed the Quad gently in the meadow.

I went to my car, connected the Quad to the computer, changed the values, stored them and back to the track, a little road in the fields.

I put the Quad on the road, and armed the motors... they started to spin gently, and within a second, without me touching the throttle, suddenly went full throttle!!!!
....

Sorry to hear about the slice and dice flight you had At least you have possibly discovered one issue with the code, since changing the values may have affected the full throttle issue.

Were you able to write down all of the values you put into the quad for both of these flights so we can reproduce your results?

Originally Posted by bob.titus

I took a good look, and have a little problem : I don't speak german well enough to follow anything that is only in german...

This is the same reason I am following this thread instead of the others. It would be a real shame for me if this project went the same route as Paulrene's who is still gracious to offer his code to us on an "as is" basis but with no tech support of any kind.

Some of the others have english manuals and plenty of english build threads with people nice enough to help anyone out but it seams like you always run into some german specific stuff if you really dig into the code.

Originally Posted by bob.titus

...that's part of the game, I accepted it the day I joined the project, that was part of the deal...

Doesn't have to be if you tether that puppy in some way. Even if you want to fly in free flight, attach a very strong string or fishing line to the quad that is 5 feet long and attach the other end to some weights that the quad can't move. Stand back at least 7 feet and you should be good to go and crash all you want.

Originally Posted by bob.titus

...I chose this project rather than directly going to Mikrokopter, or Dammar at Spectrosolutions or TT copter or X-3D X-BL because this one was based on Arduino and was open source, with all the future upgrading possibilities and the thrill of experimentation and the satisfaction of doing it all almost by yourself... and because it was CHEAPER as well, let's face it ...

All good reasons which is why I'm here as well but R&D for such a project as this is almost never "cheap". I can taste it but we ain't quite there just yet.
----------------------------------------------------------

Originally Posted by rich smith

...PS Very important to freeze a stable design stage...Another problem is originators who don't bother to try their own code and hardware designs before release.

I'm giving Mikro the stink eye right now for not leaving the stable MikroQuad build around It would be cool to have a separate section in his repository for stable builds or a way for him to tag his builds as stable or works in progress if possible? Can't blame him really for the "testing before releasing code" thing much since it's not a full time project for him and he can only do so much testing himself. The testing phase is a great area we can all assist in.

Opps. Thought my last post was edited in this one instead of being in a new post

I'll use this post to invite people over to the new (Quaduino-Part2) thread. Editing the first page to future links sounds like good "high level" work that I can handle


It ain't ideal but I suggest this new forum be used for both continued AeroQuad tech support and general Quaduino talk. I'll do my best to keep it up to date to help separate the general talk from the tech support, fingers crossed Just keep the tech support condensed and to a minimum if possible. I suggest Mikros support forum be used if someone is really stuck and doesn't resolve there issues with in a few posts.

Originally Posted by Mikro

In regards to bob's troubleshooting woes, I spent nearly a whole afternoon on my cell phone trying to help.

Wow Personal tech support. That is seriously nice of you.

Originally Posted by Mikro

Hah! Figures you'd find a way to break the site...

That's what I'm here for It's working now. I just posted a link instead of copying the text.

Originally Posted by Mikro

To slow down the code, just put a delay() statement inside the main loop. Maybe try delay(10); first?

Cool. I'll report back.

Originally Posted by Mikro

I tested the AeroQuad software on the frame I have in the latest videos and it flies smooth as silk (well, maybe with some crackling in the background, heh heh).Now coming to think about it I've had similar issues, but just haven't had the time to troubleshoot...

Just to clarify, your getting the cracking noise and the full throttle issue? Or just the cracking noise issue?

If your getting the full throttle issue, your heavier quad may be dampening it, unless that's what you were talking about. I'll double check this but I recall my full throttle issues only happening for a brief second unlike others have reported but I need to double check that.

As I am waiting for the PCB to be frabricated, I started to look at coding some of the important modules. Here is a intial code for interrupt based ADC sampling.

I just wrote the ISR and initialization function. Currently the loop() function is empty. I have not yet tested this code with any sensor data. I don't have sensors with me right now.

I measured the timings and it takes about 256us if the system is running at 100Hz loop rate.

//Program that using ADC autotrigger capability to continously sample all the 8 channels.
//The Arduino default ADC sampling rate is 9615.384 Hz
//When sampling 8 channels the net sampling rate for individual channel is 9615.384/12 = 1201.92 Hz
//With a 100Hz control loop rate each individual channel will be sampled 12 //times with in the time period of the loop. Hence we have 12 times //oversampling. Which increases the ADC bit resolution by 1 bit.
//These 12 values are accumalated and put into output array adc_sample[].
//The ISR does not divide the result by 12 and get average value. Using the //accumlated value we get advantage of increased ADC bit resolution. 

/*************************************************************
//NOTE: the ADC results in the adc_sample[] will be 12 times larger than //normal Arduino analogRead() value.
*************************************************************/

int ledPin = 13;   // select the pin for the LED

void analogAutoTriggerInit(uint8_t num_samples);

void setup() {
  analogAutoTriggerInit(12);
}

void loop() {
  delay(2);                  
  //dummy loop doing nothing hear.
  //Read data from the adc_sample[] array and use it in processing. 
}


volatile uint16_t adc_acc[8];
volatile uint16_t adc_sample[8];
uint8_t adc_acc_cnt;
uint8_t adc_max_acc_cnt;
uint8_t adc_first_run;

extern uint8_t analog_reference;

void analogAutoTriggerInit(uint8_t num_samples)
{
	
	
	//Main initialization program enables a2d conversions.
	//disable it while setting up the Auto Trigger functionality
	ADCSRA &= ~(_BV(ADEN));
	
	//Set the reference voltage
	//Set the mux for first channel.
	//LSB 4 bits determine the channel, reset them for first channel
	//variable analog_refernece is from Arduino code base.
	ADMUX = (analog_reference << 6) | 0;	
		
	ADCSRA |= _BV(ADATE);	//Enable Auto Trigger
	ADCSRA |= _BV(ADIE);	//Enable Interrupt
	ADCSRA |= _BV(ADEN);	//Enable ADC.
	
	//initialize all the variables
	adc_first_run = true;
	adc_acc_cnt = 0;
	adc_max_acc_cnt = num_samples;
	for(uint8_t i = 0; i<8; i++)
	{
		adc_acc[i] = 0;
		adc_sample[i] = 0;
	}
			
	sei();			/* enable interrupts */

	/*
	* Start one conversion to set the ball rolling.
	*/
	ADCSRA |= _BV(ADSC);
	
	//Test stuff
	pinMode(ledPin, OUTPUT); 
}


/*
 * ADC conversion complete ISR.
 */
ISR(ADC_vect)
{
    static uint8_t ch = 0;
     uint8_t low, high;

	//to measure the execution time of ISR. Comment out for normal operation.
	PORTB |= _BV(PIN5);	
	
	if(adc_first_run == true)
	{//Entering the ISR for the very first time after reset or power up. This is special condition
	//and needs different handling. Note that ADC has already started the conversion for channel 0 again.
		adc_first_run = false;
		++ch;	
		//select the next channel     
	    ADMUX != (0x07 & ch);
	    //the next time ISR is triggered we would have result from channel 0 and conversion for channel 1 would 
	    //have begun. 
	}
	else
	{
		// we have to read ADCL first; doing so locks both ADCL
		// and ADCH until ADCH is read.  reading ADCL second would
		// cause the results of each conversion to be discarded,
		// as ADCL and ADCH would be locked when it completed.
		low = ADCL;
		high = ADCH;	

		//In normal operation if the ch == 2, currently ADC is sampling channel 2 and result from channel 1 is available
		//read the ADC value and accumlate/average.		
		if(ch == 0)
		{//special condition, when Ch == 0 the result present if from that of channel 7
			adc_acc[7] += (high << 8) | low; 	   
		}
		else
		{
			adc_acc[ch-1] += (high << 8) | low; 	   			
		}
	    
	    ++ch;
	    if(ch == 8)
	    {//finished cycling through all the 8 channels
			
	    	ch=0; //cycle back to first channel
	    
	        //increment accumlator count
			++adc_acc_cnt;
			if(adc_acc_cnt == adc_max_acc_cnt)
			{//Finished accumlating the samples, copy the value into output result array
				adc_acc_cnt = 0;
				for(uint8_t i = 0; i<8; i++)
				{
					adc_sample[i] = adc_acc[i];
					adc_acc[i] = 0;		//reset the accumlator register
				}
			}    
	    }
	    
	    //select the next channel     
	    ADMUX != (0x07 & ch);
	}       

	//to measure the execution time of ISR. Comment out for normal operation.	
	PORTB &= (~_BV(PIN5));
}

Ok, I'm closing this thread down so that talks can move over to RCvertt's new Quaduino-Part 2 thread. I think he'll be better able to keep the first post up to date than I've done.

Great thread guys! Thanks to everyone who has contributed here! Sometime in the next month or so I should have some info on my own project. It'll feature very low cost sensors, the Tx/Rx entirely replaced by data modems, and some funky matrix math for getting a better orientation out of the gyros and accels. Stay tuned!