DEV call 27 Mar 2017 4pm PST = 27 Mar 2017 2300 UTC

CraigElder · March 27, 2017, 11:01pm

Copter

3.5 Update
Vision Update

Plane

nice flight of tilt-tri-quadplane
fixed quadplane transition bug

Issues

https://github.com/ArduPilot/ardupilot/pull/5935
https://github.com/ArduPilot/ardupilot/pull/5930
RC Failsafe handling issue?
-Helicopter rotor speed control setting does not check for RC Failsafe. I knew this was weak, but assumed that the RC signaling was deterministic. I tested RC Failsafe action a few times, and it seemed to work.

RC outputs during Failsafe appear to be non-deterministic. I have logs indicating that ~30% of the time, as RC comes back, just before the Failsafe flag is cleared, the RC output appears to publish an erroneous number.
During RC Failsafe, the RC library is logging 874, when no pulses are being sent. Why? It should probably be sending 0, or maybe -1, something that very clearly indicates to consumers that is not a real value.
874 could be misinterpreted by downstream users of the data.
I suspect, that as the failsafe clears, a few 874 signals get out sometime. That is likely what is triggering the short motor shutdown.
Properly protecting the RSC logic with Failsafe checks will solve the problem for helicopters.
But I think the underlying issue with RC library should be looked at, to prevent future problems.
Basically, I believe helicopter was the canary in the coal mine.

AP Sync

Hardware

CANBus Update
Joule carrier requests- sany specific needs, now is the time

GSOC

CraigElder · April 4, 2017, 2:39pm

10:02am - Tridge and tilt-rotor tri-plane
Rolfe had a great success!
Not first flight, but really nice!

Batteries were a little underpowered
Nice smooth transitions
This was a test flight of some new transition code
Much interest in various other tilt-rotors
A four-rotor tilt rotor, for example

10:04am - tridge and quadplane transition bug
Tests usually go altitude-control-mode to forward flight
E.g. qhover or qloiter to auto mode
Marco went from QSTABILIZE to FBWA
Cause found and fixed
Z-controller wasn’t initialised at time of transition
Altitude target and z-velocity target weren’t being initialised
Would almost shut the vertical lift motors down
Lots of lost stability
And altitude….
Should be able to do better than current, too
When moving from pilot-throttle to auto-throttle
Should smooth from one to the other
There are implications for heli too here with collective
In heli we set the integrator to smooth things out
Sets to current user’s throttle
Tridge does fancy things with integrator based on forward speed
Low forward speed integrator is set to zero then starts setting a negative integrator if you have lots of forward speed
Fixes the “tip up” problem because elevators have a lot of authority
We don’t test all transitions in autotest
Plane in SITL is perfectly balanced
Real planes aren’t

10:14am - tridge and i2c
MdB has had problems with airspeed sensor
Digital noise spikes in reported reported temperature

Bus noise
PR in place

Implements a digital filter in the i2c peripheral
Should have had it a long time ago
Have them for RC input
Oversampling filter
Gets rid of spikes
Built into the STM32
Off by default
Now turned on
Needs testing on Aero
May fix some compass issues there
Filter frequency changes based on i2c bus frequency
So Aero may need tweaking

Should reduce noise in lots of places
Hasn’t fixed Michael’s problem
But probably still worth it
Works well on FMUv2 for tridge on bench
Other users have had noise issues on their i2c bus
Less on is “where is our CANBUS?”
“Soon, soon” - Jani

10:27am - CANBUS
Great progress in last week
Good test flights from Eugene
CANBUS gitter channel
Nasty bug found based on template-based API
norm()
Typo where norm(x+y) vs norm(x,y)
Those are… somewhat different
The template-based stuff doesn’t give type-checking like the old code did

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_Math/AP_Math.h#L167


      
          */
          ftype wrap_PI(const ftype radian);
          
          /*
          * wrap an angle in radians to 0..2PI
          */
          ftype wrap_2PI(const ftype radian);
          
          /*
          * Constrain a value to be within the range: low and high
          */
          template <typename T>
          T constrain_value(const T amt, const T low, const T high);
          
          template <typename T>
          T constrain_value_line(const T amt, const T low, const T high, uint32_t line);
          
          #define constrain_float(amt, low, high) constrain_value_line(float(amt), float(low), float(high), uint32_t(__AP_LINE__))
          #define constrain_ftype(amt, low, high) constrain_value_line(ftype(amt), ftype(low), ftype(high), uint32_t(__AP_LINE__))
          
          inline int16_t constrain_int16(const int16_t amt, const int16_t low, const int16_t high)

powf() is inefficient; we shouldn’t be using it when doing n*n!
When this is merged we’re going to have lots of space before hitting 1M limit
Next thing to add is the FW upgrade over uavcan
E.g. ESCs

10:37am: Randy and Copter
Copter 3.5rc3 went out

github.com

ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt

ArduPilot Copter Release Notes:
-------------------------------

Release 4.5.0-beta3 14-March-2024

Changes from 4.5.0-beta2

1) Board specific changes
- added PixFlamingo F7 board
- support ICM42688 on BlitzF745AIO
- fixed IMU orientation of CubeRedSecondary
- enable all FPV features on SpeedyBeeF405WING

2) System level changes

- improved robustness of CRSF parser
- reduced memory used by DDS/ROS2
- added filesystem crc32 binding in lua scripting
- support visual odometry quality metric and added autoswitching lua script
- allow for expansion of fence storage to microSD for larger pologon fences

This file has been truncated. show original

Small fixes mostly
Tridge’s SBUS failsafe fix
Gimbal servo-reversing fix
WPNav-loiter-speed bug fix included
Cleared up the fence pre-arm checks a bit
Not a lot of testing, but so far so good
Randy looks at Copter 3.5 - ArduPilot Discourse for issues
Several good reports
Solo with 3.5
Paddles to Pedals?
Matt
On train during call, so Randy ran down the Solo list
http://discuss.ardupilot.org/t/testing-3-5-on-my-solo-she-flies
Working on a parameter file to get it flying better than the original 3DR
Thinking of doing a green-cube set of parameters, too
Problems:
LEDs are always green
Should we have a separate build just for Solo?
Tridge thinks no
Because we have FMUv3
OreoLED could be dumped into FMUv3
Aero we don’t have a choice - we have to have a separate build
Build time is a problem
Matt reports FMUv2 works badly on Solo
Tom thinks we should have a separate build
Baked-in PIDS etc
Solo users don’t use parameters
Kelly (Solex) is really keen to support ArduPilot master
Including helping uploading new firmware
No tones
EKF3 issues
Long calibration times
Gimbal goes limp
Not sure why it is working in the first place
Impressive that this is working!
In-tree driver stuff was a big part of allowing Solo to work on master

Is green cube needed?
When running master? No.
Except you don’t want to fall out of the sky
Is OK when de-tuned
Black Cube (2.1) can be modded
Puts 5V out to ESCs
Bad loop times
http://discuss.ardupilot.org/t/autotune-mishap-with-ac3-5-rc-2
Vehicle flipped over and it was bad
Haven’t gotten to the bottom of this one yet
Could be hardware, but bench testing hasn’t fixed it
Not sure how we can tackle this one
Remaining-memory goes in PM
Need to add dataflash-logging of perf counters
https://github.com/peterbarker/ardupilot/tree/df-real-perf-messages
Maybe this is DMA SPI?
Option to turning it off?
Hardware fault causing interrupt storm?
Unexplained crash which may stop us releasing
Will be a -rc4

11:09am - Randy and vision
Important progress
SLAM
ORB-slam2
Dan has been helping out a lot
Pierre has been helping

Now poses pose and location to mavros
It then flows into ArduPilot
AP only currently accepts, doesn’t use these
There are issues with the messages
Frame of reference is wrong
Location is in an odd scale
Not in cm/m
Can’t tell distance if no stereo

will move to using stereo
based on APSync
Will enhance to include ORB
Timing is really important for this stuff says Paul
Fnoop made Handle TIMESYNC mavlink messages by fnoop · Pull Request #5888 · ArduPilot/ardupilot · GitHub to help us sync
OpenMV camera for precision landing?
Makers have offered samples for those wanting to get it working

11:17am: MdB and barometers

github.com/ArduPilot/ardupilot

Baro: Temperature Related Fixups

ArduPilot:master ← WickedShell:wickedshell/baro-eas2tas

opened 07:41AM - 24 Mar 17 UTC

WickedShell

+63 -48

**TL;DR** #5889 is to complicated, this is better, and fixes an over estimation …of altitude. --- This replaces #5889. It was to complicated, and resulted in different behaviors on copter depending upon if you took off with/without GPS (and when you took off). The core problem with the EAS2TAS calculation that #5889 was attempting to fix was that the source of temperature for EAS2TAS is quite important for ensuring that we aren't providing a reasonable estimate of EAS2TAS. The problem with master is that we double count the affect of any change in altitude, causing the aircraft to change the ratio faster then it actually was. This PR corrects the use of double counting the temperature for altitude. However while doing that a rethink of how we selected calibration temperatures was needed to further improve accuracies. @priseborough and I discussed a couple of options and the best option was to select an external temperature source if we had one available (airspeed on plane, in future work we can incorporate the concept of external baro sources) if there isn't an available external temperature source we can take the internal one, but given it's tendency to be high we can clip it at a reasonable value (35C covers most tropics/hot environment users safely while still improving the reported altitude for users in cooler regions). The concept of clipping the external temperature source isn't new (we were clipping it at 25C, but we were using it in EAS2TAS which we adjusted to quickly as well) While implementing the rest of this I came across the fact that the actual relative altitude calculation uses the unclipped barometer temperature as well. This is actually quite poor if your barometer is reading 30 degrees warmer then it actually is (which is very common). This results in a linear error of the aircraft estimating it's higher then it actually is. Using the data collected by the [LOHAN](http://diydrones.com/profiles/blogs/pratchett-soars-to-31-000m-for-pixhawk-test-flight) project provided a great source of data to demonstrate this effect. The red line is the altitude ArduPilot would report using the current temperature selection method, the green line is the reported altitude if we were to clip the temperature sensor at 35C, and the blue line is the true altitude. ![figure_1-5](https://cloud.githubusercontent.com/assets/567688/24284194/4875f310-1027-11e7-8d79-e453d08ec8c6.png) ![figure_1-6](https://cloud.githubusercontent.com/assets/567688/24284195/487b2934-1027-11e7-9d60-5a090640e939.png) As you can see there is nearly a 200m altitude error at 2km of altitude. That means we are overestimating our altitude by around 10% and flying lower then intended. On a long terrain following mission this would be especially problematic (Sidenote: GPS altitude is almost always a better altitude source for long missions or terrain following). If we had instead used the 35C clip approach (what this PR presents) we would instead have around 80 meters of altitude error (around 4%). This PR clips the temperature source used for all altitude estimation at 35C as well. The final step that this PR takes is the GND_TEMP parameter can now be set to provide a true estimate of the ground temperature. During a preflight you can provide the temperature to this parameter (in degrees Celsius) and use your true OAT for the best result. (NOTE: Adjusting the value by a significant amount from the estimate will cause a step input, and upset the EKF. It will recover without any problem, but I don't recommend trying it in flight. For almost all users this is overkill, but for certain use cases the ability. Because GND_TEMP is no longer the authoritative source on what ground temperature datum is being used this also now logs the current value of the ground temperature data in the BARO message. Finally I recreated @khancyr's [patch](https://github.com/WickedShell/ardupilot/commit/f7dfac7adebec12b99d44ec8a4de79e20a7c427f) because I couldn't figure out how to easily pull just that patch in from the branch.

Problems with current estimates, we think we’re higher than we are
Linear error
Proposes solution is to apply same solution as EAS2TAS
Philip asks about supplying a good external temperature
Would work very well says Paul and MdB
Drops the GND_TEMP parameters
Could manually set this to override the sensors
Here+ provides external Baro+temperature
Tridge points out that most vehicles have an external compass, and most have thermometers associated with them
New framework makes it easier to use them
We should use them
Particularly on quadcopters
May need to allow for the baked-in-Sun followed by cooling-while-flying issue
TEMP_SOURCE parameter?
Priority order?
Auto should be external-airspeed, then external-baro then external-compass then internal baro

3930 was merged
Maybe we want a transition from BARO to GPS when we get higher
Reporting for ping etc has to be barometric altitude

11:28am: RC failsafe with Rob

PixHawk1 frsky receiver (x6r?), almost certainly SBUS, no-pulses
Flying at long-range and moving into and out of RC failsafe
Continue-in-auto set
Remote observers on ground
“Was it supposed to lose a bunch of altitude?”
10 radio-failsafe events in logs
On 3 of them the motor shuts off for a short period of time then restarts
Immediately at end of radio failsafe

Copter 3.3
Issues believed to still exist
Luis reproduced the the “874” issue
Francisco First issue: ardupilot/ArduCopter/heli.cpp at master · ArduPilot/ardupilot · GitHub ← no protection for radio failsafe being active
Franciso: Second issue: apparently SBUS with no pulses is changing input to 874 instead of no input
Setup is same as tridge’s
Tridge hasn’t seen the issue
OBC had custom patches
Tridge wants to be told how to reproduce it
He has some theories
No sync in sbus
Sbus is a crappy protocol
No crc
No framing bytes
Framing is done by gap-between-bytes
Parity bit per byte
Stop bit
Might be getting desynced
Could be a threading/locking issue
Maybe add an attenuator
Range-test mode + microwave oven might be good enough
Tridge offers a recipe for browning a TX in a microwave……
RSC should be de-bounced
There’s a slew-rate limiter in 3.4
Except it was the interlock engaged/disengaged
So the interlock should be debounced!
Can’t rely on receivers!
Maybe an OpenTX issue?!
No pulses being received says Luis yet 874 being reported

11:45am: land-complete while in flight
Copter 3.3
Unexplained throttle-up after a loss in attitude
Maybe we should add rangefinder checks for land-complete
Switches on landing gear
Negative thrust to keep things on ground
Working with Mr Dyer
Uni professor of flight dynamic

12:02am: Philip and hardware
Hardware requests for Jewel
Next carrier board for the Cube
Edison is OK
But Jewel is awesome
What do people want in terms of connectors to the Jewel?
USB-C out
Ping Philip on it

12:04am: Olivier and GSoC
Last week for proposals to get in
9 proposals so far
Still kinda private information
A couple which are very good
A couple which need a lot of work
Starting Monday a 1 month selection period
Tridge thinks 3 proposals are really good
Some more might be salvageable
Some are junk
All have been replied to to give them a chance
Some tridge’s reply was longer than the proposal
Should see 3 or 4 more good ones coming in this week
Apparently some students didn’t realise seats were limited…
Google’s sample proposal is very short
Likely to have more good proposals than spots
Asking other companies to sponsor
$6,000-$7,000 US
Scales according to cost-of-living-in-country apparently
Mentor conference afterwards
Several students present on the call