HIL Controller Current State
- Jack Greenwood
Overview
I am writing this document to detail the current state of the HIL Controller project. Please read the following two documents before reading this one. Comms Emulator Board - Requirements HIL Controller version 0.1.x.
History
After comp 2022, the desire for a system to act as a substitute for ZP when radio comms are not permitted was established. Initially, this project was labelled as a comms emulator, and scraps of the original requirements may be found here Comms Emulator Board - Requirements. However, it must be noted that the link has been updated to reflect the most up-to-date requirements. At one point, this board was going to be its stand-alone board. Now, when we refer to the "HIL Controller," we are talking about a computer hooked up to a Nucleo board (STM32F401RE, most likely), like a wrapper between ZP and GS for everything going in and coming out of ZP. Major points in this document include sensor mocking, future expansions, and where to find the codebase.
Sensor Mocking
The desire to mock sensors and their interfaces was a big goal for this project. Mainly, we wanted to mock our Inertial Measurement Unit (BMX160) and our GPS (VectorNav300). The BMX160 uses the I2C interface for communication, and if you would like to read more about that protocol or are unfamiliar, please read the following I2C - Inter-Integrated Circuit. The VN300 uses UART for communication, and you can read more about that here UART - Universal Asyncrohonus Transmitter Reciever.
To mock sensors, we must employ bit-banging, which uses “software as a substitute for dedicated hardware to generate transmitted signals or process received signals" (https://en.wikipedia.org/wiki/Bit_banging#:~:text=In%20computer%20engineering%20and%20electrical,signals%20or%20process%20received%20signals.). Some protocols are easy to mock, while others are pretty difficult. For example, I2C uses hardware addresses to communicate with peripheral devices. However, when replacing hardware with software, we must find a way around this. On the other hand, UART does not depend on hardware requirements and has common adaptations, such as STMs HAL adaptation, making it easier to implement and test.
BMX160
Given our BMX160 driver is written to use I2C for communication, mocking the I2C protocol was required. Though it is untested, you can find an I2C mock in the codebase of the current project. The same goes for the mock of our BMX160 driver as a whole. Code is implemented, though the validity is uncertain and must be verified before moving forward.
VectorNav300 (VN300)
The current state of our VectorNav300 driver is incomplete. Someone is working on it currently, but I'm unsure when this will be completed and functioning. As a result, the mocking of the driver has not been completed and exists in the project. Thankfully, the module uses UART for communication, which is not hard to mimic and is done through HAL's adaptation of the protocol. When the driver is completed and functioning, it should be adapted and implemented in the HIL repository.
NEOM8
I am unsure of the current state of the driver, though I know our neom8 has been giving us issues for the last year or so. As far as I know, the current driver implementation uses UART, though the module itself does not send and receive data. So messaging the individuals assigned to the task would be the best next step.
Future Iterations
This section will be dedicated to future iterations and how the current design may be improved.
Referencing the photo below, several things were completed this term and still need to be worked on.
Current Must Haves
PPM output was completed though not implemented in the current project. To read more about PPM output, see the following document PPM Output Implementation. Hardware ARM/Disarm signal was not completed. This was lower on the priority list and, as a result, was not met. I think CV handles all the arming and disarming through our GSPC. If so, the following steps would be finding out how this is done. After recent system architecture discussions, sending and receiving telemetry data and passthrough telemetry to GS is somewhat ambiguous. Rediscussing what this would look like is the next step. Interfaces over USB means the "board" functions as a Nucleo board connected to a computer through USB. Analog to digital conversions is handled by another member and should be implemented in the project when completed. Mocking sensors were covered above. See below for the last points/future expansions.
Remote access with the ability to remote flash has not been implemented this term, though it could be a future project using an existing framework on the internet. Through discussions, it has been brought to my attention that we plan to have a future coop implement Jenkins as a testing platform. Plans may have changed since, but if this is the case, the code will need to be adapted to work with Jenkins. The ability to reset ZP goes back to the Arm/Disarm point above.
Future Expansion (Short Term)
Analog components for user input to the HIL include peripherals like potentiometers. More sensors and testing suites are always appreciated. Ideally, when we develop sensor mocking in the future, we will use individual nucleo boards or another suitable physical device to mock specific sensors. Hardware monitoring would be beneficial. Expanding on hardware monitoring, we should be able to see the current state of ZP as we alter ZP's state on the HIL. That is, we should be able to track how ZP responds to our input commands from the HIL. As future iterations are completed, the HIL should be able to interface with our simulator. While both are in the early development stages, it is unclear how that will look.
Future Expansion (Long Term)
When the HIL has reached a satisfactory state with its current configuration using a nucleo board, we would like to have a setup with several peripheral devices connected to a central controller. In early discussion, this was thought to be something like a raspberry pi or Arduino, though this is entirely up to the user to decide and discuss. Ideally, the "peripheral devices" would be individual nucleo boards dedicated to mocking specific things. This would allow us to test individual components at will and avoid sifting through the codebase to test particular devices.
Looking further into the future, this project, in a completed state, should exist as its own board with everything built-in (i.e. no need to hook up external devices for functionality). This is out of scope for the project's current state but should be re-evaluated when a more polished version is completed. Ideally, a member of the EFS team would finish the software side of the project while a member of the electrical team designs the board. If the appointed individual has enough time, they could do both aspects, though this would be a lot of work for one person.
Where is the Code?
You can find the current state of the project under the following repositoryhttps://github.com/UWARG/HIL_Controller_SW. Most of the code is in LOS, under a branch labelled testing/HIL_SW, and you will need to ensure that this branch is up to date with the current state of the main branch. If you are unfamiliar with git, please read the following article Git Workflow.
Closing Regards
As this project is modified, this page should be updated accordingly. While the project was not completed this term, this document and the current state of the codebase will hopefully be helpful for a future individual to pick up and finish/improve upon.
Helpful Terms
What is a nucleo shield? Something that is attached to your pre-wired board that gives additional functionality.
Regression testing? In regression testing, you test the most recent version of your code and the ability to run through different scenarios. Read more about regression testing here https://www.guru99.com/regression-testing.html.
References