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!
@Pbreed: actually I think, for non-programmers tuning parameters with Mission Planner should be good enough. Those variables are then stored in a non-volatile memory from which all variables are populated in runtime. For developers changing the code is easy enough. All has to be taken care of is keeping those declarations in one place.
As to XML-files, I know they're fancy and people use them a lot (too much in my opinion), but there really is no difference between changing a #define or const in code and editing an XML. Especially when the project is small and builds quickly.
I'd say keeping things simple is the way to success, not over-engineering solutions.
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.
In my opinion the most interesting part is adding the ROS compatibility. I would strongly recommend to watch this video about "Google I/O 2011: Cloud Robotics, ROS for Java and Android" https://www.youtube.com/watch?v=FxXBUp-4800&feature=player_embedded . The video is not only interesting regarding Arduino ROS compatibility but also about the object recognition task and Android compatibility that you are suggesting (see the part of the video about "google goggles", and ROSjava for Android).
I wanted to ask which do you think, are the principal milestone to obtain ROS compatibility for the ArduPilotMega (APM). As it seems arduino should be already compatible with ROS.
I'm really impressed with the great work that the DIYDrones community have achieved,
I assume "single board APM with integrated GPS" means: APM + IMU sensor + GPS? Love it!!
XBee alternative is also excellent stuff. Let's keep also European regulation in mind. 868 MHz is possibly one of the more realistic ones, but I am not a real expert on this. Any idea how does the regulatory process work in Open Sourced radios? Some sort of XBee 2x10 header type of exchangeability is good in getting there, but could likely be achieved by 4 or so pins.
For the mission planner it would be great to be able to serve Win, MAC and Linux users by the same system. That would take us basically to Qt or Java.
<I started to write something about the SW architecture refactorings but figured out it will become a lengthy one and would need a picture or two to express. Skipping it from here.>
For the absolute pressure sensor, consider having an option in install a tube in order to get a clean static pressure reference. (esp in planes – not so much of an issue in quads.) Inside an airframe the pressure level may change quite a bit and that is an unnecessary complication in airframe design to do properly. Bringing the static port outside the airframe perpendicular to the airflow solves the problem in one go.
How about optical flow sensors for quads to achieve really precise position hold?
How about option to plug in a heavy cruncher co-procesor Srinath & the gang to actually implement the image processing on board?
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?
That sounds very very good. I just have two suggestions: Please keep the APM sold at the moment still usable. It would be sad to have a new 32bit chip and everything just half a year after erveryone bought a mega...
Those are some tall orders! Congratulations on setting the bar high. The scary part is that I've seen the beginnings of all this right here in the forums and I know it's just around the corner that we'll see a formidable robotic platform. This is the team to do it- I can't wait!
Replies
@Pbreed: actually I think, for non-programmers tuning parameters with Mission Planner should be good enough. Those variables are then stored in a non-volatile memory from which all variables are populated in runtime. For developers changing the code is easy enough. All has to be taken care of is keeping those declarations in one place.
As to XML-files, I know they're fancy and people use them a lot (too much in my opinion), but there really is no difference between changing a #define or const in code and editing an XML. Especially when the project is small and builds quickly.
I'd say keeping things simple is the way to success, not over-engineering solutions.
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.
In my opinion the most interesting part is adding the ROS compatibility. I would strongly recommend to watch this video about "Google I/O 2011: Cloud Robotics, ROS for Java and Android" https://www.youtube.com/watch?v=FxXBUp-4800&feature=player_embedded . The video is not only interesting regarding Arduino ROS compatibility but also about the object recognition task and Android compatibility that you are suggesting (see the part of the video about "google goggles", and ROSjava for Android).
I wanted to ask which do you think, are the principal milestone to obtain ROS compatibility for the ArduPilotMega (APM). As it seems arduino should be already compatible with ROS.
I'm really impressed with the great work that the DIYDrones community have achieved,
Thanks, best regards,
Jesús
Thanks a lot for the invitation to the group!!
<Deep Japanese bow>
I am proud of having received Russel's email.
Some notes / comments / questions:
Best Regards
-mikko
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)
That sounds very very good.
I just have two suggestions:
Please keep the APM sold at the moment still usable. It would be sad to have a new 32bit chip and everything just half a year after erveryone bought a mega...
And second thing: For the "Fly the camera, not the copter", I'd like to suggest something i had thought about and Ricky helped agreat bit. Implementing that would be superb: http://diydrones.com/forum/topics/i-have-an-idea-for?commentId=7058...
Regards
Daniel