ArduPilot Firmware Version 2.5.1

ArduPilot Firmware Version 2.5.1 has been renamed to ArduPilot Firmware Version 2.6


ArduPilot 2.5 is not yet officially released, but ArduPilot 2.5.1 is already moving into the alpha testing phase.  2.5 was a huge change from 2.4.  The main goals for 2.5.1 are a bit more modest:

  1. Support integration of ArduIMU.
  2. Implement a new loop timing structure to better manage processor load.
  3. Change the throttle and elevator control laws to be based on airspeed control via throttle and total energy (energy height) control via throttle.  For airframes without an airspeed sensor use a 3 or 5 point throttle curve based on desired climb/descent
  4. Use a general PID controller function to implement all control laws for simplicity and flexibility
  5. Support for the new groundstation (if it arrives fairly soon)

In addition I hope to iron out some support issues for various airframes and configurations such as airframes using elevons (flying wings, deltas, etc.).


Other functionality which has been looked at but not really worked out that could find its way in to 2.5.1 includes
  1. Support for waypoint upload by xbee (probably only for thermopile setups though)
  2. Support for some integration between Remzibi OSD and ArduPilot
  3. Other requests???

Current status: Well the weather has been pretty poor lately but I did get in two flights today testing the STABILIZE and FLY BY WIRE modes using ArduIMU rather than thermopiles.  So the code is in a somewhat flyable state.   I would like to start working with a small group of alpha testers to continue developing and refining the code.  You do not need to be a programmer type to participate, but you should expect to run in to issues and communicate with the team to help solve them.  If you expect something that "works out of the box" then please look at 2.5 and do not respond to this.  If interested please message me.  Include a statement that you are interested in 2.5.1 in friend requests.  Thanks

Views: 3536

Reply to This

Replies to This Discussion

Code support for the IMU is fantastic news. Will it be able to support BOTH the ArduIMU and the original thermopile system at the same time for redunancy, or will it be a "pick one" kind of situatiuon?

Tim
Currently it is "pick one" I could build support for using both, but could use some suggestions on how to integrate the sensor data. I thought about doing this earler but did not come up with any scheme for integrating thermopile and IMU readings that I particularly liked....
Doug, do you think you post a guide to physically connecting ArduIMU+ and ArduPilot? What do you think about us releasing a PCB that would allow the IMU to sit between ArduPilot and the shield (which would not use the thermopile connector, of course, so it wouldn't have any bits sticking out on the bottom), or replacing the shield entirely for those who don't want the airspeed sensor and voltage monitor?
Hi Chris,

I haven't looked at the pin layouts closely to see if it could somehow be done without releasing a new board. If not it would definitely be a nice feature for a v3. The other option if we are doing a revision anyway would be to make it (the IMU) just a bit larger so that we could get the airspeed sensor and voltage divider on board and have it be a new shield. I'll take a look at it this evening.

I also found Tim's question above interesting. I have had the thought myself of "would it be better with both", but haven't figured out what the advantage would be. I thought perhaps for handling linear acceleration during hand launch, etc, but Ryal Beall thinks we could do just as well with careful drift correction gain deweighting.
Maybe IR thermopiles could be used when IMU gets saturated & goes crazy and needs a reset, but we could just use last few good positions to extrapolate a new heading at level per IR sensors / mag compass until IMU gyros can lock ??? How often needed and at extra cost weight is it worth it , maybe for high reliability application over water etc,,??
I haven't even powered my first AurduPilot, so I'm grabbing at straws with everything I do. The Zigbee is flat out awesome, but I'm a HAM, and hope to eventually upgade to some HAMTV stuff for FPV on the plane. Any chance of telemetry via audio line on the video feed? I KNOW they do it with APRS stuff, but I wouldn't know where to begin getting the data from the ArduPilot without hosing it up. And I'm sure there would be bandwidth issues as well, but maybe if it sent different packets at a time, like update the GPS, then airspeed, then voltage, then start over? You'd lose some realtime, but have to have less equipment on board. Give and take?

Just another passing thought. Sorry, I'm getting more excited each day that I get closer. :)
Tim
Hey Tim, you are just the guy I wanted to talk with. I have had the same idea about telemetry on one audio channel, but didn't know where to start with the hardware/modem part of the system. Love to chat about it. Shouldn't be a problem from the firmware/ArduPilot side. Maybe we should form a workgroup on it.

Anybody else interested in helping develop this?
I'm not sure on what level I can help, but I'll do all I can. Doug, I PM'd you some great resources. Apparently HAM radio APRS/telemtry has already been done with an AVR chip. WhereAVR. We just need to adapt it to Arduino. I don't have any familiarity with the Ardupilot yet though, so someone else will have to determine whether or not the Ardupilot can do this "as-is", but its very exciting to that it might be possible.

http://www.garydion.com/projects/whereavr/
Also, if you look to the left, he has an OSD based on Atmel chips as well!
1 - I think the APRS/telemetry scheme is very doable with Arduino, but would probably need a separate processor (from ArduPilot) as it looks like it would take up a lot of real time resources.

2 - the osd also looks very doable.

The gears are turning. I'll have to read up a bit more on both topics.
Doable, but you probably want a dedicated processor, or a chip to do FSK encoding, like the MX-614. (that chip only does 2400 baud, though.) Audio bandwidth is pretty limited (15 KHz?), so more advanced modems may not work.
Ok, I mentioned to Doug about adding a user definable voltage reading that would trigger "return to launch". Sorry, I should have put that here. Anyway, the idea was for preventing some stick-greedy guy from staying out too long and not making it back before hitting the ground. Don't ask where I came up with that. :)
I had another thought though. What about the motor beeping? Is it possible to simulate the ESC signal that beeps the motor? As long as the plane can glide for a few seconds, audible tones could beep warnings to the ground for all sorts of things.

Tim
Hey Tim,

It has been suggested before but is not really feasible. The motor beeping is caused by the esc sending an audio modulated signal to one of the motor windings and basically using the motor as a speaker coil. We don't have any direct access to the motor windings. Also, my UAV is often "on mission" far enough away that it cannot be heard, so not sure what value this would have for a low battery alarm.

We do have battery voltage in the telemetry and it is displayed in the ground station....

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service