Jordi has been flight testing ArduPilot all week and we've got a raft of new code to share over the next week and an exciting new dimension of ArduPilot to reveal. First, today's installment: an updated version of the standard ArduPilot code, with PID loops improved and some bugs caught. You can find the code here.
This is the last version of ArduPilot that we will be releasing with a NMEA parser. Although NMEA allows you to use any GPS module with ArduPilot, it's inefficient and ultimately limiting in accuracy and reliability. Going forward we will be supporting SirfIII binary mode with the EM406 (if you have one, there's nothing you need to do to switch to that mode; the code will do it for you) and the Ublox 5Hz modules. Everyone with the recommended combo of ArduPilot and EM406 are fine. Those of you with other GPS modules are also fine for now, in that this is the latest and greatest code for this version of ArduPilot, but you won't be able to migrate with us to the next version. (Although you can always tweak our code for your own GPS if you want).
All this is the lead-up to the next release, in a few days: ArduPilot with built-in stabilization and navigation, flying great in a plane you may recognize ;-) More later..
Just some clarity on our roadmap:
ArduPilot will now fork into navigation-only (the current one, which supports all GPS modules), and navigation+stabalization, which is a bigger technical challenge and requires us to only use the most efficient code. That will be the standard EM406 that we've been recommending all along and the new Ublox.
If people have followed our recommendations on GPS, they're fine. If they haven't, they'll still have a state-of-the art navigation-only autopilot, which is what we initially pitched ArduPilot as. We've worked hard to keep the GPS choice wide open till now, but as the project develops we've got to impose constraints or the code base will become an unmanageable mess and then nobody will get anything!
FYI, the uBlox only does 4Hz. The 5Hz phase was a delusion of grandeur. Setting them to 5Hz only works with <10 satellites & causes them to drop back to 3Hz when >10 satellites.
Cool move to add stabilization. Thanks for your involvement in this.
Do you think the FMA CoPilot stabilization will be left on the roadside, or is there a way to run both codes evolving in parallel somehow? I assume you are going to keep the FMA CoPilot sensor without its module?
On the negative side, I think limiting GPS to binary models is not a good choice as it shall keep people out of the project if they do not have the specific GPS module. Only 1 month ago, I thought Chris had agreed with Michal about that point here and decided not to go the binary way. It seems things changed now.
Comments
ArduPilot will now fork into navigation-only (the current one, which supports all GPS modules), and navigation+stabalization, which is a bigger technical challenge and requires us to only use the most efficient code. That will be the standard EM406 that we've been recommending all along and the new Ublox.
If people have followed our recommendations on GPS, they're fine. If they haven't, they'll still have a state-of-the art navigation-only autopilot, which is what we initially pitched ArduPilot as. We've worked hard to keep the GPS choice wide open till now, but as the project develops we've got to impose constraints or the code base will become an unmanageable mess and then nobody will get anything!
Do you think the FMA CoPilot stabilization will be left on the roadside, or is there a way to run both codes evolving in parallel somehow? I assume you are going to keep the FMA CoPilot sensor without its module?
On the negative side, I think limiting GPS to binary models is not a good choice as it shall keep people out of the project if they do not have the specific GPS module. Only 1 month ago, I thought Chris had agreed with Michal about that point here and decided not to go the binary way. It seems things changed now.
-
1
-
2
-
3
of 3 Next