Folks,

The Dev Team is working on the APM hardware and software roadmap. Here are some highlights:

As I've mentioned before, the hardware roadmap (next 12 months) is to move to a 32-bit architecture along with the rest of the Arduino project. This will probably involve a single-board version of APM with an integrated GPS module. Long-term, we aim to make APM smaller, cheaper and more reliable. We'll announce more specifics when we're closer to a design. But rest assured that the current boards will remain the core of the project for a year or more and there is a lot of power still untapped in them, so we will continue to focus development on them.

There are also a bunch of other new boards coming soon, including an OSD designed to work with APM and possibly an open-source alternative to the Xbee modules.

On the software side, the priorities are also ease of use and more features. We're redesigning the Mission Planner to be one-stop dashboard for all setup needs. We'll be adding more commands to MAVLink, so you can script more complex missions. Real-time waypoint assignment with a click ("go here now") is coming. Joystick control from the HK GCS (no RC required) is very close to release. And there will be a lot more high-level photo/video controls, so you can "fly the camera", letting the aircraft figure out what to do.

On the overall system architecture side, we're adding ROS compatibility, so you can do multi-UAV swarming. We'll be integrating the PhoneDrone board for Android, so you can use an Anrdoid phone for high-level mission AI, such as tracking and following an object. And the Android interface can also allow long-distance wireless communications, far beyond the range of RC or Xbee.

That's a quick overview. What do you think? What else would you like to see?

Views: 924

Replies to This Discussion

Greetings,

As you may be aware, Darpa and the Space and Naval Warfare Systems Center Atlantic have just started a collaborative initiative to design, build and manufacture UAV systems (http://www.uavforge.net/). This was an opportunity for me to propose two themes based on two weaknesses of any quadrotors built to date which are, they can only fly an average of 15 to 20 minutes on a single LIPO battery, and there are no simulation programs predicting what could happen in bad weather (wind, rain, snow, etc.).

My main role is not to design a quadrotor, nor its avionics or electronics, but to work with academic groups and research institutes to explore, and perhaps deliver a fuel cell power source for keeping a backpacked-size quadrotor “alive” for well over 3 hours.

My second role is to select an existing community software package, e.g. the APM Mission Planner and have a team add functionality. This functionality will be to simulate a mission during “extreme” weather conditions (winds, rain, snow, etc. all in moderation of course).  Bad weather has a direct influence on flight time and the success of a mission. If we could “insert between waypoints” weather-related impairments, we could decrease the number of aborted missions and lost or crashed quadrotors.

Is the APM Mission Planner a possible solution to accomplish this second task? The simulation function of the APM MP will have to work without physical hardware (except for a laptop or tablet), the goal is to evaluate, on screen, the flight plan in simulation mode and perhaps adjust the waypoints for a safer route, if at all possible.

Thanks for your upcoming comments.

JJ

quadforge@gmail.com

 

 

JJ: Interesting project. I'm not sure we can fit the bill right out of the box. The APM Mission Planner requires the APM hardware in the loop for simulation. We don't have a pure software simulation of APM.

Chris, the APM Mission Planner is a superb piece of software and it should be kept that way without having a third party (us) messing with it.

What if an add-in module having hooks to the Flight Planner code (waypoints), hooks to the Simulation code (sim data) and hooks to the GUI? Would it be a reasonable approach vs. nothing?

This approach, good or bad, will bring many questions: Is the source code available, and if yes what programming language is it? Who has the authority to let us build an open source add-in?

You mentioned in your APM Roadmap a Dev Team, but did anyone write a tutorial on the APM MP’s internals or is it just Michael Oborne who’s doing development and code integration?

I should stop asking too many questions at this early point in time…

Yes, the source code is available (it's in .Net). Everything we do is 100% open source. 

You should speak with Michael Oborne directly about the idea of plug-ins. He's the author.

Cool, thank you! I'll contact Michael Oborne. Cheers, JJ

Hi Chris, I'm just beginning my research into autopilots for a plane I'd like to have flying next year (when the $ may be available).  I must say... what the ArduPilot team has accomplished already is just incredible!!  Many bits of your roadmap post above only amplify my excitement for this project.  

 

I'm sure you've heard this one 100 times since yesterday, but .. any plans to add flaperons to APM?  I think many of my missions may find me landing on short runways so slowing my plane down would be pretty nice.  

 

I want to reiterate that I don't mean to undermine your giant list of accomplishments by illuminating a feature that's not currently implemented!  I'm just asking because I love flaps :)

Chris,

Will the new 'high-level photo/video controls ...' include a command set that will control a camera shutter with the flexibility required for aerial survey applications?  

 

We need to be able to snap pictures every X meters (or Y seconds) along a line between selected waypoints at a defined altitude and ground speed.  The event should be logged in realtime and the logs should provide geo-stamping information.  Manual triggering from the GCS is needed.  Mission planning aids would be a big help.

 

Thanks to all the great work by you and the developers we have successfully flown a 200 meter square survey track.  All we need now is the camera shutter control.

Irvin, the issue is that all cameras are different. We have a relay on board that you can trigger whenever you want, if your camera shutter can be controlled by a relay. Other cameras can be controlled by an IR blaster connected to a RC channel; in that case you can trigger it via a spare RC Out channel on APM.  Yet others can be hacked to take a direct digital signal, such as the Canons that can be controlled via the CHDK

 

So the question is what kind of camera you have and which method is best to control it. 

Chris,

I have a camera that works very well with the relay (Canon SD1100 IS with CHDK) but 'you can not trigger the relay whenever you want'.

The problems are:

The current relay commands don't work properly. (See Issue # 374 Once the relay is turned on - it can not be turned off.)

I see no command set that will cause the relay to be 'triggered' every X meters or every Y sec. between two waypoints.

A log of the trigger event is needed for geo-positioning the pix after the flight. 

A trigger command sent from the GCS is needed to ground test the camera.

 

I submitted Issue # 292  Add a command TRIGGER in March.

 

Again, thanks all for the good work.

Gotcha. There is a difference between the functions that we build into MAVLink and those you can add yourself to the code. You can do anything you want with APM, but for some functions you'll need to add a line or two to the code. Others (chosen by popular demand) we'll build into the standard configuration, so you can script them in the Mission Planner. 

 

I'll check the MAVlink "relay off" command Issue you mentioned..

 

What would the difference between "Relay on" and "Trigger" be?

The trigger command would just do with one command what you can now do with multiple existing commands....

 

I have seen the relay issue on the issue tracker.  It is near the top of my to do list.  I keep finding more interesting navigation bugs and am digging in to them at present.

 

On the hardware roadmap, any interest in smaller form factor? - the stacking 'Ruby' http://www.uthere.com/products/ruby/ruby_for_your_aircraft.html form factor looks great for a skinny fuselage - an Arduino Nano style-ly APM would be great in my Merlin

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service