-
Notifications
You must be signed in to change notification settings - Fork 11
October 15, 2021
We're in the middle of planning Demo 2. Planning is important because it smooths out implementation and testing down the road. We've just finished researching some good approaches to our task, and now we need to design our own components.
- Behavior Planning and Controls (Cristian, Jim, Nikhil)
- Perception (Kyle, Ragib)
- Mapping and Processing (Vishvak)
- Data Visualization (Raghav)
(If your notes are missing, please add them)
We're planning out how the goals of Demo 2 should be met.
Many of you are familiar with the V Model, which describes the software development process. Here's the V Model:
I know many of you are eager to get your hands dirty and build this thing, but some clear and thorough planning will really pay off down the road. The more we plan, the easier our implementation will be.
We've already finished our requirements generation (see Success conditions). We're now in the thick of Architecture Design and Components Design.
Basically, each of you should consider how our ROS nodes should be divided and how each node should function.
Our next meeting (next Friday at 3pm in ECSN 2.110) will be focused on component design. Each group should arrive at the meeting with a plan for:
- What ROS nodes (executables) should be developed, including improvements or replacements to existing nodes
- The inputs and outputs of each node
- The internal operation of each node, with as much detail as possible
The result should be design documents from each group, written as Markdown files. For an example of what I'm looking for, see Autoware's localization design pages.
These should take you all four hours of the time I expect from you. Divide them into multiple writing/planning sessions if you need to, but if you don't dedicate the required thought and planning to this, it will be obvious. Be sure to make these design documents as thorough as possible.
Here's which design documents each group should focus on. You can divide these however you want (so that the Behavior Planning Nodes are split up, for example). Please refer to Fig. 2 above.
- Behavior Planning and Controls
- Behavior Planning Nodes
- Control Nodes
- Route Planner
- Perception
- Vision Nodes
- Moving Object Tracker
- Firmware
- GPS
- Front Camera
- Rear Camera
- Throttle, Brake, and Steering Interfaces
- Software Architecture (Josh)
- Safety Manager
- Mapping (Vishvak)
- PCD map publisher
- Lanelet2 map publisher
- Real-time mapper, map stitcher.
- Write design documents as Markdown files
- Send me your top three name ideas in each category by Monday at noon
- Write a brief bio for Dylan by our next meeting (Friday, Oct 22). Refer to his instructions.
We're planning how the car should make a loop around campus.
At our next meeting, we will present our design documents, which are detailed plans on how our system components should work. These should be written as Markdown files. You should spend your full time on these.
I'm always here for you if you have questions, so let me know if you'd like me to clarify something. We're doing an excellent job-- Don't let up now!
-Will
Special thank you to Egan, Cristian, and Josh for showing up early on Saturday for on-campus testing :-)
General
- Papers for literature review
- Demo 2: Grand Tour (Overview)
- Our Team
- Learning resources
- Meeting notes
- Archived Pages
Development & Simulation
- Code Standards and Guidelines
- Writing and Running Tests
- Installation and usage
- Logging into the Quad Remote Simulator
- Running the Simulator
Software Design
Outdated or Uncategorized