HIL Controller version 0.1.x

Principle Engineer

@mahir @Yuchen Lin

Forced to Review

@Christopher Chung @Anthony Luo

Dragged Along

Uplifted

@Daniel Puratich @Former user (Deleted) @Ethan Abraham @Aidan Bowers (Deactivated)

Objective

To creates a system that feeds simulated signals directly into pilots to verify the behaviour of zero pilots is correct.

Due date

Key outcomes

Capture as many potential errors in the code before the actual test flight.

Status

in progress

 

 Problem Statement

The art of code testing.

code analysis → unit testing → simulator in a loop(test high level manager behavior) → Hardware in a loop(HIL)

The HIL allows mocking of sensors, peripherals, and “environment” while verifying that outputs from ZP are as expected.

will this ever interface with the simulator?

possible but as an extention of current system.

What is HIL?

a test suite → ecu → hardware → output

HIL uses plant, a mathmatical representation, to test the embedded system. The plant first generate a situation of input and corresponding signal is emulated and send to the embedded test. The input will affect the output signal and then change plant input again. Test suite are prepared which is a collection of test cases.

 Scope

Current Must Haves:

  • PPM Output to emulate controller signal

  • Hardware ARM/Disarm signal → ZP (button emulation)

  • Send/Receive Telemetry Data

  • Passthrough Telemetry to Ground Station

  • Interfaces over USB

  • Analog ↔︎ Digital conversion up to 6s VBatt.

    • monitor battery [status]

  • Mock IMU, GPS

    • by extension, mocked interfaces (spi/i2c/uart).

  • Remote access incl. remote flashing.

  • Test suites (small regressions for now).

  • Ability to reset ZP (toggle reset line on ZP) (or remote flashing).

Current Must Haves:

  • PPM Output to emulate controller signal

  • Hardware ARM/Disarm signal → ZP (button emulation)

  • Send/Receive Telemetry Data

  • Passthrough Telemetry to Ground Station

  • Interfaces over USB

  • Analog ↔︎ Digital conversion up to 6s VBatt.

    • monitor battery [status]

  • Mock IMU, GPS

    • by extension, mocked interfaces (spi/i2c/uart).

  • Remote access incl. remote flashing.

  • Test suites (small regressions for now).

  • Ability to reset ZP (toggle reset line on ZP) (or remote flashing).

Future Expansion:

  • Add-on with analog components for user-input to HIL

  • Mock more sensors (Airspeed, Barometer, OFS, etc).

  • Future expansion for more complete test suites.

  • Actuator output checking? (in a safe way)

  • hardware monitoring (temperature / current / power / etc)

Not in scope:

  •  

tasks break down:

To-do:

PPM data: (emulating controller signal)

Hardware ARM/ Disarm signal:(emulate a safe to start signal):

Output verifying? Hooking up scope/DDM ← safe thing to do?

solution proposing: reduce the voltage to 5v analog and send the actuator signal back to the stm board to verify the input and anticipated output.

under research:

Send/ Receive telemetry data: (mocking UART data stream)

Interfaces over usb: (emulate Serial communication)

Analog ↔︎ digital conversion: (adc singal?)

Mocking IMU, FPS/ other peripherials: (Mainly i2c and spi)

future to-do list:

Remote access and remote flashing: hardware power-cycle

testing suites: (regression testing)

Having a custom HIL system and custom hardware

Hardware monitoring.

comms emulator. Portable ground station

 Timeline

The current short term goal to the mid-march will be to create the designed signal and to finish coding and unit testing the code. After all testing is carefully done try to run it on zp carefully and see correct output are generated. Think about how to check the signal output and verify the signal.(safe and automated)

23-Jan202330-Jan06-Feb13-Feb20-Feb27-Feb06-Mar13-Mar20-Mar
architecture planning
coding
unit testing

understand ppm frame

understanding disarm button signal

purposing interfaces and arch

automating the zp output testing

finish the code

unit testing each output

zp integration test

 

 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.

 Actions Items

@Yuchen Lin Finish reading all the document about ppm and disarm button and sketch a basic data frame for the ppm and output and the disarm button output

PPM Output Implementation

@mahir Catch up on the speed of reading all the document. We want to by the end of this week, we are clear about what is ppm and disarm mode
@Anthony Luo @Christopher Chung @Yuchen Lin @mahir architecture meeting for HIL about 1. interface, 2. data structure, 3 test suite for controller and disarm button.

 Milestones and deadlines

Milestone

Owner

Deadline

Status

Milestone

Owner

Deadline

Status

Finish understand ppm output and disarm mode

@Yuchen Lin

@mahir

Jan 27, 2023

in progress

finish designing the arch

@Anthony Luo @Christopher Chung @Yuchen Lin @mahir

Feb 10, 2023

 

finish coding

 

Feb 17, 2023

 

unit testing done

 

Mar 9, 2023

 

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 talking about the nucleo + the computer it interacts with. For the first revisions, we’ll design on a F401. (L5) In the future, this might turn into a nucleo shield, but we’re more likely to have a central controller (refer to below).

  • "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 ?

    • We want to measure the analog voltage from our power distribution board. When the HIL reads this value, it then sends a signal to ZP indicating that our board is receiving a certain voltage. This voltage is “forwarded” to ZP which then determines which flight mode we’re in.

  • By "remote flashing" do we mean having the ability to flash when the programmer is not in physical contact with the device? Would the HIL then be under the view of a camera?

    • Due to the fact that the HIL controller is the nucleo AND the computer, we should be able to SSH into the system.

  • 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 peripherals (decided to be nucleos as of now) that route through said 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 the HAL UART, this will likely be a bigger issue.

  • I2C issues, and working with hardware that doesn’t exist. More direction on this would be nice.

 

 Reference materials