Principle Engineer | |
Forced to Review | |
Dragged Along | |
Uplifted | Daniel Puratich Sahil Kale (Deactivated) Ethan Abraham Aidan Bowers (Deactivated) |
Objective | |
Due date | |
Key outcomes | |
Status | NOT STARTED / IN PROGRESS / COMPLETE |
\uD83E\uDD14 Problem Statement
Determine the necessary requirements & future expansion for a HIL Controller for verifying ZP. The HIL should allow for mocking of sensors, peripherals, and “environment” while verifying that outputs from ZP are as expected.
will this ever interface with the simulator?
🎯 Scope
Current Must Haves: |
|
---|---|
Future Expansion: |
|
Not in scope: |
✈️ Implementation Details
ZP input outputs
1 RFD900x
PPM & Telemetry
1 Mateksys 3901 L0x Optical Flow sensor
1 VN-300 Inertial Sensor
1 Neo M.8 GPS Sensor
1 BMX160 Inertial Measurement Unit
1 digital airspeed sensor
4 lift motors + ESC’s + Props
1 push motor + ESC’s
7-8 Servos
Jetson TX2
PX5
Central controller raspberry pi. Attach nucleos to this which run proper firmware.
\uD83D\uDDD3 Timeline
Open Questions
Do we want this to be a nucleo shield? I know this was mentioned throughout the meeting, but I don't remember if we came to a conclusion.
As it currently stands, when we refer to the “HIL controller,” we’re taking about the nucleo + the computer it interacts with. For the first revisions, we’ll design on a f401 In the future, this might turn into a nucleo shield
"Analog ↔︎ Digital conversion up to 6s VBatt" How do we want to do the analog to digital conversion? Where is the analog input coming from ?
- By "remote flashing" do we mean having the ability to flash when the programmer in physical contact with the device? Would the HIL then be under the view of a camera?
Will this ever interface with the simulator? I feel like this is more of a future expansion thing, especially because the simulator hasn't been started.
Yes, this should easily interface with the simulator because we are using a nucleo.
"Central controller raspberry pi" I'm not familiar with the pi, so how would this change the flow? Would the nucleo interact with the pi, which then interacts with ZP?
Long term scope for this project is to have one central controller, such as the raspberry pi, and several which route through the central controller. For example, one nucleo might be dedicated to mocking an IMU, and another might be dedicated to mocking GPS. The use of a central controller would allow us to break the project up into smaller parts, and have dedicated modules for certain things.
Do I need to write a UART driver? Or can I use the HAL UART driver?
HAL UART driver is fine for now. If we have issues with Aside: I know there is a UART driver in the old telem modules, so in case the HAL one doesn’t work I’ll use that - granted, this is approved of course.
✅ Actions Items
- Jack Greenwood create architecture diagram, documentation, & open questions!
\uD83D\uDEA9 Milestones and deadlines
Milestone | Owner | Deadline | Status |
---|---|---|---|
0 Comments