Thanks a lot for your help! The battery pack is huge indeed, 484g :). But I’ve read about so many octo’s lifting around 1,2 Kg I thought if my lipo would be 200g heavier but could increase the flight time a lot I’d go for it (and I was actually hoping it could eventually lift 2… lol :-).
But you got a very good point. I’ll switch to the ZIPPY Flightmax 2200mAh 3S1P 45C (285g).
Tnx a lot for the ESC as well. I heard more about the plush, don’t know why I forgot that. I’ll switch to the TURNIGY Plush 30amp Speed Controller (do like the margin).
You really helped me out here, allmost made some big mistakes.
Looks like a good list considering the corrections realiser made. If you’re going to make your own frame that is probably not going to be ultralight at first, the only thing that worries me is the 750KV motors. Unfortunately, there doesn’t seem to be a lot of good data out there to give direction in the selection of motors/props/etc. in the construction of quads but what I found was that most quads the size I was planning to build were using 1020KV to 1400KV motors. I haven’t weighed my quad yet but I’m surprised at how heavy it is once I got everything together. My guess is it weighs in the 3-4 lb range. Building the frame to accept 8 motors accounted for a lot of that.
Regarding the batteries… Here’s my suggestion. If you’re doing this just a few hours a day as I am then once you get the structure together you’ll be spending the next few months in the “lab” with the quad secured somehow so you don’t destroy it while trying to figure out the balancing code. To make the most of your time you’ll need enough battery power to let you test as long as possible. So, I suggest you buy one of the larger batteries in addition to the smaller one. That way you have plenty of juice to keep you going. Of course, if you have a power supply to provide the power via cord while in the lab then this is not as much of a concern. I have a 4000mAH battery and another on the way. Later on when I’m happy with it’s ability to fly and I start phase 2 (putting it on a diet then I’ll probably buy some smaller batteries and see what kind of difference it makes.
has anyone had any progress with IMU/AHRS in managed code?
so far i’ve noticed severe drifting and sometimes completely missing readings from the sensors.
considering that you have to poll the sensors at a really high frequency im thinking of using an AHRS board. so i can use the domino for the fun part- staying on course and navigating to coordinates.
I found this today:
either rs232 or ISP communication. this is a device which keeps track of roll / pitch /yaw,
which is the intensive part to calculate.
im not giving up on AHRS algorithm completely done in managed code but it would be fun to get up in the air this year. it will be so cool seeing an170cm wingspan airplane hovering above the house, and then slowly transition into flightmode and do loops and rolls
I saw your post and it looks very interesting. If you want to make your own IMU software for pitch and roll, you should differently check out my guide: [url]http://arduino.cc/forum/index.php/topic,58048.0.html[/url]. It is based on Arduino, but you could easily port it to the FEZ Panda II
Anyway I think you will find it interesting, despite you might want to buy a IMU with a onboard microprocessor and algorithm.
Continued reading on the Mongoose… that thing is indeed great! And has altitude I don’t get from the wii motionplus. I’m switching to Mongoose in time as well (After Ianlee74 tested it out and still likes it :D). Too bad I need to get all of these parts from the US. Seems like the only place they still have fun stuff.
@ Cyberwaelder, I still think I can suspend the GC until it’s allowed to run. And hopefully build something that allows a bit slower loop. If it still fails I’ll use the FEZ for AI and switch to another board for the flying part. But I’m still hopeful.
@ Lauszus, TNX! I need to learn a lot more about these functions, so your code is really helpful and I’m sure I can implement it on the mongoose as well.
[italic]I did come up with two new stupid questions today:[/italic]
What should we do to implement a “fail safe?” I got a 850mAh lipo on my driving robot (actually 2, one for the engines and one for FEZ) and today while driving it ran out too much. Fez still active (led on), but it somehow crashed and set full PWM to the engines. If that also happens on my quad I’ll never see it again, including the mongoose and other expensive parts. Same could happen to my sender, if it runs out while flying and just made a “please fly up” command that would also raise some problems. Not onlu when running out, also noise issues etc. But implementing an entire standalone board as a “watchdog” to return it to ground if the Fez crashed seems like a bit overkill.
Would it be a real stupid idea to add a fifth engine / propeller in the center of the quad? Somehow not fixed but connected to a flexible cable (don’t know how to do that on takeoff / landing yet, but i´m still in the designing phase ;)). I guess this would create some extra lift and increase stability. Can’t really call it a octocopter anymore though.
One of the boards I read up on, I think Ardupilot, has a special pin on the accelerometer for a parachute. If it flips, it deploys the parachute without the processor being involved.
I am toying with the idea of having 1 mid propeller (counter rotating) and then using servos with weights to balance it with reverse pendulum effect. No idea if it will work. Adding a fifth prop won’t really do much to lift ability. What would be possible is one big mid motor for lift and 3 small motors for control.
@ Lauszus i’ve read that post a couple of months ago. it’s a really good starter!
@ mammaplank
first, your last question, adding a fifth motor wouldnt give it more stability.
your four motors, two CW and two CCW makes the quad stable around the Z axis (jaw) if you add a fifth motor, which lets say runs clockwise, it will create a counter clockwise drag which your other four motors will have to compensate for. with good enough software this isnt an issue. but considering your just beginning this journey i’d opt for as stable as possible. which in turn could be compensated by a sixth motor under it with a pushing prop going CCW, makes for a great lawn mower
question 1. You could measure each cell from the charging connector, if any cell drops below 3.3 volts it’s about to run out. google MicroScream, it’s a lipo alarm. im sure you can alter that and connect it to a pin on your FEZ
Not quite… The Mongoose also has magnetometer and more importantly has AHRS. The problem most people run into with quads on NETMF is not being able to loop the sensor data fast enough. I hope to avoid that problem using the Mongoose by allowing it to offload that high speed looping to a lower speed loop that has already been filtered. Motors are far less responsive than the sensors so it shouldn’t be necessary to update the motors nearly as often as you read the sensors in a fast loop system.
Unfortunately, my weekends keep getting consumed by others and I’ve yet to make much progress in proving this.
Thanks for the advice (again). Did you have some time to play with the Mongoose allready? Would love to read your progress, hope you get some time to play and hopefully blog about it soon ;D.
Has anybody conisdered using Fuzzy Logic for the control? I’m just getting to learn about it and it looks like an interesting alternative to PID loops.
[quote]Has anybody conisdered using Fuzzy Logic for the control? I’m just getting to learn about it and it looks like an interesting alternative to PID loops.
[/quote]
interesting! @ realiser, do you have any hardware to test it on? it all depends the algorithms -offcourse. but it would be interesting to see how FLC compares to a well tuned PID. If i get the time on sunday i’ll definately try this.
After that we carry on with AI or GA for getting optimal parameter values
Still working on the hardware. Will be Panda based initially.
Maybe we should put some effort into defining an overall architecture for this thing?
It sounds like people want to play with different options of IMU (standalone, external controlled from NETMF, internal RLP, internal pure managed code).
For the IMU itself we also want to play with PID, FLC and AI.
For telemetry and remote control there’s RC PWM, Xbee and WiFi already talked about.
I would like something where we can work independently on these building blocks and then combine or exchange them with each other later like Lego parts.
What about “Fluzi” - the Flying USBIzi architecture
@ mammaplank Unfortunately, my time has been totally consumed lately with work, 3 classes, and family… Working a charity event all this weekend and backpacking next weekend. Hopefully, after that I’ll have some time again for the copter
then I’ll probably buy some smaller batteries and see what kind of difference it makes.
