Moderator

How to contribute to a DIY Drones project? Start with something small and useful! Here's a list.

One of the biggest challenges in an open source development project is getting the "architecture of participation" right. Like a great game, contributing should be easy to pick up but hard to master, giving people of all skills and experience an opportunity to engage. Right now we have scores of developers working on dozens of projects, but a lot of it is behind the scenes on private email lists, Skype calls and IM threads, Google Docs and 3D Robotics project trackers.  You can see the tip of the iceberg in the change logs and Issue Tracker, but that's just a hint of the activity that goes on every day.

 

We're working to make more of this open to all, but one of the unique challenges of open source hardware development is that there must be manufacturing side to it, and that involves big investment and expenses in production capacity, component inventory and other commercial elements necessary to produce sophisticated electronics, do quality control, and keep them in stock. (In our case, that's companies such as 3D Robotics, Sparkfun, Jdrones, Udrones and others.) Accidentally pre-announcing a product (which is what might happen in a totally open dev process) risks confusing the market, setting expectations that production can't meet or leaving the production company with excess inventory of unsellable goods, which could bankrupt the companies that make it and deprive everyone of the technology. This is why none of the open source hardware companies, from Arduino to Sparkfun to Adafruit to MakerBot, have a open hardware development process, despite their commitment to openness in other respects. 

 

What all these companies do have, and we are working towards as well, is a more open software development process. The reason we haven't done that to date is that we had a lot of hardware discussion on our software dev lists, and it was too hard to police that. We're working on better policies to segment the discussions, but in the meantime, I wanted to give some guidelines on how to get involved with the dev process. 

 

First, one of the reasons we switched to the Git version control system is that anyone can create their own clone repository and work on it in a way that can create a patch that's easy for us to evaluate and integrate into the official code. A guide for those who want to do that is here. 

 

Second, we have a number of relatively small tasks, from bug fixes to features requests) that a perfect way for people who want to join the project to do something useful that will help us see their skills and figure out how best to integrate them into the core dev teams. People are always encourage to check out the Issue Tracker and pick off something they know how to fix, but here are some that we've identified that would make great first projects (existing Issues hyperlinked to issue tracker). Please volunteer in the comments below!

 

ArduPlane projects that we need volunteers for:

  • 1) Flaperons - Add a feature for use of flaperons building upon the new differential aileron feature
  • 2) Rudder with elevons - Add a feature to allow use of a rudder with elevons
  • 3) Split elevons (elevons and elevator) - Add a feature for use of one of the auxiliary channels as an elevator channel when using elevons 
  • 4) GPS time stamps - Correct to a single epoch - The supported gps units all report time differently.  Add code to report time in msec since Unix epoch for all gps
  • 5) Landing flare based on sonar - Add a feature to handle the landing flare based on height above the surface as measured with the sonar units used by ArduCopter.
  • 6) Minimum ground speed – auto throttle nudging - Add a feature so that a minimum ground speed may be specified and the airspeed/throttle will be increased as necessary to achieve that speed (for flight into headwinds)
  • 7) Verify proper operation over all conditions – throttle reversing - This is a little used feature that just needs thoroughly debugged.
  • 8) Minimum altitude feature for modes >= FBW - Add a feature where the user can specify a minimum altitude that the autopilot will not go under when in higher modes
  • 9) CLI – message when bad command entered - Add a message so users know when they have entered an invalid command.
  • 10) Allow alternate IMU orientations. - There  are a variety of issues that must be addressed to allow alternate IMU mounting orientations without impacting code performance
  • 11) Allow calibration at known non-zero pitch (eg fortaildraggers) - Allow the user to input a non-zero pitch angle that will correct for calibrating out of the flying attitude
  • 12) Fix # of sats and HDOP - Debug and standardize gps performance metrics for all supported gps
  • 13) Implement dead reckoning - Add a feature to calculate the 3D position based on kinematics between gps fixes.
  • 14) Wind estimation and related navigation changes - Add wind estimation feature based on Bill Premerlani's algorithm and/or a traditional magnetic vs gps heading approach
  • 15) Implement counterclockwise loitering - Impementing this feature will probably also require changing our mission storage structure (which should be done to be more in line with MAVLink's structure
  • 16) Implement landing command with automatic landing pattern planning - Add a feature where the autopilot and/or ground station will automatically plan the waypoints required to properly set up a landing pattern.
  • 17) Implement take-off and landing features for guided mode - Add features so that entire flights can be conducted in guided mode.

 

ArduCopter projects that we need volunteers for:

 

("TradHeli" means traditional helicopter. "Multi" means multicopters)

 

This is just small example on ArduCopter needs, more information can be found on How to contribute on ArduCopter project post.

 

Views: 3445


Developer Comment by Adam Rivera on September 29, 2011 at 6:49pm

I'll try to implement the flare (#5). Might take me a while to figure that out :-)


Developer Comment by Adam Rivera on September 29, 2011 at 6:50pm

What is a use case for #5 so I understand it's context a little better?


Moderator Comment by Chris Anderson on September 29, 2011 at 7:25pm

Re: #5. When you go into RTL, it always goes clockwise. Some people would rather have the choice to go the other way. Don't ask me why ;-)


Developer Comment by Adam Rivera on September 29, 2011 at 7:29pm

Sorry Chris... I meant the first #5 in that list. Looks like the number got repeated.


Moderator Comment by Chris Anderson on September 29, 2011 at 7:43pm

Adam: sorry about that--buggy CSS style sheet. Now fixed.

 

This list was created by Doug Weibel, but I think #5 refers to autolanding with fixed wing aircraft using the ArduCopter sonar library. We need to figure out how to translate sonar altitude into a landing flare for a soft landing with a plane. 


Developer Comment by Adam Rivera on September 29, 2011 at 8:02pm

Aha. Perhaps my confusion started by assuming #5 was for the ArduCopter. I was imagining my Octo flying in fast and flaring before a landing a lot like the huey's in vietnam or something. Unfortunately I have no experience with the ArduPlane setup. I think I will attempt creating a new mode for the ArduCopter. Sorry for the confusion.

Comment by Jose Angel on September 30, 2011 at 2:19am

Chris, apart fromt the bugs/requests in issue tracker, any list for arducopter project?


Developer Comment by Doug Weibel on September 30, 2011 at 6:20am

Hello all,

 

I gave this list to Chris, and would be happy to chat with anyone interested in doing any of these.  I basically know how to do all of them, but am very busy and don't get these done due to work on other issues/projects.

 

In fact, I would encourage you to contact me if you are interested.  In many cases getting a bit more background info will save a lot of wasted time and help you come up with a solution that better fits into the ArduPlane architecture.  I don't want to publish my email to the whole internet, but if you PM me through the site I will be happy to chat with you directly by PM, email or Skype.

 


Moderator Comment by Chris Anderson on September 30, 2011 at 7:27am

Jose, yes, I'll ask Jason and Randy to create a list for that, too, as soon as it comes out of beta. Right now we want the initial build to be 100% solid before we bring other people into the dev teams.

Comment by Jose Angel on September 30, 2011 at 8:14am

Thanks Chris, I look to hear from them soon!

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The third round was a reliablilty/aerial photography round for both planes and copters, which is now closed. Stay tuned for the next round, beginning soon.

A list of all T3 contests is here. 

 

Top Content 

1 What do you think the APM should do on fail safe

What do you think the APM should do on fail safe
2 Hexa-copter found after failed attempt of delivering cell phones to inmates of a Brazilian penitentiary

Hexa-copter found after failed attempt of delivering cell phones to inmates of a Brazilian penitentiary
3 Gauging Interest in the CNC Machine

Gauging Interest in the CNC Machine
4 Housekeeping note: Kevin Finisterre

Housekeeping note: Kevin Finisterre
5 hexa copter calibration problem

hexa copter calibration problem

Groups

© 2012   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service