From Google issue 516:

Project Member Reported by [email protected], Nov 8, 2012
Arducoper NG or ACM?
What steps will reproduce the problem?

1. No current sensor attached or enabled in Config
2. Click terminal tab
3. type 'logs', then 'enable all'.
4. type disable current

What is the expected output? What do you see instead?
Expect CURRENT to no longer appear in the list of enabled logs.
CURRENT shows as still enabled

What version of the product are you using? On what operating system?
ACv2.8.1 MP 1.2.18

Please provide any additional information below.
See attached the screen print here: https://picasaweb.google.com/lh/photo/9I1X8CR2_Vyp4A3IatCbcCvpImV_kRcnSE2hj9F3Pw0?feat=directlink

Nov 23, 2012 Delete comment #1 [email protected]
Correct this is an error.
To disable current in log you have to run the command "disable cur"

/Benny

Having added 'take-off' to a mission, I arm the quad and switch to auto, I then gently move the throttle to start the mission (ie take-off) and the quad jumps agressively into the air (ie full throttle) before starting the rest of the mission.
Is there a parameter to adjust to do the take-off gently or if not, can the take-off be made more gentle or progressive?
It is currently quite alarming and draws a lot of current for a short time.

Should add LEARN_WP_SPEED boolean option

The altitude airspeed algorithm increases speed to gain attitude. This drains the batteries fast as the drag increases with the increased speed which steals power that could otherwise been used to climb
I would like to have an algorithm where the aircraft pitches to the desired climb pitch angle and check if the aircraft manages to hold the cruise (climb) speed. If the speed is lower than the desired the pitch is decreased until cruise airspeed is restored.

For the last couple of versions of mission planner (since about 1.2.28 I think) the option to embed video into the HUD is broken on my machines (3 of them, running XP, 32 and 64 bit Win7). It works fine after initialization in the configuration tab - but once any tab other than flight data is selected the video is replaced with a white box and the desired input device needs to be selected again.

if GPS lock is lost for several minutes we need to decay the contribution of the velocity to the attitude solution, otherwise the attitude can go a long way off

Since the move to the HAL version of the ardupilot code the IR sensor sonar function is no longer functioning and constantly returns a value of 715 no matter what distance an object is from the sensor.
I suspect that the problem may be in these two snippets of code:

ModeFilterInt16_Size5 sonar_mode_filter(2);

if CONFIG_SONAR == ENABLED

AP_HAL::AnalogSource *sonar_analog_source;
AP_RangeFinder_MaxsonarXL *sonar;

endif

if CONFIG_SONAR == ENABLED

#if CONFIG_SONAR_SOURCE == SONAR_SOURCE_ADC
sonar_analog_source = new AP_ADC_AnalogSource(
&adc, CONFIG_SONAR_SOURCE_ADC_CHANNEL, 0.25);
#elif CONFIG_SONAR_SOURCE == SONAR_SOURCE_ANALOG_PIN
sonar_analog_source = hal.analogin->channel(
CONFIG_SONAR_SOURCE_ANALOG_PIN);
#else
#warning "Invalid CONFIG_SONAR_SOURCE"
#endif
sonar = new AP_RangeFinder_MaxsonarXL(sonar_analog_source,
&sonar_mode_filter);

endif

When RTL mode is engaged, arduplane set default altitude.
Problem : it can cause crash
Solution : if current altitude>default altitude, keep current altitude as target in RTL mode

ArduCopter: I've been testing a fully automated parachute drop and have noticed that if the drop waypoint is close by, my quadcopter will drop the chute at whatever altitude it is at when it reaches the horizontal position of the waypoint. My waypoint height was set at 50m which, if far enough away, would be reached but if the waypoint was close then the chute was dropped at ~25-30m.

So... please could the next mission item not be executed until the altitude condition is achieved and could the climb rate be automatically adjusted by the distance to the waypoint?

This should include simulation of ESC input filtering

In ArduPlane there is a choice between navigation primarily by GPS and primarily by compass. Right now users need to make a choice before takeoff, by setting COMPASS_USE=0/1. I think a COMPASS_USE=2 option meaning "auto" makes sense, where the compass would be always enabled for takeoff (where GPS makes no sense, due to low ground speed), and GPS would be used when the GPS fix is high quality, and the plane is travelling well above the minimum speed.
I also think this should be the default for ArduPlane.

I have a half german-half english version of Mission Planner.

If you log messages too fast then the buffer to page async write may not have completed by the time you get to the next page. We need to ensure that when we start a new page that the previous buffer to page for that page has completed.

The throttle control is very granular in auto mode for rovers. It tends to be full speed or stopped

In Mission Planner 1.2.31 and 1.2.32, the Ctrl+A command does not bring up the 3DR radio configure tool as it did in 1.2.29.

The failsafe in Arduplane is a source of problem and isn't compatible with different brand of radio:

1. Firstly : lot of radio RX have failsafe for each channel (you cannot choose which channel have failsafe position or not).

When a faisafe kicks in, each servos takes a failsafe position, and that "failsafe position" is a different position before the failsafe event.
The problem is that: your plane moves its servos on each failsafe event.

And after that, APM takes control of the plane (circle mode). BUT if you regain radio control just after; the plane moves again its servos depending of your TX commands.

These situations can switch over very quikly (1-2 secondes for each situation)

Conclusion : I 've lost control and I've crashed my plane with brief tops radio, because the plane switched to circle/manual very quickly.

2. Secondly : Failsafe event is not temporised at the source (ie : timer in RX failsafe is impossible in FRSKY for example), and it's impossible to leave servos in last good position during losing radio (arduppm?)

Solutions for minimal crash :

• Buy a RX with only trottle channel failsafe (like futaba) and configure timers on radio losing event (1.5 seconds circle and 20 seconds RTL)

• OR Change APM code on failsafe detection (that i did) :

  On the radio : - generate heart beat on channel 7 of your RX (easy with ER9X), cable this on a free channel on APM.
  - disable failsafe mode on your RX (servos positon doesn't change on radio losing event)
  In APM : - detect lost of heart beat with a timer, and activate RTL at the end of this timer
  - test when you regain radio control that APM stay in RTL mode till you decide to change for an another mode.

Results :
- Losing radio for 1 or 2 seconds : my plane continue to fly keeping servos in last good position
- Losing radio for 5-10 seconds : my plane engages RTL mode till I decide to change for an another modes

If it could help...

there are a lot of old parameters from the plane code in the rover, which should be removed for the release

Automatic ESC calibration output rate needs to be change from 490hz to 50hz.
In some ESC calibrating at 490hz result in recording wrong low end point.

Currently, Mission Planner defaults to enable the "Lock Pitch/Roll" checkbox in the PID Config screen. When MP is connected to a TradHeli, this box should not be checked by default. Helis typically have very different pitch/roll values, and this checkbox can cause problems when trying to tune PID's.

Either remove constraint or offer additional API for setting PWM.
Thanks!
Jason

void APM_RC_APM1::OutputCh(uint8_t ch, uint16_t pwm)
{
pwm=constrain(pwm,MIN_PULSEWIDTH,MAX_PULSEWIDTH);
pwm<<=1; // pwm*2;

switch(ch)
{
case 0:  OCR5B=pwm; break;  //ch1
case 1:  OCR5C=pwm; break;  //ch2
case 2:  OCR1B=pwm; break;  //ch3
case 3:  OCR1C=pwm; break;  //ch4
case 4:  OCR4C=pwm; break;  //ch5
case 5:  OCR4B=pwm; break;  //ch6
case 6:  OCR3C=pwm; break;  //ch7
case 7:  OCR3B=pwm; break;  //ch8
case 8:  OCR5A=pwm; break;  //ch9,  PL3
case 9:  OCR1A=pwm; break;  //ch10, PB5
case 10: OCR3A=pwm; break;  //ch11, PE3
}

}

Current DO_JUMP behaviour is sometimes difficult for users to understand as these things are counter-intuitive:

• putting a DO_JUMP as the last item in a mission causes it to be ignored. Putting a "dummy" WP after every DO_JUMP fixes this.
• the "repeat" value for DO_JUMP is decremented in-place in the EEPROM, resulting in odd behaviour when missions are restarted ( eg, have a DO_JUMP set to repeat 3 times, then fly the mission in its entirety, and when the mission is restarted, the DO_JUMP never executes, as its decrimented to zero ). re-loading the mission from the GCS fixes this temporarily, but it happens any time a "mission restart" occurs.

Lets discuss this, and try to make it "more obvious" for user/s, one way or another.

The new multi-step gyro calibration routine leaves the copter at a tilt. No remedy, because starting at this much tilt will result in a fatal crash before you could do autolevel or ch7. Auto-Calibration on boot and manual calibration are gone (15s disarm motion), no help there.

Downgrade back to 2.8.1 leaves the "Level" button in the MP unusable, because it hangs on 2.9+ and doesn't accept any input.

When CH7 used to enable/disable sonar it doesn't work properly.

ArduCopter.pde:1994 (line numbers from ArduCopter-2.9-release tag)

case THROTTLE_HOLD:
// alt hold plus pilot input of climb rate
pilot_climb_rate = get_pilot_desired_climb_rate(g.rc_3.control_in);
if( sonar_alt_health >= SONAR_ALT_HEALTH_MAX ) {
// if sonar is ok, use surface tracking
get_throttle_surface_tracking(pilot_climb_rate);
}else{
// if no sonar fall back stabilize rate controller
get_throttle_rate_stabilized(pilot_climb_rate);
}
break;

i.e. only sonar_alt_health used, but it's updated only in sensors.pde:35 - read_sonar()
But when sonar disabled with CH7 only g.sonar_enabled changed, and read_sonar() not called anymore. Thus if before disabling sonar with CH7 sonar_alt_health was good - it will be still used, but sonar_alt and sonar_rate not updated.

Request for an audio and a visual notification/warning on the Mission Planner HUD when a failsafe condition is encountered.

Mine is set to Auto yet always reports a declination of -0.3, I'm at -18°10' (W)

something is causing a timeout in ArduPlane autotest log dump

This afternoon I powered up my quad and was watching the MP, eventually I had 11 satellites and a gpshdop of 0.81.

My home postion however remained at the point where I flew this morning, 5530m away! It stayed like this for the whole flight and was like this when I landed.

Correct me if I'm wrong but I understood the home position is set on either 3D lock or arming postion?

If that is not my home position why does the MP say "DistToHome"?

I recently tried some long distance flights flying with FPV / APM2 / APv2.68 and I had a few failsafe occurances while in Stabilize, FBW-A and AUTO, (VTx interfering with RCRx). In all cases the failsafe worked correctly however some shortcomings in it's implementation became apparent.

First: after one second of lost signal the APM goes into circle mode, however in at least one instance I worringly lost a lot of altitude, fortunately I had some to spare, so could this be changed rather to loiter so that position AND altitude are maintained?

Second: After 20 secs the plane will RTL however 20 secs feels like a VERY long time in that situation, 10 secs would be much more appropriate (although if the plane was in a loiter and not loosing height it would not feel so long).

During Auto Mode operation, if the rover mode is taken to Manual Mode and then returned to Auto Mode, the rover will return to the home waypoint instead of continuing on to the waypoint it was headed for.

This will be the RC channel for learning waypoints. It should default to channel 7 in LEARNING mode

The GCS telemetry failsafe option is no longer visible in the MegaPlanner v1.2.29 for ArduCopter v2.8.1.

While flying, i changed to Joystick Flight Control using APM Mission Planner. When i switched out, the RC controller was locked out from Throttle, Pitch, and Yaw/Roll. The mode change channel (8) was still working and was able to bring the plane back with RTL and it made a forced uncontrolled glide in for landing in manual mode(i did not have auto land set up). I performed several ground checks on the bench top and found the following. Every several times (about 1 in 10) when disabling the Joystick through APM, it will lock out both the joystick and the RC controller, though in APM it reads that the Joystick is not enabled. If the joystick is re-enabled it regains control. If the joystick is then disabled, the RC controller typically regains control. It appears as if there is a handoff error either in the APM Mission Planner or the APM2.5 code that is causing the RC receiver commands to be ingnored and preventing the joystick controls from being sent. My current configuration:

APM: 2.5 with Arduplane 2.68
APM Mission Planner: 1.2.31
Datalink: 3DR radios, tried at both 128 and 250 airspeeds with ECC on and off
Aircraft: Slowstick
Transmitter: Futaba 9C with Spektrum Module
Receiver: Spektrum 6 channel park flyer.

I can provide the Mission Planner and APM logs.

Currently, when Auto-landing, the code will naturally shut down the motors on a multi-rotor when it bumps the ground. This is because the controller moves the throttle setpoint towards zero. However on a heli, all that happens is that the throttle moves down, creating negative pitch, pushing the heli into the ground. This is harsh. And the motor continues to run indefinitely.

The controller must be modified for helis to limit negative collective to some reasonable setpoint. Further, we need some sort of system to signal the ESC to stop when we have confirmed we are on the ground.

Hi,

I am using an AMP 2.5+ along with the XT60 APM 2.5 powermodule and for some reason the APM will not hold (store) the APM Ver setting. It correctly stores the Monitor, Sensor, Capacity and APM Input Voltage settings, but only stores APM Ver temporarily (per battery), so if you disconnect the battery and put in a fresh one you have to re-input APM Ver.

I am using Mission Planner version 1.2.27 (mav 1.0)
APM 2.5+ with Arducopter Version 2.8.1

Issue occurs when using USB link or Telemetary (3DR 433 radios).

Thanks

I think it would be nice if it were possible to name APM boards (PX4s and other compatibles as well), like you can with a *nix computer, and have this name displayed in the Mission Planner and CLI, and maybe appended to the log filenames. So users and devs with multiple boards can easily identify which one they are using or where certain logs came from.

The rover currently drives backwards in short failsafe! It sets the throttle to RC3_MIN, which is reverse. We should just remove the short failsafe action

Think i found a small coding error in the 2.9 release, in init_ardupilot(), system.pde, line 292:

if FRAME_CONIG == HELI_FRAME

should probably be

if FRAME_CONFIG == HELI_FRAME

Currently, the code does not adequately determine if a Heli has plausibly taken off. It is entirely possible for a heli to be armed, and the throttle to be high, without having left the ground if the rotors are not turning yet.

Current Code:

if (!ap.takeoff_complete && motors.armed()) {
if (g.rc_3.control_in > g.throttle_cruise) {
// we must be in the air by now
set_takeoff_complete(true);
}
}

Needs to be something like:

if (!ap.takeoff_complete && motors.armed()) {
if (g.rc_3.control_in > g.throttle_cruise) {
// we must be in the air by now
set_takeoff_complete(true);
}

if FRAME_CONFIG == HELI_FRAME

if (h.rsc_mode > 0 && Ch8.control_in <11){
set_takeoff_complete(false);
}

endif

        }

This will check if we are using the rotor speed controller, and if it is running. This does not protect for cases where the rotor is running, but slowly. Or if the user is not using the rotor speed controller at all, but it's all we can do for now.

I think I will tackle this by adding a new bool to the AP_MotorsHeli class, which is "Rotor Run-up Complete" which we will confirm than the Motors have been running for a suitable period of time.

Further, I'd like to add some code to the auto-take-off code which will not even attempt to leave the ground until run-up is complete.

Need some way to do speed scaling in rover, to prevent it rolling over in a hard turn

Create a filter on the servo output that runs when disarmed only, which will help to reduce servo noise and activity when the heli is sitting on the ground.

The ground stations need to understand LEARNING mode (mode 2). Currently mavproxy displays it as STABILIZE mode.

Presently the "learning" function in the ArduRover2 code is broken. Linus and I have looked at the present code, but cannot tell what needs to be restored and where. The availability of the "learning" function is very valuable when there is no Google Earth connection available for the MP when in the field.
Regards,
Tom Coyle (TCIII)

When the rover reaches home on RTL it should stop, not circle!

I'm getting sched debug output that looks like this:
Scheduler overrun task 0 (944/900)
Scheduler overrun task 5 (1708/500)
Scheduler overrun task 0 (916/900)
Scheduler overrun task 5 (1652/500)
Scheduler overrun task 0 (932/900)

0 is GPS_update, and obviously 50us is no big deal - we can just change the worst case time to 1000.
5 is run_nav_updates. I'm sure that the problem is when run_nav_updates calls run_navigation_contollers (sic - who named that function? :-) )

Leds attached via transistor switch to out 4 (COPTER_LED_1), LED_MODE=1. On ArduCopter-2.9-release it work. Maybe some config problem with COPTER_LEDS?

the pysim code sometimes gets a floating point overflow error, possibly due to large timesteps on an overloaded machine.

(Not urgent but it would be awesome if the function of these could be restored somehow)

Mission Planner v1.0.98 connected 100% of the time to the APC220 Xbee replacement modules (http://wiki.openpilot.org/display/Doc/APC220+Transceiver+Telemetry).
There was some packet loss, it was however useable to change PID's and get HUD data.

From MP 1.1.26+ they did not connect at all.

Win XP or Seven, same conditions/cable/port and baud, etc.

autotest suite does not test trim and autotrim functionality.

When I click on the map during a flight and select "fly to here", it works perfectly and asked me what the altitude of that should be. When I put that altitude in, it is always tries to go 600 feet higher than the number I put in.. I suppose the altitude is somehow added to my field elevation number, but I would rather it just work similar to the waypoint alt.

Hello,
Since Arducopter 2.9 already uses mediatek 3329 GPS firmware version 1.9, would be great to be able to interchange between arducopter/arduplane firmwares without changing GPS firmware.
Since this GPS firmware upgrade improves GPS precision in a decimal place precision I think arduplane would take also great advantage of this improvement especially in auto land.
Regards,
Miguel