Replies to This Discussion

Permalink Reply by Jeff Smith on August 9, 2012 at 5:10pm

I was curious what it would be like to figure out the control of a tri-copter with all 3 motors on servo's but figured out that other than having the ability to yaw at crazy RPM there would be no advantage LoL

• ▶ Reply

Permalink Reply by Harry on August 9, 2012 at 7:26pm

The picture of my tricopter at the beginning of this has only the yaw motor spinning in the opposite direction and with the KK board.  Then I broke one more and ended up with all in the same direction and found out that's really not going to work .  New ones on the way, another lesson learned.

Where are you with your efforts, Jeff?

• ▶ Reply

Permalink Reply by Jeff Smith on August 9, 2012 at 10:30pm

LoL, day dreaming :-) I have done lots of reading, but as I have no ArduIMU yet, I have really done nothing but intently watch your progress.

I did get my shipping notice from 3DR today which ROCKS! but the fedex tracker doesn't show it yet, so I still don't have a due date. I suspect either Saturday or Monday and can't see it going past Tuesday at the latest... I'll know more tomorrow.

I have read tons on the DCM functions but still haven't learned much on the mixing of the channels. To be honest I think I will just have to start from what you have and then correct as I go. Once I've got something that will keep my copter in the air I think I will move on to Greg's gimbal code to see what can be gained. Though the more I look the more I am finding on ArduIMU copter controllers so there may be more to work with than I know of.

As a side note I am also intently looking into ARM based processors and 32 bit code written in C++, it seems it will be the future of this hobby. I can use the ArduIMU (with AVR) straight up to act as a bus for raw sensor data and use one of these Cortex-M4 processors with a floating point unit (FPU) to crunch the numbers for full blown DCM/Kalman filters at a crazy refresh rate. There is a fair amount of work being done on the 32bit side of the hobby and the gizmo's are dirt cheap. Here's one of the boards I'm ordering Friday along with about a grand in programmers and starter kits. Micro board with ARM ST32F4 processor. It comes with the companies bootloader, but I'll have a JTAG to load my own.

Can't wait for some hardware :-) I'll catch up to you soon.

• ▶ Reply

Permalink Reply by Harry on August 10, 2012 at 8:42pm

Catch up?  With the list of hardware you plan to play with, you'll be miles ahead.  I'll be making a small change and waiting for props forever. 

Whatever you do, wait until I have a successful flight before you take a chance on any code I've touched.  Be suspicious and check everything for yourself.  I've had a tendency to get all excited when something almost works and that's not good.  For instance, I was playing with the code and testing over and over and didnt see that the for loop that gets the offsets was only reading the last three positions in the AN_OFFSET[y ] array.

     Read_adc_raw();
    for(int y=3; y<=5; y++)   // Read initial ADC values for offset.
      AN_OFFSET[y]=AN_OFFSET[y]*0.8 + AN[y]*0.2;

I've had a tendency to also think something is more complicated than it really is.  It's all part of learning though.   Hopefully I get to a point where I'm competent enough to really get creative.

• ▶ Reply

Permalink Reply by Jeff Smith on August 10, 2012 at 10:54pm

We will both get there, what we end up spending to do it might not be a good subject though. This was a project to make something small do neat thing after all ;-)

• ▶ Reply

Permalink Reply by Harry on August 12, 2012 at 12:05am

Youre right again, Jeff.  If I just wanted to get in the air with an Arduwhatever, I could.  I wanted to use the ArduIMU to do something that really isnt supported and actually learn something beyond following directions.  With the motors spinning in the right directions and not causing wild torque problems, it should work but only if the output is fast enough.  I just read something about 100Hz being what a helicopter needs and I think the main loop() is 70Hz but it did work for Jean-Louis on V2 

Greg's code might be the best starting point in the end since it's supposed to be faster.  I should take another look now that I'm waiting on props. 

• ▶ Reply

Permalink Reply by Jeff Smith on August 12, 2012 at 12:21am

I just dropped $1100+ on goodies, so I sure hope I'm not heading in the wrong direction LOL

This will inspire you :-)

P.s. you're up late... are you installing countless GB of IDE's too?

Permalink Reply by Jeff Smith on August 13, 2012 at 5:42am

Had an idea this morning, I wonder if I could use the ArduIMU to stabilize the optical flow sensor for my 600efl as a way to get familiar with it?
I think the Optical Flow sensor hasn't worked well on the traditional heli's because when the APM corrects for drift it tilts the heli causing the Optical to sense drift, which has to be accounted for in code. This makes for a complicated loop in the software that must be hard to tune... eliminate the tilt for the Optical and simplify the tuning?

Then I could be playing with Greg's code parallel to yours :-)

• ▶ Reply

Permalink Reply by Harry on August 14, 2012 at 10:06am

All I've done is combine other's code in a way which hasnt passed testing yet.  

It sounds like youre saying youre going to use Greg's gimbal to physically isolate the optical flow sensor from the rest of the APM.  Is that to simplify the APM tuning?  

• ▶ Reply

Permalink Reply by Jeff Smith on August 14, 2012 at 11:52am

No, I want to use Greg's code to build an auto-stabilizing platform to go under my heli to allways keep the optical flow sensor pointed straight down without regard for the attitude of the heli. 3 servo's in 120 degree seperation like the awash plate on my heli moving a plate with the OF and sonar on it.

Currently when the OF detects drift the heli will tilt to correct, this alone causes the OF to sense amplified movement because it sees more ground passing by due to the heli changing its angle relative to the ground.

It will be the same stabilize code, just different intent.

Then I can address the servo inputs, yaw, and GPS stuff later. Kind of gives me a way to work with each aspect of the software independently.

• ▶ Reply

Permalink Reply by Jeff Smith on August 14, 2012 at 11:56am

Should have mentioned the OF will go to the APM as it usually is, the IMU will be independent with no inputs, just stabilizing the OF sensor.

• ▶ Reply

Permalink Reply by Jeff Smith on August 14, 2012 at 1:30pm

Got my ArduIMU V3 waiting at home :-)

I've got an FTDI programmer, but it's likely I will be using the AvrICE MKII to debug with, it is due Friday. I'll try the FTDI until then, guess I will be familiar with Arduino too...

• ▶ Reply

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• …
• 15
• Next ›
• Page