Hi All,
Here is the Agenda for June 26:
- Dev Summit Debrief and summary
- Component maintainers
- v1.9.1 Maintenance Release
- Stick feel
- UX
More topics might be added based on the Devcall list on Github or by commenting here.
Dial-in:
Join Zoom Meeting
Zoom Video
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference…
One tap mobile
+14086380968,946175205# US (San Jose)
+16468769923,946175205# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 946 175 205
Find your local number: https://zoom.us/u/ad94Pgv9yQ
Wednesday, June 26, 2019
10:10 AM
Agenda
- Dev Summit Debrief and summary
- Component maintainers
- v1.9.1 Maintenance Release
- Stick feel
- UX
From https://discuss.px4.io/t/px4-dev-call-june-26-2019/11631
Action Items
David - look into USB plug issue
CUAV boards - noise on power supplies
David to post updates on CUAV board connector bringup.
Lorenz - Followup on V1.9 announcement
Thomas - will check send invite
Important Dates
Meeting Details
- Date and Time: 6/26/2019
- Location: Zoom
- Attendees:
Announcements
Discussion
CUAV boards
- Bootloader V5 bootloader being used? Are these being CUAV. Wrong rev on version ID. IS this a systemic issue. Revision - we cannot be sure if it is a new revision? David gave them a version and revision ID. We assume this is a build issue or bug in the firmware.
- Power module 2 connector doesn’t bring voltage onto system. What is the use case?
- SBUS out does not work.
- GPS fix LED - do we support that.
PX4 V1.9
- Did we ever announce it formally? Social media/dicsuss etc.
- Ready to announce. Just dropped because of summit.
- Use V1.9 despite 1.9x update.
- Need to push out a textual description of the
Dev Summit feedback
-
Great response
-
Discovering holes in community process.
- Next week -
- Week after - Lorenz is out.
-
In person discussions were very useful.
- Jinger preparing notes.
- Summit was much better than Dev call.
-
Lead on subject needed, then add a whip.
- Interrupt when we go down into the details
- Try to keep the call moving with detailed follow-up
-
Working groups? One day a month? With informal presentation
-
Schedule, with some process to take action and followup
-
Mavlink Dev call - bi weekly
- Need to get better, but still reasonable amount of work done. Thanks Hamish!
- Every two weeks - focused on standard some communications.
- Should this be led by component maintainer - that can provide context.
-
Dilution of efforts?
- During dev, announced that maintainers are contributing to upstream
- How do we know where other developers fit in. without clarity on other high level priorities.
- Stale expectations? Like Dshot?
- Should this call be the update for the “real roadmap”?
- (Daniel) - calls are not frequent enough for people that need decisions to be made.
- Suggest local deep dive groups. Monthly session on this? Also reconsider roadmap at that time? Presentation, video, update - allow component maintainer to stay relevant
- How do we ensure we know the priorities of the end users.? (broken airframe configuration etc.)
- Are we realistic on what we actually support based on what is being actively supported
- Lightweight file per directory to represent the support of that module?
- Daniel - lets go through everything and be realistic. Test, does it work? And drop?
-
Lorenz - component maintainers
- Purged the list to remove absent people.
-
https://github.com/px4/firmware#maintenance-team
- Need to ensure that these maintainers are on the call.
- Timezone? Should not be during business hours for some of Europe
- Lorenz - for most people late in the afternoon works well Europe (Nunio, Paul Riseborough are outliers.)
- Overlap? Each item needs a second component maintainer. Second is assumed to be filling in , but partnership/equality is also good.
- Alignment on roadmaps - get pushback
- Schedule tool. Gant charts?
- Bigger issues within git. Own the issue and keep updating it.
- Do we really use Project boards? Lorenz found that project board was useful and gave good awareness.
- Daniel - milestones? David - can we nest the roadmap in to each board use the top level issue. Take ownership of release blockers board - that seems to be the issue. Assign owners and pass on to second in charge. Organized to the person, and they manage it.
- Everything can be found quickly.
- Visible if backlog is creeping up
- Rundown with component maintainers to dive into details and triage and loadbalance
- If you want to track something , then you need an owner, and that owner will be a component maintainer.
- Daniel - each PR needs a response to set expectations. (we see the issue, but cannot address - open for help)
- David - root source of “buckets” for issues - is project board structure within that tools. Spend some time on process.
-
Thomas to add new people to invite
-
UX issue
- Matthias
- Mapping stick input to acceleration while in normal position mode
- Yuneex H520, “altitude mode is more intuitive”
- Reaction to stick based on accel .
- Compared with Ardupilot
- Controller changes needed to have it work with real units M/S^2
- Tilt limit not completed
- Torque limit missing
- Goal was to be backward compatible.
- Testing for usefulness. Limited testing to date
- Could be moved to default and
- Lorenz - not disagreeing. Building more options that rely on parametrs. There are too many. You can’t decypher or find many of these options.
- Some systems fly better with airmode. But we need to invest time to autodetect when this mode is needed.
- Config should be about true user preferences and not a tuning exercise.
- Beat - (airmode) risk is that vehicle will shoot up.
- Check for rate tracking, oscillations, add limit to alititude?
- Too close to ground - disable
- User perspective. Fly system in postion control, look for excursions based on GPS velocity alone -adds robustness. Racer has no GPS, so it can be made visible to acro mode racer. Need to classify user and vehicle profiles a bit more. This could be used to pre-configure setup for particular needs
- Airmode - matthias - nothing to do with GPS. Connect motors in wrong order - airmode will …rate error , vibration playing a role.
- NEED detection for reasonable use cases.
- Daniel - Be realistic for parameter configuration, minimize the surface area for adjustment
- David - review what parameters need to be exposed. What the priority is? Infer the meaning. Lorenz - source of crash and reliability.
- How will this get implemented? How do we reduce?
- Can we infer things from old parameters? (Not really)
- Matthias, more comfortable with parallel path so that new methods can be tested.
- Safety manual in QGC. Should be presented in a UI method.
- Daniel - For airframes we have now -should drop
-
https://github.com/PX4/Firmware/compare/master...mcsauder:pr-airframe_cleanup
- Size and scaling - determines the parameters for generic
- 3-4 frame sizes
- Julian - tuning guide is in depth. Should we set a few default sets of parameters to start? Suggestions for parameters.
- Declartive airframe configuration. Metadata for outputs included?
- Matthias - how could setup workflow be drafted - Gus/stephan needs to know what should be in there. Agree what is needed?
- Daniel - David - can QGC - Upload parameters then highlight which have changed?
- Click on airframe + defaults for airframes
- If we change the defaults - they don’t necessarily get them
- Use previous setting, (but they are in a script) . Maybe they should be in a parameter file instead.
- Need requirements, also need to brainstorm with Gus and Don on what’s possible and what are the pain points.
- Pull requests:
- Run stackcheck on bench - Julian
- Mark to do stackcheck build on PX4FMUV5 stackcheck- boot with console connected. Do with Each of these PRs
