Homepage GitHub

Yukon management thread

The Yukon project is currently suffering from a lack of well-defined long-term vision which complicates planning and management. In order to address this, we just convened with @TSC21, @arrowcircle, and @ivodre, and drafted out the following plan for the immediate future:

  • Nuno will document the activities outlined in the active Statement of Work that he has agreed to with Amazon on GitHub to ensure that they are visible to the other team members.

  • Oleg and Nuno will be collaborating on the above activities as they see optimal. In particular, Oleg will focus on rectifying the shortcomings of the existing CI/CD infrastructure. I have requested Scott to grant us more autonomy on tool selection.

  • Ivo will familiarize himself with the context, read the existing relevant discussions on this forum, skim through the UAVCAN specification, and decide whether he wants to commit to this. If yes, he will join the project in the form of a project manager or a product owner, defining the abstract project documentation and deriving low-level requirements such as storyboards, etc, as well as performing other related tasks appropriate for a PM/PO.

Here is the list of the reading materials for Ivo:

The group will reconvene on Monday, 17:00 EEST / 16:00 CEST at https://whereby.com/Zubax. Somebody will post the notes from the call here.

One thing we should discuss at the next call is whether it is possible to aim for a minimal practical demo to be presented at the upcoming PX4 Developer Summit.

FYI @scottdixon @dmitry.ramensky.

1 Like

@arrowcircle says that the number of project management boards on GitHub should be reduced. He also says that we need to define concrete requirements for the demo canvas mock-up starting with the exact list of nodes; we agreed to model a trivial tailsitter containing the following nodes:

  • one FMU
  • four ESC
  • two servos
  • one airspeed sensor

The exact subjects and services are TBD.

@arrowcircle should look at the ROS Computational Graph documentation to better understand the concept of real-time distributed pub-sub:

It is hard to organize our activities because we still don’t know what the specific objectives are. @ivodre is going to help us here. He is willing to invest up to 15 hrs/week (best case) into this project but the duration of this commitment is unknown. We are unable to determine what is the required minimum level of involvement from his side as a product owner so we are a little in the blind but hopefully things will clear up in the near future. Ivo will be asking questions via Slack until he has a clear picture of what we are trying to do, I will make sure to accommodate. While @tsc21 & @arrowcircle are working on the demo, @ivodre will be learning the background and then working on formulating the plan & requirements.

Regarding the PX4 summit: @tsc21 is hesitant to commit to anything citing conflicting personal arrangements so at the moment we are going to avoid stating anything related to Yukon but will keep our options open; hopefully the organizers will be flexible enough to admit late replanning.

The next conversation will take place on Wednesday during the regular weekly dev call.

As discussed, Ivo is expecting to get sufficiently involved by the end of the current sprint, which means around early July. Meanwhile he is observing the ongoing work.

OIeg is going to submit pull requests fixing the CI/CD issues as already mentioned here earlier. He is supposed to have full access to Buildkite now.

The next call is tentatively planned to Friday 17:00 UTC, pending confirmation from @arrowcircle.

We have a new record – approx. 2h on the call. There should be an emoji of a unicorn puking rainbow.

Tomorrow morning @tsc21 will be working hard on defining the low-level requirements for the current sprint. We may or may not have another call to discuss that afterward.

Here is the image of the drawing I made on the (not so) white board:

Important things on the image:

  • Inputs are on the left, outputs are on the right (GUI Tool – Next Generation)
  • The local data manipulation entities – namely, the subscriber, the getter, and the plotter – are outside of the scope of the current sprint but the design shall allow their introduction later.