When to declare APM 2.x codebases "feature complete" and move on?
221 views
Skip to first unread message
Chris Anderson
Sep 25, 2013, 12:01:48 PM9/25/13
to drones-discuss
Team,
As we did with the original ArduPilot and then APM 1.x, it will soon be time to declare the APM 2.x codebases "feature complete" and move development to Pixhawk, which has so much more headroom.
In general, "feature complete" means that the code goes into maintenance mode, meaning bugfixes, support and documentation will continue for some period of time (at least a year and ideally more), but new features will not be added. This allows us to focus our developer time on taking advantage of the power in the new platform, rather than milking marginal returns out of the old one.
We expect to be shipping Pixhawk to the general public in the second week of October (core developers have it now and if you don't have one, Craig is the handling developer requests). My suggestion is that around the end of October would be a good time to draw the line in the sand for APM 2.x. So that would be ArduCopter 3.1 and ArduPlane 2.8(?). I suspect ArduRover has more headroom and is less mature, so perhaps it can go a bit further on APM 2.x
One question is whether we should increment the codebase numbers for the PX4-and-up generation, for clarity with users. So Copter 4.0, Plane 3.0 and Rover 3.0.
Thoughts?
Chris
Kevin Hester
Sep 25, 2013, 12:09:22 PM9/25/13
to drones-discuss
I think this is a great idea.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Gary McCray
Sep 25, 2013, 12:18:45 PM9/25/13
to drones-...@googlegroups.com
Hi Chris,
Though I am not central to this decision, I am glad to see it happening now.
And I think we all appreciate the disclosure ahead of the fact.
The APM is out of memory in Copter at least and trying to force it to keep up with the things that can be done on the Pixhawk / PX4 would only hold us back.
It might be possible that for Rover which is quite separate and still has a fair amount of headroom a bit longer period of forward motion might be beneficial to maintain in the firmware, not the hardware.
Clearly you will be and should be concluding sales of the APM (I suggest giant sale on remaining stock).
Best Regards,
Gary
Robert Lefebvre
Sep 25, 2013, 1:51:50 PM9/25/13
to drones-discuss
I also agree. Seems that at this point, the majority of developer time is being spent trying to figure out how to get things to run on the APM, rather than just implementing new features. I'm actually have a problem right now with an Octocopter running Mount, and wondering if I'm having a processing problem, as telemetry is definitely dropping out. So in a way, we're beyond feature complete.
So there's no question that we should stop futzing around with AVR. I'd be pretty happy with 3.1 being the final release, as long as we get the new Acro controller in, and my heli stuff. If Randy is having trouble getting the GPS glitch stuff to fit then... I wouldn't worry about that.
I read various forums other than just DIYDrones, and I think we can hold our heads high and say we delivered what we said we would. And I believe the market has recognized that. I see A LOT of talk on RCG, MRF, etc. where people are talking about how good Arducopter is. You can't go into a DJI thread without seeing somebody complaining about something, and somebody else replying to them saying they should just get an APM. Doesn't matter if they're talking about the $200 Naza, or the $1200 A2.
Point being mainly, we should be able to hold our head high. I'm sure some will complain as they always do, but we can confidently stand behind Arcopter 3.0.
However, regardless of exactly where we draw the line, there's an important question to be answered. How will we manage the code base? Say in the future, we find some bug that needs to be fixed. Surely we'll do it for APM2.x? How do we manage that? Would it become... for example, AC3.1.1? If Copter jumps to 4.0 for PX only, how do we maintain an old code-base to which we can apply a critical fix and release for APM2.x?
Do we fork the code base? Leave an AC3.1 branch?
All of this is for Copter. I'm not sure what to do with Plane or Rover. As far as I know, they still have headroom. Do we want to stop developing for them anyway?
Randy Mackay
Sep 25, 2013, 9:09:21 PM9/25/13
to drones-...@googlegroups.com
I agree too. It's pretty much impossible to add new features to copter anymore.
The only thing is I'd prefer not to update the major version number for copter just yet. We just upgraded to 3.0 and that was a huge move. I'd rather use the big number increments for big increments in functionality. How about the first pixhawks/ARM only release for copter being 3.5?
-Randy
From: Gary McCray <garyr...@gmail.com>
To: drones-...@googlegroups.com
Sent: Thursday, September 26, 2013 1:18 AM
Subject: [drones-discuss] Re: When to declare APM 2.x codebases "feature complete" and move on?
Chris Anderson
Sep 25, 2013, 9:36:05 PM9/25/13
to drones-discuss
3.5 works for me!
-Chris
john...@gmail.com
Sep 26, 2013, 4:33:53 AM9/26/13
to drones-...@googlegroups.com
Totally agree that we need to separate the 8bit and 32bit system at this point. The problem is two way. We are pushing the 8bit system in ways it was never meant to, and at the same time using the new 32bit system with suboptimal designs for that architecture to keep the 8bit alive.
But here is a hard question. When the separation is official. Do we then allow AVR (8bit) only optimized patches for the legacy APM board, just as we will start doing Pixhawk only patches for the 32bit branch?
- JAB
But here is a hard question. When the separation is official. Do we then allow AVR (8bit) only optimized patches for the legacy APM board, just as we will start doing Pixhawk only patches for the 32bit branch?
- JAB
Andrew Tridgell
Sep 26, 2013, 5:04:54 AM9/26/13
to Chris Anderson, drones-discuss
Hi Chris,
Sorry to be the odd one out on this, but I don't agree :-)
> In general, "feature complete" means that the code goes into
> maintenance mode, meaning bugfixes, support and documentation will
> continue for some period of time (at least a year and ideally more),
> but new features will not be added.
I know you intend the above to mean less work for developers, but for me
at least with plane and rover this would be more work, not less.
If we followed this suggestion and froze development on features on AVR
but still had the inevitable bug fixes then we'd be doing both bugfix
releases for the AVR version and feature releases for the ARM
version. The flight testing needed for a release takes a lot of time,
and we would no longer be testing the same code bases for both. As the
two drifted apart this would increase the development burden, not
decrease it.
It is certainly fine for Randy to decide not to support AVR on future
releases of copter if he decides that is the best option, but I would
prefer to continue support for AVR for plane and rover for quite some
time.
What I'd like to do instead is on a module by module basis continue the
work we've been doing to take advantage of the additional processing
power available on the ARM boards. We've been doing that for some time
now, for example:
- on ARM we use much higher sampling rates on the sensors, and better
(more CPU intensive) filtering
- on ARM we have much better logging to the SD card
- on ARM we have a more accurate barometer calculation for EAS2TAS
- on ARM we support some new sensors (such as the new airspeed sensor)
which we could support on AVR if we wanted to put in the effort, but
haven't done so as we'd rather people start using the new ARM boards
I see this continuing with for example a move to Kalman filtering for
attitude. That wouldn't mean dropping the existing DCM complementary
filters, instead we would be able to switch between filters in
flight. On AVR only the DCM filter would be available, whereas on ARM we
could switch between two filters, just like we've been able to switch
mid-flight between attitude control algorithms, navigation algorithms
and speed/height controllers.
That is largely the point of the modular architecture we have been
moving the code to over the last 2 years. It gives us the ability to
slowly move the code to both take advantage of new hardware and also fix
bugs while keep things very stable.
> As we did with the original ArduPilot and then APM 1.x, it will soon
> be time to declare the APM 2.x codebases "feature complete" and move
> development to Pixhawk, which has so much more headroom.
this approach of the "big switch" is what I've been trying to get the
project away from. It is much better to do things incrementally,
switching over small portions of the code to take advantage of new
capabilities while leaving existing code stable than it is to think of
"new board, all new code".
I have no problem at all with whatever schedule 3DR chooses for stopping
selling the AVR boards, but I do want to keep doing development for
plane and rover for the time being with both AVR and ARM targets. For me
at least that will be both less work, and I also think the right thing
to do for the plane and rover communities.
Cheers, Tridge
Sorry to be the odd one out on this, but I don't agree :-)
> In general, "feature complete" means that the code goes into
> maintenance mode, meaning bugfixes, support and documentation will
> continue for some period of time (at least a year and ideally more),
> but new features will not be added.
at least with plane and rover this would be more work, not less.
If we followed this suggestion and froze development on features on AVR
but still had the inevitable bug fixes then we'd be doing both bugfix
releases for the AVR version and feature releases for the ARM
version. The flight testing needed for a release takes a lot of time,
and we would no longer be testing the same code bases for both. As the
two drifted apart this would increase the development burden, not
decrease it.
It is certainly fine for Randy to decide not to support AVR on future
releases of copter if he decides that is the best option, but I would
prefer to continue support for AVR for plane and rover for quite some
time.
What I'd like to do instead is on a module by module basis continue the
work we've been doing to take advantage of the additional processing
power available on the ARM boards. We've been doing that for some time
now, for example:
- on ARM we use much higher sampling rates on the sensors, and better
(more CPU intensive) filtering
- on ARM we have much better logging to the SD card
- on ARM we have a more accurate barometer calculation for EAS2TAS
- on ARM we support some new sensors (such as the new airspeed sensor)
which we could support on AVR if we wanted to put in the effort, but
haven't done so as we'd rather people start using the new ARM boards
I see this continuing with for example a move to Kalman filtering for
attitude. That wouldn't mean dropping the existing DCM complementary
filters, instead we would be able to switch between filters in
flight. On AVR only the DCM filter would be available, whereas on ARM we
could switch between two filters, just like we've been able to switch
mid-flight between attitude control algorithms, navigation algorithms
and speed/height controllers.
That is largely the point of the modular architecture we have been
moving the code to over the last 2 years. It gives us the ability to
slowly move the code to both take advantage of new hardware and also fix
bugs while keep things very stable.
> As we did with the original ArduPilot and then APM 1.x, it will soon
> be time to declare the APM 2.x codebases "feature complete" and move
> development to Pixhawk, which has so much more headroom.
project away from. It is much better to do things incrementally,
switching over small portions of the code to take advantage of new
capabilities while leaving existing code stable than it is to think of
"new board, all new code".
I have no problem at all with whatever schedule 3DR chooses for stopping
selling the AVR boards, but I do want to keep doing development for
plane and rover for the time being with both AVR and ARM targets. For me
at least that will be both less work, and I also think the right thing
to do for the plane and rover communities.
Cheers, Tridge
Chris Anderson
Sep 26, 2013, 9:55:51 AM9/26/13
to drones-discuss
Tridge, I'm very happy to let the team leads decided on the timing of the switchover for each platform. If Randy decides to switch over Copter now and you don't switch Plane and Rover for another year, that's fine with me and appropriate, since you're the best people to make that choice.
Your incremental (module by module) approach seems to make a lot of sense but my impression is that with Copter the memory issues have come to a crisis point and the team is hungry to increase our pace of innovation by focusing our new efforts on a platform that is more capable.
Again, I leave this in your and Randy's very good hands. I just wanted to start the discussion and get to a decision, which I think we've now done.
Best,
Chris
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Craig Elder
Sep 26, 2013, 10:36:12 AM9/26/13
to drones-discuss
What we need is for somebody besides Randy and Tridge to step up to the plate and take on re-working the Arduino compiler so we can keep using it.
We have lots of talent in this group. Anyone looking for a little project?
Robert Lefebvre
Sep 26, 2013, 10:36:37 AM9/26/13
to drones-discuss
Whatever is decided with the code bases, it needs to be matched up with hardware availability. We shouldn't announce anything, or release any 32-bit-only code until we are sure there is a large, stable supply of hardware to go with it. As I understand it, the Pixhawk still is not widely available. We don't want to be in a position where a statement is made which generates buzz in the community, but nobody can get their hands on the hardware. The flipside of that, is that if any sort of firm change in direction is made, we need to make sure all the developers are on board and development actually happens.
I've heard from a number of people (regular users) who bought a PX4 thinking it was the next big thing, only to find out that it really wasn't ready to go from a consumer standpoint. We've only just got easy firmware uploading direct from MP, and already the PX4 is being replaced. Not to say that it's obsolete and will not be supported... but it is a bit of an orphan. This whole situation generates a negative perception of the entire program.
This is the situation we're in still. It is, or will soon be consumer available, but I don't see much development being done specifically for it. I haven't got one to use, so I'm still working with APM. Lots of ideas, but they won't fit on APM so, I'm just stalled.
Another aspect of all of this, is we may have already got too much in the Copter code. Not positive this is the issue yet, but I have an Octocopter which is running Mount on an APM, and it's not flying well. Soon as I turn on Loiter, telemetry stops and INAV is not feeling good. We may need to deprecate some of these features for APM.
Meier Lorenz
Sep 26, 2013, 11:23:17 AM9/26/13
to <drones-discuss@googlegroups.com>
Hi Robert,
Just to make this very clear: Although there has been a marketing stunt to sell Pixhawk as the new thing, it is PX4FMU + PX4IO in one case, along with a bunch of incremental improvements. Nothing more, nothing less.
The only reason its not named PX4FMU+PX4IOv2 is the obvious problem that it starts to look like a random assortment of letters and numbers.
There is no orphan, and flight-performance wise I'm not expecting differences between FMU and Pixhawk. The only difference is the form factor, and there is a relevant share of people preferring FMU for its smaller footprint.
Also note that we never spun it as "end-user thing" until now, and I'm sure the config tool support will be great once the end-user hardware (made obvious by having a case) is finally available.
-Lorenz
On 26. Sep, 2013, at 16:36 , Robert Lefebvre <robert....@gmail.com<mailto:robert....@gmail.com>> wrote:
Whatever is decided with the code bases, it needs to be matched up with hardware availability. We shouldn't announce anything, or release any 32-bit-only code until we are sure there is a large, stable supply of hardware to go with it. As I understand it, the Pixhawk still is not widely available. We don't want to be in a position where a statement is made which generates buzz in the community, but nobody can get their hands on the hardware. The flipside of that, is that if any sort of firm change in direction is made, we need to make sure all the developers are on board and development actually happens.
I've heard from a number of people (regular users) who bought a PX4 thinking it was the next big thing, only to find out that it really wasn't ready to go from a consumer standpoint. We've only just got easy firmware uploading direct from MP, and already the PX4 is being replaced. Not to say that it's obsolete and will not be supported... but it is a bit of an orphan. This whole situation generates a negative perception of the entire program.
This is the situation we're in still. It is, or will soon be consumer available, but I don't see much development being done specifically for it. I haven't got one to use, so I'm still working with APM. Lots of ideas, but they won't fit on APM so, I'm just stalled.
Another aspect of all of this, is we may have already got too much in the Copter code. Not positive this is the issue yet, but I have an Octocopter which is running Mount on an APM, and it's not flying well. Soon as I turn on Loiter, telemetry stops and INAV is not feeling good. We may need to deprecate some of these features for APM.
On 26 September 2013 09:55, Chris Anderson <ch...@3drobotics.com<mailto:ch...@3drobotics.com>> wrote:
Tridge, I'm very happy to let the team leads decided on the timing of the switchover for each platform. If Randy decides to switch over Copter now and you don't switch Plane and Rover for another year, that's fine with me and appropriate, since you're the best people to make that choice.
Your incremental (module by module) approach seems to make a lot of sense but my impression is that with Copter the memory issues have come to a crisis point and the team is hungry to increase our pace of innovation by focusing our new efforts on a platform that is more capable.
Again, I leave this in your and Randy's very good hands. I just wanted to start the discussion and get to a decision, which I think we've now done.
Best,
Chris
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.
Just to make this very clear: Although there has been a marketing stunt to sell Pixhawk as the new thing, it is PX4FMU + PX4IO in one case, along with a bunch of incremental improvements. Nothing more, nothing less.
The only reason its not named PX4FMU+PX4IOv2 is the obvious problem that it starts to look like a random assortment of letters and numbers.
There is no orphan, and flight-performance wise I'm not expecting differences between FMU and Pixhawk. The only difference is the form factor, and there is a relevant share of people preferring FMU for its smaller footprint.
Also note that we never spun it as "end-user thing" until now, and I'm sure the config tool support will be great once the end-user hardware (made obvious by having a case) is finally available.
-Lorenz
On 26. Sep, 2013, at 16:36 , Robert Lefebvre <robert....@gmail.com<mailto:robert....@gmail.com>> wrote:
Whatever is decided with the code bases, it needs to be matched up with hardware availability. We shouldn't announce anything, or release any 32-bit-only code until we are sure there is a large, stable supply of hardware to go with it. As I understand it, the Pixhawk still is not widely available. We don't want to be in a position where a statement is made which generates buzz in the community, but nobody can get their hands on the hardware. The flipside of that, is that if any sort of firm change in direction is made, we need to make sure all the developers are on board and development actually happens.
I've heard from a number of people (regular users) who bought a PX4 thinking it was the next big thing, only to find out that it really wasn't ready to go from a consumer standpoint. We've only just got easy firmware uploading direct from MP, and already the PX4 is being replaced. Not to say that it's obsolete and will not be supported... but it is a bit of an orphan. This whole situation generates a negative perception of the entire program.
This is the situation we're in still. It is, or will soon be consumer available, but I don't see much development being done specifically for it. I haven't got one to use, so I'm still working with APM. Lots of ideas, but they won't fit on APM so, I'm just stalled.
Another aspect of all of this, is we may have already got too much in the Copter code. Not positive this is the issue yet, but I have an Octocopter which is running Mount on an APM, and it's not flying well. Soon as I turn on Loiter, telemetry stops and INAV is not feeling good. We may need to deprecate some of these features for APM.
On 26 September 2013 09:55, Chris Anderson <ch...@3drobotics.com<mailto:ch...@3drobotics.com>> wrote:
Tridge, I'm very happy to let the team leads decided on the timing of the switchover for each platform. If Randy decides to switch over Copter now and you don't switch Plane and Rover for another year, that's fine with me and appropriate, since you're the best people to make that choice.
Your incremental (module by module) approach seems to make a lot of sense but my impression is that with Copter the memory issues have come to a crisis point and the team is hungry to increase our pace of innovation by focusing our new efforts on a platform that is more capable.
Again, I leave this in your and Randy's very good hands. I just wanted to start the discussion and get to a decision, which I think we've now done.
Best,
Chris
For more options, visit https://groups.google.com/groups/opt_out.
--
Chris Anderson
CEO, 3D Robotics
ch...@3drobotics.com<mailto:ch...@3drobotics.com>
--
Chris Anderson
CEO, 3D Robotics
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
Robert Lefebvre
Sep 26, 2013, 11:37:07 AM9/26/13
to drones-discuss
Lorenz, I didn't mean to imply that you had done anything wrong. I understand what the situation is. I'm just talking about the broader market, where perception is reality. The perception is that the PX4 was consumer released, never really developed, and then superseded by another board. Some people have them sitting in a box on a shelf with other "couldn't make it work" electronics.
I'm just trying to help that not happen again.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
Arthur Benemann
Sep 26, 2013, 1:14:04 PM9/26/13
to drones-...@googlegroups.com
My comment to this matter is that there is no problem to do it, if we have a nice chart showing what firmware goes with what board. Maybe a table with the Boards and software versions showing what is compatible.
If not, all this mental mapping will confuse any regular user.
Marco Robustini
Sep 26, 2013, 2:54:58 PM9/26/13
to drones-...@googlegroups.com
Hi Chris, i've asked for one Pixhawk and U-Blox gps with compass inside two week a go but i haven't received nothing.... Craig? :-)
Marco
Marco
Roberto Navoni
Sep 26, 2013, 3:25:54 PM9/26/13
to drones-discuss
I start to work on VRBrain and ARM processor 2 years ago . I'm very
happy that ear that the avr development stop. So will be possible to
have better fly performance and less limit on hardware resource . But
I agree with tridge is not so simple doing a switch on a new platform
without problem.
Now respect of 2 years ago there are a lot of powerfull arm platform
on the market. DJI for example with it's last product A2 and Naza V2.
So i think that for the user now is very important to have an
affordable product when choose a new platform for his development. So
Opensource is great for developer but is not so great for the end
user.
In these 2 weeks we found some bugs in the scheduler of APM / VRBrain
implementation. The main problem was that at low speed you don't see
the problem when you try to use more performance of your arm processor
if you don' know very good the hardware you can have bad surprise . So
is very important change approach in the development . Is important
to develop modular application where when you finish one module you
don't need to change it to implement a new functionality.
Debug a new platform is a lot time expensive. And normally in the lab
the bug not happen , normally only at some user and is not so simple
found and understand how solve it.
So at the moment we are evaluating how improve the AP_HAL_VRBAIN with
O.S. functionality and could be possible that we choose to use NuttX
as PX4 so our team can support PX4 development and vice versa . So i
undestand that the rev 3.5 will be an evolution of 3.1.x so with the
same approach of original APM development or we intent to switch
towards original PX4 firmware ? Could be nice understand what will be
the exact strategy of future development .
In our debug and development we are using a lot JTAG POD , i don't
understand if PX4 use it ,too . Other questions is about CAN BUS , i
think that the future of external option could be implemented on CAN
BUS protocol , at the moment the APM don't support it could be nice
start to work on a new kind of lib that use CAN for managment external
device as GPS , TELEMETRY Module ecc ecc .
Best
Roberto
2013/9/26 Marco Robustini <robusti...@gmail.com>:
happy that ear that the avr development stop. So will be possible to
have better fly performance and less limit on hardware resource . But
I agree with tridge is not so simple doing a switch on a new platform
without problem.
Now respect of 2 years ago there are a lot of powerfull arm platform
on the market. DJI for example with it's last product A2 and Naza V2.
So i think that for the user now is very important to have an
affordable product when choose a new platform for his development. So
Opensource is great for developer but is not so great for the end
user.
In these 2 weeks we found some bugs in the scheduler of APM / VRBrain
implementation. The main problem was that at low speed you don't see
the problem when you try to use more performance of your arm processor
if you don' know very good the hardware you can have bad surprise . So
is very important change approach in the development . Is important
to develop modular application where when you finish one module you
don't need to change it to implement a new functionality.
Debug a new platform is a lot time expensive. And normally in the lab
the bug not happen , normally only at some user and is not so simple
found and understand how solve it.
So at the moment we are evaluating how improve the AP_HAL_VRBAIN with
O.S. functionality and could be possible that we choose to use NuttX
as PX4 so our team can support PX4 development and vice versa . So i
undestand that the rev 3.5 will be an evolution of 3.1.x so with the
same approach of original APM development or we intent to switch
towards original PX4 firmware ? Could be nice understand what will be
the exact strategy of future development .
In our debug and development we are using a lot JTAG POD , i don't
understand if PX4 use it ,too . Other questions is about CAN BUS , i
think that the future of external option could be implemented on CAN
BUS protocol , at the moment the APM don't support it could be nice
start to work on a new kind of lib that use CAN for managment external
device as GPS , TELEMETRY Module ecc ecc .
Best
Roberto
2013/9/26 Marco Robustini <robusti...@gmail.com>:
Gary McCray
Sep 26, 2013, 3:52:08 PM9/26/13
to drones-...@googlegroups.com
Interesting dilemma.
On the one hand, APM:Copter in particular has successfully used up the APM pretty much completely.
A small amount of rework may gain us enough space to add a few of the things that we already want to put in.
But the fact of the matter is that for copter we are very nearly at the end of the road for the APM.
Plane and Rover still have significant headroom but even they are unable to benefit from the higher CPU performance available in the PX stuff.
That said, a huge effort has gone into forcing the PX4 to operate in a fully compatible way with the APM code.
The reality is from a functional standpoint the APM still has a one or two year remaining service life even if production ceases immediately (which I suspect it will.)
So for that one or 2 year period we are going to need to continue to provide support for it (as Tridge has said).
But it is also a reality that for copter pretty much all and even for plane and rover most future development is going to be taking place for the PX stuff.
Frankly it seems to me that Tridge and Lorenz are the ones who are best qualified to determine the staging and actually fulfill the primary implementation of this and how it is handled should probably be left primarily up to them.
Personally I would be perfectly happy to write off the APM, say damn the torpedoes and full speed ahead, but I can see how a large number of other APM owners might not favor that decision.
However the course is charted it should prove to be an interesting journey.
Best Regards,
Gary
On Wednesday, September 25, 2013 9:01:48 AM UTC-7, chris wrote:
On Wednesday, September 25, 2013 9:01:48 AM UTC-7, chris wrote:
Marco Robustini
Sep 26, 2013, 5:12:03 PM9/26/13
to drones-...@googlegroups.com
This is my thought, accept it if you can: i think that, lately 3DRobotics is thinking very to the business and maybe a little to those who did sell a lot of hardware, without asking anything in return.
Pixhawk has long been in the hands of the lead developer but to someone of the team, in my opinion important, has not been sent... why?
3DRobotics is abandoning those who perhaps had to do a lot of business and has helped in the development of new functionalities (such Robert, for example, but is not the only one)?
I read my name as "lead tester" of this project and i don't have this board.
I'm just curious to know how 3DRobotics want to proceed, there is something that is not working or there are new choices in the company?
Just curious...
Bests, Marco
Pixhawk has long been in the hands of the lead developer but to someone of the team, in my opinion important, has not been sent... why?
3DRobotics is abandoning those who perhaps had to do a lot of business and has helped in the development of new functionalities (such Robert, for example, but is not the only one)?
I read my name as "lead tester" of this project and i don't have this board.
I'm just curious to know how 3DRobotics want to proceed, there is something that is not working or there are new choices in the company?
Just curious...
Bests, Marco
Robert Lefebvre
Sep 26, 2013, 5:40:03 PM9/26/13
to drones-discuss
I wasn't going to say anything this directly, but since Marco has said his piece I'll back him up. I have to admit that I'm a little dismayed that it seems like some number of Pixhawks just went out the door on Iris "Developer Editions", but I'm still waiting, apparently going to be waiting a few more weeks at least? I've been a developer already for 2 years, but it seems I'm nowhere near the head of the line.
If this is the way it is, a decision has been made and my input isn't valued anymore... fine. I'd just like some clarity on the matter because I'll have to reassess what I'm doing.
Marco Robustini
Sep 26, 2013, 5:46:16 PM9/26/13
to drones-...@googlegroups.com
+1 ;-)
Marco
Marco
Andrew Chapman
Sep 26, 2013, 5:51:42 PM9/26/13
to drones-...@googlegroups.com
The sooner we ditch support for APM 2.x the sooner the code will inevitably grow to fill the available resources of the Pixhawk and we'll be right back in the same situation. And the more code you have, the more bugs you have.
I would much rather see certain functions turned off by default for APM 2.x users so they might have to use a GCS to do certain things they can currently do with on-board code (my suggestion was auto-declination, which is quite large by the look of it, and how often are people moving between different declination areas?). Forcing people with lower-end hardware to jump through some more hoops or go to the effort of compiling their own code to pick-and-choose the functionality they want is preferable to locking them out of the exciting new functionality they're hearing about and might be keen to play with.
We'll also be doing ourselves out of a lot of testers for new features when they're only supported on the newer hardware. It is inevitable of course, but it feels a bit too early to be considering it now. Perhaps in 6 months or whatever point Pixhawk is used by the majority of users?
Andrew Tridgell
Sep 26, 2013, 6:47:47 PM9/26/13
to Craig Elder, drones-discuss
Hi Craig,
> What we need is for somebody besides Randy and Tridge to step up to the
> plate and take on re-working the Arduino compiler so we can keep using it.
Randy and I had another go at this yesterday and did get something
working, it just isn't as neat as we'd like.
If anyone would like to try it you need to download and install both of
the packages in this directory:
http://firmware.diydrones.com/Tools/Arduino/alpha/
you'll then have a version of Arduino that uses the 4.7.2 version of gcc
and you will get small binaries.
Note that those two packages are currently still uploading from my slow
home network, so wait at least 10 minutes from when I send this email
before downloading.
The reason we aren't delighted with this solution is it comes as two
packages rather than a single Arduino package. We haven't yet managed to
untangle the links between the two packages.
With this package APM:Copter builds to around 221 kbytes, which gives a
bit of breathing space for flash.
Cheers, Tridge
> What we need is for somebody besides Randy and Tridge to step up to the
> plate and take on re-working the Arduino compiler so we can keep using it.
working, it just isn't as neat as we'd like.
If anyone would like to try it you need to download and install both of
the packages in this directory:
http://firmware.diydrones.com/Tools/Arduino/alpha/
you'll then have a version of Arduino that uses the 4.7.2 version of gcc
and you will get small binaries.
Note that those two packages are currently still uploading from my slow
home network, so wait at least 10 minutes from when I send this email
before downloading.
The reason we aren't delighted with this solution is it comes as two
packages rather than a single Arduino package. We haven't yet managed to
untangle the links between the two packages.
With this package APM:Copter builds to around 221 kbytes, which gives a
bit of breathing space for flash.
Cheers, Tridge
Gary McCray
Sep 26, 2013, 7:40:15 PM9/26/13
to drones-...@googlegroups.com
Just a suggestion for Craig and Chris,
As someone else who has put in quite a bit of time on the Wiki, it might be a good idea to put out some regular posts to your important contributors to let them know where they stand, what might be coming and what if anything you would like to get from them.
Maybe something a little more declarative.
I know Marco has been a very capable, dedicated, invested and responsive tester and I know Robert has put enormous effort both into making trad heli what it is today and into responding to myriad user questions.
I know that with everything: Iris, Pixhawk and $30 million dollars that you are probably up to your ass in alligators, but it still might be worth a bit of effort to let your real non employee contributors know they are valued members of your team too.
Not really my place, I know, but it needed to be said.
Best Regards,
Gary
Andrew Tridgell
Sep 26, 2013, 8:07:34 PM9/26/13
to Andrew Chapman, drones-...@googlegroups.com
Hi Andrew,
> The sooner we ditch support for APM 2.x the sooner the code will
> inevitably grow to fill the available resources of the Pixhawk and
> we'll be right back in the same situation. And the more code you have,
> the more bugs you have.
I think that is a bit simplistic. We have much more code now than we had
2 years ago, yet I think we have less bugs now than 2 years ago.
I think the reason that happens is:
- lots of great testing and feedback by the community
- better software engineering practices (better simulation/autotest
etc)
- more modularity and module test suites
- better log analysis tools
It is also true that expectations are higher. Two years ago people were
happy if their aircraft survived a flight and did generally what they
wanted. Now they are only happy if it stays in a 1m box in loiter or for
planes it executes perfect turns every time. That is a good thing of
course!
> I would much rather see certain functions turned off by default for APM 2.x
> users so they might have to use a GCS to do certain things they can
> currently do with on-board code (my suggestion was auto-declination, which
> is quite large by the look of it, and how often are people moving between
> different declination areas?)
we may end up disabling auto-declination as you suggest. I did that for
the APM-1280 to keep it alive on planes a bit longer. For now we can
gain more by fixing the Arduino build system to use a more modern
compiler. That gains us a few months more on AVR. After that we can
revisit which features to disable, or choose to stop supporting AVR on
copter.
Cheers, Tridge
> The sooner we ditch support for APM 2.x the sooner the code will
> inevitably grow to fill the available resources of the Pixhawk and
> we'll be right back in the same situation. And the more code you have,
> the more bugs you have.
2 years ago, yet I think we have less bugs now than 2 years ago.
I think the reason that happens is:
- lots of great testing and feedback by the community
- better software engineering practices (better simulation/autotest
etc)
- more modularity and module test suites
- better log analysis tools
It is also true that expectations are higher. Two years ago people were
happy if their aircraft survived a flight and did generally what they
wanted. Now they are only happy if it stays in a 1m box in loiter or for
planes it executes perfect turns every time. That is a good thing of
course!
> I would much rather see certain functions turned off by default for APM 2.x
> users so they might have to use a GCS to do certain things they can
> currently do with on-board code (my suggestion was auto-declination, which
> is quite large by the look of it, and how often are people moving between
> different declination areas?)
the APM-1280 to keep it alive on planes a bit longer. For now we can
gain more by fixing the Arduino build system to use a more modern
compiler. That gains us a few months more on AVR. After that we can
revisit which features to disable, or choose to stop supporting AVR on
copter.
Cheers, Tridge
Andrew Tridgell
Sep 26, 2013, 8:00:03 PM9/26/13
to Gary McCray, drones-...@googlegroups.com
Hi Gary,
> Plane and Rover still have significant headroom but even they are unable to
> benefit from the higher CPU performance available in the PX stuff.
not really. Using the modular approach we have adopted we can benefit
from higher CPU speeds when available. We've been doing that for a while
now and I expect us to continue to add improvements which take advantage
of the faster CPU and larger memory, while still flying planes and
driving rovers fine on APM2.
> That said, a huge effort has gone into forcing the PX4 to operate in a
> fully compatible way with the APM code.
I wouldn't characterise it as "forcing" as that implies it wasn't a good
fit. The port to PX4 was actually a very good fit for AP_HAL. A lot of
the work that has been needed has been to improve the NuttX/PX4Firmware
layer which had a few issues that have mostly been addressed now.
The APM code itself has been slowly morphing to take full advantage of
whatever hardware is available. So on APM2 that means a slower AVR CPU,
and on embedded Linux it will mean even faster CPUs than PX4. I see this
as continuing, with APM becoming less and less dependent on a particular
hardware architecture or operating system.
> Frankly it seems to me that Tridge and Lorenz are the ones who are best
> qualified to determine the staging and actually fulfill the primary
> implementation of this and how it is handled should probably be left
> primarily up to them.
minor correction - for copter it is Randys call.
Cheers, Tridge
> Plane and Rover still have significant headroom but even they are unable to
> benefit from the higher CPU performance available in the PX stuff.
from higher CPU speeds when available. We've been doing that for a while
now and I expect us to continue to add improvements which take advantage
of the faster CPU and larger memory, while still flying planes and
driving rovers fine on APM2.
> That said, a huge effort has gone into forcing the PX4 to operate in a
> fully compatible way with the APM code.
fit. The port to PX4 was actually a very good fit for AP_HAL. A lot of
the work that has been needed has been to improve the NuttX/PX4Firmware
layer which had a few issues that have mostly been addressed now.
The APM code itself has been slowly morphing to take full advantage of
whatever hardware is available. So on APM2 that means a slower AVR CPU,
and on embedded Linux it will mean even faster CPUs than PX4. I see this
as continuing, with APM becoming less and less dependent on a particular
hardware architecture or operating system.
> Frankly it seems to me that Tridge and Lorenz are the ones who are best
> qualified to determine the staging and actually fulfill the primary
> implementation of this and how it is handled should probably be left
> primarily up to them.
Cheers, Tridge
Gary McCray
Sep 26, 2013, 9:06:31 PM9/26/13
to drones-...@googlegroups.com, Gary McCray, and...@tridgell.net
Hi Tridge,
When I said that plane and rover weren't able to benefit from the higher CPU performance I really meant that the APM couldn't benefit because it had lower hardware performance.
I was not clear on that.
"Forcing" was a very poor choice of words.
I think you guys have done an amazing job at getting the APM and PX stuff working together using the HAL and that approach also makes it a lot easier to move to other platforms as well (which you are already doing).
And when I was referencing the primary implementation, I meant Primary, as in the underlying structure, not in the individual implementations.
Under no circumstances was it my intention to slight Randy or to fail to understand his fundamental and critical importance to Copter in making those decisions, it was simply a recognition of your and Lorenz's pivotal roles in defining and constructing the underlying platforms that now makes this whole thing work.
I know there are many others too.
I think the fact of the matter is that you are exceptionally democratic and work completely with the developers and concerned others on figuring out what to do next.
Clearly the underlying reality is that some more capability can and will be added to the APM, but that for the time being future board sales and major firmware advancements will likely be primarily targeted to the PX boards and that after that it will be more Powerful Linux SBCs like the ODROID boards.
With the architecture you have created you can keep all of them working beneficial well into the future.
Best Regards,
Gary
Craig Elder
Sep 26, 2013, 10:11:37 PM9/26/13
to drones-discuss
Marco, you're in the queue.
Chris Anderson
Sep 27, 2013, 12:58:42 AM9/27/13
to drones-discuss
Marco, Robert: As far as I know everyone who has requested a Pixhawk will get one. They're making them as fast as they can and sending them out in order of request. Craig is handling these.
Just so you know, even I don't have one yet! (hint, hint Craig ;-)
-Chris
Reply all
Reply to author
Forward
0 new messages