Comment

Developer Comment by Randy on October 9, 2012 at 7:55pm

Hey Alex (and all),

    To get started understanding the code, I'd suggest looking at the main loop function ("loop") in ArduCopter.pde and trace it through..i'd recommend next looking at Attitude.pde and figuring out how the stabilize + rate controllers work.  As you bump into objects (like AC_PID or APM_PI) you could check them out in the libraries.

     I guess it depends upon what you'd like to work on next..There are still lots of places to improve inside of ArduCopter.  There are many issues on the issues list which people have requested..I also have a list as long as my arm on things I'm working on and I'd be happy to pawn some of them off on people!  ..feel free to PM me.

Comment by alex corbett on October 8, 2012 at 9:59am

Hi all, This is probably as good a place to ask. If I wanted to get into being able to write or alter bits of code on the apm, for a complete novice, where would you advise me starting? Hoping not to sound like a total noob, Alex

Developer Comment by Randy on August 30, 2012 at 9:46pm

@Eagle,

    More brains the better I'd say!  welcome welcome!

Developer Comment by Randy on August 30, 2012 at 9:18pm

@Eagle re suggestion to create group re connecting ardupilot mega with external hardware...

A discussion is also a good way to go..whichever works for me of course.

Tridge (ArduPlane lead developer) uses a beagle board i believe.  I've had people here in japan ask about how to do this as well so it's certainly something that some people want to do.

One option is to use mavlink to receive/send data between apm and the other board.  Not sure if that's too slow or not..remember the parent board should be able to leave the nitty gritty of keeping the multicopter upright to the APM

Comment by Eagle on August 30, 2012 at 8:33pm

Hi, I have an idea and I would like to share it with you.

I don't know where to start so please Monroe I need you in this.

 

How about a Group?:

Learning to Connect Ardupilot Mega with external hardware?

 

Long time ago I follow a design and build a programmer on a breadboard that use the // port of a PC for I/O.  I establish a communication with the author of the electronic design and I wrote a GUI using Visual Basic and some dlls to upload/download programs in and out of a PIC16F84.

But that was... 20-25 years ago...

 

How about a Black-Box for APM.2.0 and up...

 

So far I learned about I2C versus SPI... I learned to blink a led. I learned to use HyperTerminal on Windows and comunicate with the "breadboard"....I learned to use a Dragon board.... I learned a lot.

 

Phase I:

Read the same data that MinimOSD is reading.

Store the MAVLink Data in the BlackBox.

 

Hardware: AT45DB321 and AT328P

Developer Comment by Andreas M. Antonopoulos on June 24, 2012 at 1:57pm

@Veikko (miss-addressed)

Unplug the motors and servos before running test code

Comment by Veikko Vierola on June 24, 2012 at 1:43pm

@Andreas / @Mike

Thanks for the help. I managed to compile arducopter code according to modem_test branch. Is there any problem if I test the arducopter on my plane setup. Is there going to be some funny things happening to my ailerons when the AMP is running arducopter code on a fixed wing plane?

Developer Comment by Andreas M. Antonopoulos on June 24, 2012 at 1:27pm

@Mike,

First of all, this is a "show me the code" dev culture, as I found out. Code talks, talk walks. 

The preferred method for contributions is to create a personal clone, then create the feature or fix you want on a branch of that clone. Once compiling and testing correctly, you then submit the code for code review by a dev peer. Then it is "scheduled" in the release plan. There are mailing lists and such of course, which devs are invited to join.

So if you want to get involved:

- Create a clone

- Implement a change

- Ask any dev (me if you want) for code review of the change

A

Comment by Michael Pursifull on June 24, 2012 at 1:12pm

@Andreas - thanks, I set it all up manually, outside of the repo stuff. I look at look at autotest.py main() and I may give that a try instead. 

Speaking of which, I've been testing various features, mostly adding more of the Mavlink specification into ArduPlane (and libraries; and soon ArduCopter) - what do you recommend as the form for approaching fellow devs for considering/discussing potential adoption? Now that I've been successful at navigating the codebase, I plan to go look at the bug list, or locate some request features (beside what I was working on, which was also requested, but not formally) and working up some candidates... how do you guys presently prefer changes? unified diffs off of the GIT, or diffs off of the release, or a patched branch for eval (if so, how frequently do I re-converge?) Is there a mailing list I should join? Thanks for any pointers. 

Comment by Michael Pursifull on June 24, 2012 at 12:56pm

yes, I use git. I mainly use it under Xcode, but I wouldn't recommend it over other platforms, I just happen to use it for unrelated reasons.

See "man gittutorial" for a walk through. If you are stuck on a GUI oriented operating system, or don't have man support, see http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

What is the problem? Have you used an RCS before?

Here is the basic idea - 

  * you specify a repository (or create one, if you are hosting)

  * if you made a new project, you import that code into the repo, otherwise

  * you go to a clean directory, and "check out" a copy of the project

  * you make edits, and then when you are happy, you "check in"

  * you should regularly "update" which pulls any changes down from the repo

There is a lot more you can do, this is just a basic conceptional/generic intro to repos. 

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• Next ›
• Page