Replies to This Discussion

ModeratorPermalink Reply by Nathaniel Caner on January 1, 2013 at 9:50am

Perhaps we could make that behavior optional?

Regards,

Nathaniel ~KD2DEY

• ▶ Reply

Permalink Reply by Dario Lindo Andres on January 1, 2013 at 10:33am

Hi Graham,

Maybe using a buzzer instead of a servo signal could be the solution. The servo_test(); function is included in the system_ini(); so replacing this function with a buzzer function and defining it through an analog port can do the trick.

Same for led light flags: gps fix, armed, disarmed,...

Happy new year! Dario.

 

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on January 1, 2013 at 11:13am

Thanks Dario, to you too.

I'd like to see this behaviour taken out completely as a default rather than have to modify code and add buzzers, LED's etc. I have those on my quad but don't feel the need for them in ArduPlane.

Even having it as a user selectable option is better than what we have now but that would require an extra parameter and we already have enough of those.

• ▶ Reply

ModeratorPermalink Reply by Nathaniel Caner on January 1, 2013 at 12:04pm

Hi Guys,

I'd like to see the LED status lights broken out like the ArduCopter code through the MP in ArduPlane as the APM board is often buried inside the fuselage in a fixed wing plane. I think perhaps replacing the current wagging of the control surfaces to indicate ready status would be OK if there were a ready made way of bringing the ready status to the operator. I think your idea of a buzzer or the like would be a good idea, but I still think that if that wasn't a standard hardware feature shipped with the APM that you would still need some means of communicating the ready status for those who don't want to add any other hardware. That's why the current behavior of wagging the control surface works so well, because it makes use of what you inherently already have. I think an option that was configurable through the MP for all Arduxxx platforms would be the best solution. You already have from what I understand remote LED behavior configured in ArduCopter code and in the MP for basic LED behavior. It would be nice to see this migrated to the other Ardu code. Once that is done adding the option to disable the control surface wagging and enable a buzzer if required would be good too.

Regards,

Nathaniel ~KD2DEY

• ▶ Reply

Permalink Reply by Chris on January 6, 2013 at 10:21am

Hey

I use an APM1 for my Plane. (FPV-EPP)

Now i read, that there is a new firmware for the Mediatek GPS and the PPM Encoder.

Is the new 1.9 Firmware from the GPS compatible with the actual APM1 Arduplane Code?

And should i update my PPM Encoder, if i fly with a MX-20 from Graupner?

I was an long time not in the forums, so i dont know, what actual is "the newest" Info.

Hope u can help.

• ▶ Reply

Permalink Reply by jim C. on January 6, 2013 at 7:50pm

altitude change problems in home mode.

and I noticed when I give problems changing altitude of 100 m to 200 m, the plane begins to climb but angle exceeds its limit to make a loop. this occurs when there is wind of 20 km / h. what would be the parameter to adjust?
any explanation for this behavior?

Attachments:

• 2013-01-06 15-26-17.rar, 3.4 MB

• ▶ Reply

Permalink Reply by Djalma C Jr on January 9, 2013 at 6:15am

Hi Guys!

 

Can someone give an attention? is very important!

 

thanks!!!

http://diydrones.com/forum/topics/camera-stabilizer-pan-tilt?commen...

• ▶ Reply

Permalink Reply by mc_don on January 21, 2013 at 10:27pm

hire my log files..

using sw condor and set PID from Djalma C Jr

test for stabilizer,FBW from flight mode on remote

and RTH,loiter command from AMP planer

Attachments:

• sw_rute.kmz, 182 KB

• ▶ Reply

Permalink Reply by Djalma C Jr on January 31, 2013 at 12:44pm

great friend! thanks!

• ▶ Reply

Permalink Reply by Djalma C Jr on January 31, 2013 at 12:45pm

Hi friends, I would like an answer, always hear talk about calibrating the compass offsets X Y Z, but then .. What's that for? and what is the correct way to calibrate? because I already tried to calibrate with the logs through flight, and every time this show a different value.

I would like a clear answer about it, and that would result in a good calibration

• ▶ Reply

Permalink Reply by paul riseborough on February 2, 2013 at 4:37am

Looking at the code (I'm new to ardupilot, but have worked in flight controls for some years)  I can't see where the cross-track correction for wind gets applied in auto mode. Looking at the navigation.pde file on lines 31-33

// nav_bearing will includes xtrac correction
// ------------------------------------------
nav_bearing_cd = target_bearing_cd;

the nav bearing has been calculated previously using the bearing from current position to next waypoint and looks as though it should subsequently have the cross-track correction (including wind applied using an update_crosstrack(); function call.

Looking at the  update_crosstrack function I  believe there would be some benefit in an additional gain term based on cross track velocity to provide some damping to the track capture. I'm currently taking time to  understand the structure of the exisiting loops before inplementing some ideas for improvements. In particular I'm trying to improve track accuracy with varying crosswinds.

• ▶ Reply

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• Next ›
• Page