What's new.
The PID files have changed slightly to match Mega.
Landing options are now set by distance to the landing waypoint. See the config file, this should be much easier to do than before. You'll want to make sure you line up your plane before you land.
Landing waypoint should be where you want the plane to land. Create a line up waypoint far enough away that your plane can get low enough. If your plane passes your landing spot, you need to take manual control of your plane.
Takeoff now holds its heading after climbing 15 meters.
Takeoff throttle is now set with by the radio instead of the config file. Safer...
I've included egg drop code. Please try it and improve upon it. It's in the events tab and is untested.
FBW A should has greater pitch authority.
Jason
We are now using the Issues list on Google Code.
Please include your header file and any telemetry output.
Replies
Is there any possibility that AUTOTAKEOFF mode will be like in 2.6.1 version?, ie, auto throttle from start? I have problems to launch my plane using my "IRE Automatic Launcher" with the latest version of code. I have no sufficient time to move the stick between the plane speeding up and the plane leaves the launcher. I need that from the beginning takeoff will be fully autonomous (like Ardupilot 2.6.1). (See this post and you understand me: http://diydrones.com/profiles/blogs/more-improvementsmore-funny )
Another issue ... is it necessary to have an IMU to run the Xplane simulation? I have XYZ sensors attached and in ArdupilotSim program not appear any data of GPS and aircraft attitude. It is right?
Thanks for your time and regards from Spain!
Dario.
I was flying revision 2.7 1390 today. The tested functions worked very well. The whole plane felt much smoother and under control.
I was looking at:
- STABILIZE
- FBW B
- RTL
- AUTO
I used the same config and setup as on my tests with 2.6.3
I had a problem with AUTO_TAKEOFF. I was flying at 10m above H and switched from MANUAL to AUTO. The plane went straight foreward with no pitch or climb past WP1. I stopped, returned and tried again. This time I "nuged" some pitch in. The plane was going up but exeeded the 75m I set by far. Then it seemd to have reached the TAKEOFF COMPLETED altitude and started the WP's very nice (while decending to 50m).
I have no clue what the altitude messup caused. I attached the logs.
The LOITERS are not very round, but we had some gusty wind today. I will report on that after a "calme day" flight.
I attached a proposition for the "no climb" in AUTO_TAKEOFF. Maybe you could have a look at that before I fly it tomorrow. I would feel much better that way.
Thanks for you work
Best
Christof
code proposition for AUTO_TAKEOFF.txt
APflight_2010_08_21_17_41_48.kml
ArduPilot_DataLog_2010_08_21_17_29_20.txt
I've made a new Debug mode for you (on the SVN) to help debug this throttle issue.
Here is the output:
ch3: 1408 Radio_in limited: 1405 Throttle: 35.86 PWM output: 1400 PWM Min: 1107 PWM Max: 1936
Min and Max are calculated on the fly.
Your output should match your input within about 10µs.
Radio_in limited is the constrained value based on your config file's CH3 min max.
Please run this and give me samples of the output.
Thanks,
Jason
Earl
I'm not sure where to post this information for you any more. I guess here is as good as anywhere else. Anyway not really formal report, I just wanted to let you know I tried r1385 and had the same result as before. Throttle is higher in Stabilize and Fly By Wire A (only modes tested) than in Manual. I reran Debug_Subsystem 1 & 2 with the new version with only slight changes in any of the PWM values. Tomorrow I'm going to recheck the transmitter setup and the ESC programming. If you get a chance to read this I have two questions for you:
1) Other than the ESC being programmed for Auto calibrate, can you think of anything else that might cause this behavior?
2) Are any of the servo output PWM values constrained to a maximum of 2000? When I ran the Debug_Subsystem 2 I got two channels that had max values of 2000 (Elevator and Rudder) I thought this seemed like more than a coincidence, since each of the channels output min values were very close to the input min values obtained with Debug_Subsystem 1, but the max values for output capped out at 2000 each despite the fact that the max input values were 100+ units higher.
I'll put together a better more detailed report with attachments tomorrow, and I'll be able to report anything I find (or not) with the inspection of my transmitter and ESC programming.
Best Regards,
Nathaniel
Can anyone tell me what causes such ground starts - I assume it is a poor receiver signal? Should I be using a receiver with a failsafe type out put that continues to generate PPM signals when there is no received signal?
Peter
ps I am a confirmed 35MHz user for the time being!
The longitude error people were reporting with the MediaTek is real.
I changed init_gps to look like this to put the MediaTek into binary. Seemed to work, but it did take MediaTek a long while to get a lock.
void init_gps(void)
{
Serial.begin(38400);
delay( 500 );
Serial.print( "$PGCMD,16,0,0,0,0,0*6A\r\n" );
delay( 500 );
GPS_fix = BAD_GPS;
}
I restart ArduPilot, my longitude (82degrees west) is showing as 44 degrees east. (Latitude and altitude is OK)
I'm seeing errors I thought were fixed. Are you updating a version not publicly available yet?
I just downloaded from http://code.google.com/p/ardupilot/downloads/list
Filename ▼ Summary + Labels ▼ Uploaded ▼ Size ▼ DownloadCount ▼
Ardupilot_2.7.53.zip Ardupilot 2.7 Beta 5.3, with egg drop demo code 2 days ago 689 KB 81
#1. Will not compile if I use
#define GCS_PROTOCOL -1
Has this error:
o: In function `set_mode(unsigned char)':
undefined reference to `send_message(unsigned char)'o: In function `update_GPS()':
o: In function `medium_loop()':
It will compile if I use
#define GCS_PROTOCOL 5
#2. When using
#define GPS_PROTOCOL 4
The MediaTek does obtain a lock, its blue light is steady. But ArduPilot does not recognize the lock. Its blue LED is blinking. Digging deeper I see that the MediaTek is outputting NMEA text, not binary. There is no code to put the MediaTek into binary (such as there is for the EM-406).
Docs for the MediaTek say it should come from the factory set in binary. I guess you are assuming they are shipped that way. None of mine are in binary. I thought someone had posted the command to set that, but I can't find it now.
Tried your solution, unfortunately it didn't resolve the problem for me. Thanks for the suggestion though!
Regards,
Nathaniel
-
1
-
2
-
3
-
4
of 4 Next