Hi

I finished my frame desing, then I have a few frames for sale

I'm writing about frame like in this video with a small modifications:
http://www.youtube.com/watch?v=eRSUOPCX_Is

Here is my child

More photos see bottom of page

Motor 2 motor distance <> 61cm - 24inch.
Weight <> 290g - complete frame without plastic box, motors etc.
Arms made using painted auminium 8x12x1mm profile.

Frame is very easy to fold - it takes only one-two minuts.
You dont need to disconnect anything during this operation
(only unscrew this four screws visible on next photos!)
After folding frame lenght is only 43cm!

Price - 65USD with free shipping everywhere!*

In this price are:
- center boards,
- four arms (three black, one red),
- four legs,
- four "motor savers",
- LiPo holder with velcro,
- all arms with drilled holes for motors like Emax 2822,
- all needed screw and nuts.

You will get frame partialy mounted - arms conected to
central boards, with LiPo holder.

In this price are not included:
- plastic L&L box for control board.

You will get free!:
- two spare legs,
- two spare "motor savers",
- one spare BLACK arm - needed if you will broke one
- one spare RED arm - if you will want to fly X mode,
- a few spare screws etc.

You will not get for free:
- plastic box for control-board (you can use CD box etc),
- motors, ECS, control board, LiPo...

You can add to your frame:
- plastic L&L box like on photos - only 5USD,

You can also pay for faster parcel (free is economic, registered letter):
Additional fees for priority parcel:
- Europe - 3USD,
- Nord America - 5USD,
- Central and South America - 7USD,
- Australia - 14USD (sorry ).

Payement by PayPal. Will be sent 1-2 days after.

If you want to buy one PM me.

If you want to buy more than one - for your frend for
example PM me I'll make you better offer.








Jakub

I have an error when I try to write the efuse or (the extended fuse). i am using avrdude and an Atmega48P. This is the error I get: verification error, first mismatch at byte 0x0000 0xff != 0x01

Anyone have any ideas?

Well I tried the clock test anyways and....... SUCCESS!!!! It worked and was right the money for every time it went on and off. Now to finish my frame.

Originally Posted by ben123

The finished kkquadrocopter is 22cm motor to motor (can be adjusted) and exactly 70g with a 500mah lipo.

sounds great Ben! Sound like something good to fly indoor . What motor are those?

Thanks

thanh

Originally Posted by ben123

The finished kkquadrocopter is 22cm motor to motor (can be adjusted) and exactly 70g with a 500mah lipo.

70 grams....thatīs an acheivement!

What motors and ESCīs you use - looks like stripped 6A plush....looks like you also hardwired the RX?

2 or 3S ?

Lets see a video when you get it dialed in....

Nice work!

hi,

i made a new layout for the smd pcb. its much better to solder if u are milling the board. and there are less drills. put the most parts to bottom. only the needed on top (led, poti etc.)

i rotated the hole thing for 45° to get it better on a tricopter. so the front is where the yaw gyro is placed. there are still 6 motor connectors for quad and hexacopter.

what are thinking about?

Thanh:

The motors are these ones :

http://www.hobbycity.com/hobbyking/s..._Weight_3700Kv

After work I swapped out the 3020 props for 3030s. I got "lift off" with the 3020s at very high throttle so I thought the motors didn't have enough room at the top. The 3030s took lift off to much lower and it seems much more stable I got it to hover stably then pushed forward and it did a front flip hehe need to adjust the tx endpoints I think.

420RcPilot:

My controller board is made for 3.7v so its 1S lipo. The escs are only 0.7g and are these ones:

http://www.hobbycity.com/hobbyking/s...idProduct=9667

The rx is wired in under the controller and is hobbykings 6 channel rx with the case removed. Only around 6 grams then

Posting a video is next but it may only be it hovering and moving a bit as my next challenge is learning how to fly the thing

The IDG650 and IXZ650 have analog x1 and x4 outputs. Perhaps the mcu sends data on I2C.

Originally Posted by thanhTran

Sorry to hear that Pug! Too bad that it burned before it flew. I thought the clone Wii Motion Plus only supports I2C? So it output analog voltage as well?

Thanks

-Thanh

it works!

Quadcopter test -KKMulticopter (6 min 49 sec)

Mine flew a bit yesterday. :-)
- I've tied it down so that any glitches/control problems won't cause any problems.
- I still have some control problems. :-( Every now and then a motor goes full-blast for two seconds at a time. I've programmed my own mixer, and it seems I'm doing the PWM output differently from everybody else. I'll check out the hardware PWM. (in theory I have clock cycle resolution output 0.050us resolution, but if it doesn't work reliably....)
- I haven't taken apart the HK401b gyros. I've just put them inline with the pitch and roll controls.
- I haven't put in a yaw gyro yet.
- I've used my own development PCB instead of one of the designs here.

oh! It survived a crash without any damage: First test, before we knew it might have the control glitches, we held it by hand, and it was too strong...

All in all: More work to do, but in principle it seems to work... :-)

Hello,
I am starting to build the KKMulticopter controler.
I have already a few gyros seating arround. Does anybody know if the E-Sky EK2-0704B head Lock gyro (http://cgi.ebay.fr/EK2-0704B-Lock-Te...-/300346805884) is usable for this project?

Does anybody knows if the PICKit2 programmer (http://www.microchip.com/stellent/id...cName=en023805) will work to programm the Atmega 48 chip?

Thank you and have good flights.

No, the pickit programmer is not good for programming atmel chips. :-(

The suggestion in this thread is to take the gyro apart, and use the actual sensor element from the gyro. This depends on a suitable component being used. I don't know whether the linked gyro uses the same (or compatible) sensor as the HK401b.

Originally Posted by rewolff

Mine flew a bit yesterday. :-)
- I've tied it down so that any glitches/control problems won't cause any problems.
- I still have some control problems. :-( Every now and then a motor goes full-blast for two seconds at a time. I've programmed my own mixer, and it seems I'm doing the PWM output differently from everybody else. I'll check out the hardware PWM. (in theory I have clock cycle resolution output 0.050us resolution, but if it doesn't work reliably....)...

Maybe timer rolls around
Inspired by Kaptein's work, I'm also working on my own controller. So far 2 channels with hardware PWM outputs and 2 interrupt base input captures are working. I'm debating whether I should work on the leveling (accelerometer) adds on to KK controller first or should I aim for a 4 channel quad controller. It's been interesting & good experience for sure.

Thanh

Originally Posted by ben123

...
The motors are these ones :

http://www.hobbycity.com/hobbyking/s..._Weight_3700Kv

After work I swapped out the 3020 props for 3030s. I got "lift off" with the 3020s at very high throttle so I thought the motors didn't have enough room at the top. The 3030s took lift off to much lower and it seems much more stable I got it to hover stably then pushed forward and it did a front flip hehe need to adjust the tx endpoints I think.

..My controller board is made for 3.7v so its 1S lipo. The escs are only 0.7g and are these ones:

http://www.hobbycity.com/hobbyking/s...idProduct=9667

...

Thanks for the links to those little gems Ben! I'll be watching out for your video and then will build one little quad for sure. Last time I flew my quad in the office I made couple scratches on the wall

Here is my "4 channel" input code;

int          ts[4];
volatile int chan[4];

uint8_t chpins[4] = { 1 << CH1_BIT, 1 << CH2_BIT,  
                      1 << CH3_BIT, 1 << CH4_BIT};


ISR(PCINT2_vect)
{
  uint8_t newpins, d; 
  int t;
  uint8_t ii;

  newpins = PIND; 
  d = newpins ^ oldpins; 
  t = TCNT1;
  for (ii=0;ii<4;ii++) {
    if (d & chpins[ii]) {
      if (newpins & chpins[ii]) {
        // rising edge: store timestamp; 
        ts[ii] = t;
      } else {
        // falling edge;
        chan[ii] = t - ts[ii];
      }
    }
  }
  oldpins = newpins; 
}

The measured values in the "chan" array end up in clock cylces.

For "direct from reciever" these are likely accurate to one or two clock cycles. You can easily see the ADC in the transmitter jittering between two possible ADC values, giving readings about 1 microsecond apart (20 clocks!) with a jitter of just a few clocks of measurement error.

Now on the output side, I have:

int wait_for (int end)
{
  end += TCNT1;
  while ( (((int) TCNT1) - end ) < 0)
    /* wait */;
  return TCNT1 - end; 
}

....

    FRONT_HI ();
    wait_for (front);
    FRONT_LO ();

So we calculate the number of clocks the "FRONT" output needs to be high, and wait for the timer to reach that count.

Suppose we need to wait for 20000 clocks. Suppose TCNT1 starts out at 1000, we caculate end to be 21000, and so we wait as long as TCNT1-end is below zero. Or TCNT1 < end.

Now that was the easy case. When wraparounds occur, this still works! So when TCNT1 starts out at 23456, end comes to 43456, but in signed 16 bits, that comes to -22080. Now is TCNT1 (23456) < -22080? Apparently in my compiler: No (I expected it to be yes), but if we calculate TCNT1 - end, we get: 23456 - (-22080), or 45536, which in signed 16 bits is -20000! so less than zero, so the loop continues!

There are a few snags: Some things would be best to shield from interrupts. But that would corrupt the accurate input readings a bit. Hmm. On the other hand. shielding the input interrupts for several instructions is better than having an interrupt cause an output error of around 30 or 40 cycles!

Anyway, an interrupt occurring between the "FRONT_HI ()", and the end += TCNT (two cycles, because avr-gcc inlines the function!) would put the timing off a bit.

The return TCNT1-end allows me to keep track of the "residue". If the current pulse ended up 5 clocks too long we can shorten the next one by 5 clocks. I'm going to see if that causes the mishaps, so I'm taking it out of my current code version, and left it out in the sample above.

The left and right motors are tilted to allow yaw authority. Prop-torque causes the opposite yaw motion.

Oh one more thing. I upgraded to 20MHz yesterday ("up from 8" :-) ). So now 2ms pulse is 40000 clocks. That would negate my whole 16bit math trick. So now I wait for the 1ms "always" separately from the actual timer variation. It would be slightly better to do this in the "waitfor" routine: if ( end < 0) .... do something about it.