Servers by jDrones

Dev Call Jul 10, 2017 2300 UTC

(Craig Elder) #1

Contribution of the month


  • AC3.5 release update

Rover update

Plane update

plane 3.8 progress,
new io mixer for plane


Discourse Update

GSoC updates (Sebastian, Pierre, any other GSoC students available can give an update)

(Craig Elder) #2

Attendee count (max): 27

09:02am - Contribution of the month
Please get your contribution of the month nominations for May in!
Email was sent by Randy

09:03am - Copter with Randy
-rc9 and -rc10 went out
GPS fixes and EKF fixes, minor things
Changes for the Intel Aero dictated -rc10
Plan was to do final release yesterday
But MdB found some GPS issues
Septentrino GPS
3DR GPS also stops being recognised on 3.5
Something wrong with autoconfig?
Will put out 3.5 as soon as possible
Preferably before next dev call!
Someone reproduced the DSM issue!
Randy’s hardware still needs sorting out
3.4.5 doesn’t work for him!
Possible there are commits in PX4 Firmware which may be addressing issues with PixRacer
Several PX4Flow optical flow complaints
Maybe startup time has changed
Sensor not being detected
Tridge notes there are no retries at the moment
Scan_busses - have it scan for a lot longer
People without OF won’t be affected
Maybe up to a second
Lightware rangefinder should also be configurable for multiple buses/addresses
Almost there!
[09:22am] Heli release?
Will happen at the same time as 3.5
Testing would be really good!
But not horribly broken

09:17am - Rover with Randy
Pierre and Randy have been poking Randy a bit
AP_MotorsUGV class has gone in
Start of the onioning
Peter’s control-modes-are-objects patches to go in next
Startup issue where you get a momentary motor output
Support for wheel encoders is coming in next couple of weeks
Quadrature encoders
May be wired into EKF
Really cheap visual odometry?

09:23am - tridge and plane
Docs are pretty much ready to go!
Tom had some minor points
Probably good enough for getting 3.8 out
Found some issues with mixing while doing docs
Test flew a PR with mixing fixes:
Mixer generation was broken
Manual_rc_mask has come in to allow mixed-output planes be flown in manual in case of failsafe
Bitmask of channels which in manual mode are transferred straight to servo output
Default is normal mixing but subset of channels can be passed straight through
Absolute control in manual mode
MdB has some issues with the patch, particularly with the trim values
1500 is magic
Limitations in the PX4 mixer bite here
PX4 only has angle not ranges
After the same mixing answer when in bypass/not-bypass mode
It will certainly be better than it was
E.g. elevons
Replace mixer firmware?
Too large a change for putting into 3.8!
A lot of retesting would need to be done
Too risky at this late stage
Many issues were raised on the agenda to look at for Plane
Crash bugs only at this stage, please!
Quadplane auto-disarm is thus not a candidate for this release
Not disarm at end of landing
Won’t continue mission past this….
Maybe a parameter to the VTOL land operation that says whether to continue onto next one
To avoid doing odd things to people who already have missions out there
Maybe a mission command?
Same problem present in Copter
Mission logic
Same with facing-into-wind for RTL
Tridge will look at logs
Mr Merlin’s issues will definitely get looked at, as they do seem to be crash issues

09:42am - Peter’s devcall-marked PRs
Nobody on call really knows why these were marked devcall
Peter notes that it is code churn
GCS abstraction discussion ensued
Vehicle-state object
A bit for the attitude information has changed
Then the GCS backends have their own clocks to send messages based on whether the data has changed
Non-permanent information vs permanent information
Push vs pull interface
Telemetry backend
Peter points out this should be the GCS object, FF agrees
Francisco: Yes, I agree with Tridge on this point. Telemetry backends should ask for the information, not be given it
Need to separate information-update from information-push
Missions show the vehicle state object won’t itself contain all of the information
Encapsulated mavlink packets in RTPS was really bad
Can take state out of the state structure
“Information is available to be published”
Tridge has no concerns about these PRs going in, though they probably don’t really move us towards a better GCS abstraction

10:07am - taking ArduPilot code and getting it 178-certified?
Several companies that want to make flying cars want to know whether they can run us in the final product rather than just their test-beds
They need certification!
Cube gold full triple-redundant system
Clients want this certified
Philip says $$$$!
They then ask “how much!”,
Which is a positive but also a problem
JamesP: It’s almost impossible retrospectively, and the ardupilot architecture doesn’t really support it. But it depends the level of 178 compliance you want to achieve.
ArduPilot on manned aircraft is what we’re really talking about here
We currently say “don’t do that!”
But people are doing it anyway
Risks to project?
Liability for killing someone?
Ongoing maintenance of certification is the really major issue
If you wanted someone to get it certified you might say 3 engineers 6 months will get certified to a specific level
But then you might get pressure to not make changes because it would invalidate the certifications
Would be stuck because of the cost of re-certifying
Would have to be a fork
Change the name?
Stuck at 3.5 or 3.6
We continue as normal
If they want e.g. 3.9 certified then someone gets to pay again
Suggestion that a working group be put together
Link a line of code back to a requirement for the software
Every line has to be accounted for here
Only 178-certified operating system is based on Greenhill
Exemption for the operating system is generally given
Advantage to ArduPilot for doing this?
Could find bugs
Nothing stops people from doing this now, of course
Do we cooperate with someone who decides to go off and do this?
Years of effort, millions of dollars
From Chat: To hard to type on the call atm, but certified code I’m good with, but if its getting the code into manned aviation, I’m not getting paid enough, or thinking about the code in a manner for that, and my current contributions would basically stop, and I don’t really want my code flying in manned systems. Not meant as an ultamtium but I don’t want to be working towards enabling manned aviation along the road…
Eugene: every change in code, even lightest will have to be made for recirtification
We currently say, “don’t talk to people doing manned”
If we start are we going to accidentally “bless” these efforts?
Not just flying vehicles
E.g. tractors
Currently proficnc isn’t certified hardware and they don’t pretend otherwise
Canada is doing kinda-certification on UAVs
Interest from people on call on doing 178C certification for planes
EKF is nice!
Luis is already drowning in paperwork with his UAVs!

10:29am - UAVCAN gimbal
Eugene is ready to work on this!
OlliW wants to know what sorts of messages should be exchanged?
There’s a set of messages
Attitude of vehicle and gimbal
Tridge: Would be nice to have the serial-over-uavcan
Could then start with Solo gimbal which is a serial gimbal
And we do have uav-to-serial boards
Could make autopilots much physically smaller if we could get rid of all the uarts!
Jani has a board
Has sent to Eugene
Might be a good starting place for talking to multiple serial devices
Expose all magic serial endpoints as UARTs from HAL

10:50am - Servers and Jani
Several new servers brewing up on Digital Ocean
Hopefully today/tomorrow we can do a swap-over for Discourse server
Swapping will be quite fast
Will hopefully fix missing-images problem
But since we don’t know the root cause, we really don’t know
Currently working on MTA server
Needs to be in New York rather than Netherlands
Firmware and autotest will move to Digital Ocean
One really big virtualised server in Digital Ocean

10:55am - Randy and GSoC update
Working in SITL
Video in a couple of days
Needs to work on threading
Needs to work on moving the vehicle home
Setting waypoints is bad
Need to use some other control mechanism, will work with Randy
Integrated compass, baro, gps and IMUs into SITL
Works through a pipe in SITL
Will be working on two-way communications support to allow for configuration from the processing side to the sensor side
Linux as consumer and SITL as producer?
Will be useful for measuring latency
Linux variant is working but hasn’t been tested on real hardware
Miguel has the hardware
Next milestone should be ensuring we can get kilohertz IMU data
Question as to where to do the filtering
Rate controllers at KHz into future!
Producer or consumer?
Vibe analysis is an extra product which would have to be sent if the filtering was done on the producer
Not to mention raw logging
So best to do the filtering on the consumer