The Dev Team is working hard on the ArduCopter hardware and software roadmap. Here are some highlights:
As I've mentioned before, the APM hardware roadmap (next 12 months) is to start moving 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 frame side, we're continuing to evaluate alternative frames, ESCs, and power distribution boards. Our current frame performs very well, but we're always seeking to make it easier to set up, cheaper and more robust.
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 multicopter 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?
You need to be a member of diydrones to add comments!
I'd like to see the variable data interchange format between APM, autopilot etc become more generic.
Right now if, for instance, I wanted to improve the hovering accuracy by adding a velocity control loop then I would need to add PID values for the velocity loop. This is a mod to the format of messages, frames, APM etc... I have to touch two or three different pieces of code in two of more build environments ;-(
It would be much nicer if things like PID constants were stored in some kind of XML or other extensible structure so that I could add new constants and the APM would then automatically see that new elements were added and allow me to adjust them. I realize this might be hard with the existing AVR stuff, but if it could be done with the newer high perf 32 bit versions it would make it easier to contribute.
When I did this for my own helicopter code I could add a C++ variable IE:
AdjustableVariable my_newpid("My New PID",1.0);
this would automgically get stored in config and communicated to/from the variable adjustment/set up program on the PC.
In the declaration case above it added a new variable that had a name "My bew PID: and default value 1.0, asociated with it. I also had two knobs on my RC Tx that I could assign to varying any one of the AdjustableVariables.
I am working on some object recognition software, so it would be nice to make the copter follow a car on it's own. The aim would be to first maneuver the gimbaled camera so that the car remains at the center of the screen. But if the rotation limits of the camera are reached, it would start giving way-point commands to the autopilot.
But doing all this image processing onboard is a tall order. So it would have to beam back the live video using a video link or a 3G camera, do it in "real time" on a big comp on the ground and beam back the way-points to the copter.
In fact to ensure an uninterrupted video-stream it is cool to switch between a video link and a 3G connection dependent on availability.
Also it would be cool to push the limits of the estimator algorithm to know what we can do and where we would fail..
Apart from the DCM algo, i plan to try out some EKF's. I just wish we had a way to estimate attitude without having to make assumptions like udot is small etc...
How does a fighter plane pull it off?
Replies
I'd like to see the variable data interchange format between APM, autopilot etc become more generic.
Right now if, for instance, I wanted to improve the hovering accuracy by adding a velocity control loop then I would need to add PID values for the velocity loop. This is a mod to the format of messages, frames, APM etc... I have to touch two or three different pieces of code in two of more build environments ;-(
It would be much nicer if things like PID constants were stored in some kind of XML or other extensible structure so that I could add new constants and the APM would then automatically see that new elements were added and allow me to adjust them. I realize this might be hard with the existing AVR stuff, but if it could be done with the newer high perf 32 bit versions it would make it easier to contribute.
When I did this for my own helicopter code I could add a C++ variable IE:
AdjustableVariable my_newpid("My New PID",1.0);
this would automgically get stored in config and communicated to/from the variable adjustment/set up program on the PC.
In the declaration case above it added a new variable that had a name "My bew PID: and default value 1.0, asociated with it. I also had two knobs on my RC Tx that I could assign to varying any one of the AdjustableVariables.
I am working on some object recognition software, so it would be nice to make the copter follow a car on it's own. The aim would be to first maneuver the gimbaled camera so that the car remains at the center of the screen. But if the rotation limits of the camera are reached, it would start giving way-point commands to the autopilot.
But doing all this image processing onboard is a tall order. So it would have to beam back the live video using a video link or a 3G camera, do it in "real time" on a big comp on the ground and beam back the way-points to the copter.
In fact to ensure an uninterrupted video-stream it is cool to switch between a video link and a 3G connection dependent on availability.
Also it would be cool to push the limits of the estimator algorithm to know what we can do and where we would fail..
Apart from the DCM algo, i plan to try out some EKF's. I just wish we had a way to estimate attitude without having to make assumptions like udot is small etc...
How does a fighter plane pull it off?
Very cool, can't wait to play with it all. :O)