ArduPilot Firmware Version 2.6
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:
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
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
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:
- Support integration of ArduIMU.
- Implement a new loop timing structure to better manage processor load.
- 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
- Use a general PID controller function to implement all control laws for simplicity and flexibility
- 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
- Support for waypoint upload by xbee (probably only for thermopile setups though)
- Support for some integration between Remzibi OSD and ArduPilot
- 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
Replies to This Discussion
-
Permalink Reply by Earl on -
It would be nice to use the pin to select set 1 or set 2 of TX 3 pos sw commands.
How about bit banging another serial port on the IMU and then comm the commands to the AP ?
Then we could have an easier in flight command from the GS !
Earl
-
DeveloperPermalink Reply by jasonshort on -
in print.pde find:
Serial.print(current_loc.alt,DEC);
change to
Serial.print(current_loc.alt/100,DEC);
Sorry about that. Surprised no one caught that before. I don't use that ground station, because I'm on a Mac.
-
Permalink Reply by Greg Fletcher on -
I just had an idea for how to uplink with 2.6 and the IMU. I haven't looked at 2.6 yet(where is it?),but I have been keeping up with this blog. The Ardu IMU is recieving the GPS just like the Ardupilot does using thermo's. Need to connect the Xbee Txo to the IMU's Rxi shared though a multiplexer with the GPS just like i do now with the Ardupilot. The IMU will poll the Xbee buffer for any uplinked commands. This takes very little time if no data has been sent, so it shouldn't load the processor very much. less time than reading the GPS. IMU will have to decode the received data and put it in the regular data stream to the Ardupilot. The work never ends when your having fun :)
...
-
Permalink Reply by Earl on
-
Most of the uplink will be solved with the mega with all its many serial ports. Sure will open up a lot pf on the fly programming possibilities !
I sure do like the IMU with the manometers and the new pressure sensor.Still can have the speed sensor in there also.
Come on MEGA...Get to the store already ! We are impatient (As you can tell)
Earl
-
Permalink Reply by Greg Fletcher on
-
DeveloperPermalink Reply by Doug Weibel on -
Hey Greg,
I have already had the same idea and communicated it to Jason. The question is if we need to change the protocol on the uplink. Currently Jason uses a blocking parser because the message length is not defined (you can string multiple commands together). The biggest problem this poses is that you could get a transmission error that causes the parser to not recognize the end of the message and to block execution of the IMU code. A different protocol (such as having the package size as part of the message header, or only allowing one command per message) would allow use of a non-blocking parser. Stay tuned.
2.6 is in the repository under Branches.
-
Permalink Reply by Yves Gohy on -
There is a small mistake here, in the code ArduImu.
In function 'void printdata ()':
error: 'imu_health' was not Declared in this scope In function 'void printPerfData (long int)':
It happens when PERFORMANCE_REPORTING == 0
The reason is: unsigned int imu_health = 65012; in section arduimu
The variable is not defined for the future, and is used in Section Output.
-
DeveloperPermalink Reply by Doug Weibel on -
Thanks Yves - I'll fix that... I obviously have not tried it without performance reporting since I added that feature. It is a nice feature. I leave it on all the time now and find interesting things. Like today I found that I had pushed the performance boundary too far and was using roll rates that were causing gyro saturation...
-
DeveloperPermalink Reply by Mark Colwell on -
Doug,
I have added Rembizi OSD code to AP_2_6, and got it to compile, but not getting numSV, always = 0, will you be adding Yves RemZibi OSD code to AP_2_6 soon?
-
DeveloperPermalink Reply by Doug Weibel on -
I posted R952 earlier today which has an important bug fix if you are flying with an airspeed sensor.
After correcting that bug the airspeed hold was working well. I was holding 25 m/sec +- 1.5 during some very demanding maneuvering. I should be able to do even better with some tuning.
Also, at this time I would recommend using the throttle slew rate limiter if you are flying with an airspeed sensor. I may need to tweak the total energy (energy height) throttle control law to be less sensitive to airspeed variation.
-
Permalink Reply by Earl on
-
Doug, I lost the addy of where to get the latest test code. Could you post pls ?
Earl
-
3D RoboticsPermalink Reply by Chris Anderson on -
The latest code is always in the repository.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
ArduRover User Group
185 members
-
Moderators
24 members
-
Agricultural UAVs
133 members
-
ArduCopter User Group
1298 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
