Processor-in-the-loop (PIL) with Teensy?

K

king_griffin

New member
Hi everyone,

I am developing a controller on Teensy 4.1. First, I do want to test it in the PIL style where my real Teensy gets feedback and control a model running on my computer. I know that Arduino and Simulink can work together. But my application does need Teensy board.

So, has anyone done this kind of experiment before? Could you give me some advice?

Thank you very much!
 
If you search the forum for "simulink", you will find quite a few threads, and at least one person who is using it, but with their own modified version of Teensy core, so it may not be "easy". See the posts by forum user @brtaylor.
 
My application is a little different, I have Teensy running controllers developed using MATLAB Simulink Autocode. The workflow is to use a Simulink Simulation of the vehicle and controller to develop and validate control laws and autonomy software in Simulink. The controller is then autocoded to C++, bundled with some wrapper code I wrote that handles the sensor and actuator I/O and real-time state estimation, and then flashed to Teensy. This uses a CMake build system to handle a lot of the magic and pull in dependencies:
https://github.com/bolderflight/spaaro

I have Simulink Embedded Coder setup for an NXP Cortex chip, but it's just generating C++ code during the Autocode process. This gets combined with C++ code from the Teensy cores along with C++ sensor drivers, state estimation, and a data logger. Then it's built and flashed using my CMake toolchain. Theoretically, you could setup the Teensy fully in Simulink and have Simulink flash the Teensy directly, but that approach seemed like a lot more effort than I wanted to invest. I would also then need to implement my sensor drivers and state estimation software in S-Functions so that they could then be Simulink blocks. There are some (simple) examples of this online, but from experience, implementing S-Functions can be time consuming.

I used to use Hardware in the Loop (HIL) testing in previous jobs, but I haven't found enough justification to implement it yet. My understanding is that Simulink can communicate with external devices over ethernet or serial. So the idea would be to spoof the sensors and actuators while running the vehicle model on a PC, communicating with a controller running on the Teensy. Probably use serial to facilitate that communication. My biggest issue is that I would need to have a different version of the controller software for HIL, one for example that looks for IMU data over serial instead of reading from the IMU over SPI. The other issue is that I'm using the IMU data ready interrupt for timing and for HIL / PIL the timing would need to come from Simulink. With all these mods am I really testing the controller?

In my experience, I'm mostly using Simulink simulation to validate my control laws. HIL / PIL testing is used to validate that I'm not overrunning frames and to ensure that the sensor and actuator I/O is correct. I just use ground testing for this currently. It's not the perfect work flow for everyone, but it works well enough for me and seems like a good approach for UAS / drones.

EDIT: I think HIL testing would likely be easier to implement and far more useful if the Teensy toolchain is fully implemented in Simulink. There are examples where the S-Function for a sensor driver can be setup to:
1. use a simulink model of the sensor during simulation
2. autocode to the C++ driver to communicate with the actual sensor
3. pull in external data from HIL

So that would be perfect, but it is a tall hill to climb. If you go down the path of trying to fully implement Teensy in Simulink, please let me know, I'd be happy to contribute where I can.
 
Last edited:
brtaylor said:
My application is a little different, I have Teensy running controllers developed using MATLAB Simulink Autocode. The workflow is to use a Simulink Simulation of the vehicle and controller to develop and validate control laws and autonomy software in Simulink. The controller is then autocoded to C++, bundled with some wrapper code I wrote that handles the sensor and actuator I/O and real-time state estimation, and then flashed to Teensy. This uses a CMake build system to handle a lot of the magic and pull in dependencies:
https://github.com/bolderflight/spaaro

I have Simulink Embedded Coder setup for an NXP Cortex chip, but it's just generating C++ code during the Autocode process. This gets combined with C++ code from the Teensy cores along with C++ sensor drivers, state estimation, and a data logger. Then it's built and flashed using my CMake toolchain. Theoretically, you could setup the Teensy fully in Simulink and have Simulink flash the Teensy directly, but that approach seemed like a lot more effort than I wanted to invest. I would also then need to implement my sensor drivers and state estimation software in S-Functions so that they could then be Simulink blocks. There are some (simple) examples of this online, but from experience, implementing S-Functions can be time consuming.

I used to use Hardware in the Loop (HIL) testing in previous jobs, but I haven't found enough justification to implement it yet. My understanding is that Simulink can communicate with external devices over ethernet or serial. So the idea would be to spoof the sensors and actuators while running the vehicle model on a PC, communicating with a controller running on the Teensy. Probably use serial to facilitate that communication. My biggest issue is that I would need to have a different version of the controller software for HIL, one for example that looks for IMU data over serial instead of reading from the IMU over SPI. The other issue is that I'm using the IMU data ready interrupt for timing and for HIL / PIL the timing would need to come from Simulink. With all these mods am I really testing the controller?

In my experience, I'm mostly using Simulink simulation to validate my control laws. HIL / PIL testing is used to validate that I'm not overrunning frames and to ensure that the sensor and actuator I/O is correct. I just use ground testing for this currently. It's not the perfect work flow for everyone, but it works well enough for me and seems like a good approach for UAS / drones.

EDIT: I think HIL testing would likely be easier to implement and far more useful if the Teensy toolchain is fully implemented in Simulink. There are examples where the S-Function for a sensor driver can be setup to:
1. use a simulink model of the sensor during simulation
2. autocode to the C++ driver to communicate with the actual sensor
3. pull in external data from HIL

So that would be perfect, but it is a tall hill to climb. If you go down the path of trying to fully implement Teensy in Simulink, please let me know, I'd be happy to contribute where I can.
Click to expand...


Thank you for your kind answer.

We are new to HIL/PIL things. What we want is basically testing our algorithms on MCUs.
Yes our application is with drones. So we do not want to try to make it run on real drone right now. We think PIL is good for now. We want to build a drone dynamics model in Simulink (not considering more complicated stuff than that) and use our controller on real Teensy. We do not auto generate code for Teesy (maybe it will be more convenient that we are not aware of).

I thought for HIL you need a real-time computer that we are not gonna go for. Could I have your email in DM? Thanks again.
 
Seriously, take a look at our SPAARO project in the simulation folder:
https://github.com/bolderflight/spaaro/tree/main/simulation

There's a pretty generic vehicle dynamics model and the option to load some defaults for a fixed-wing drone. It requires MATLAB Simulink and Aerospace Toolbox. If you start getting into autocoding, then you'll need Simulink Coder and Embedded Coder.

You can use a real-time target like a Speed Goat for HIL/PIL, which is called Simulink Real-Time (https://www.mathworks.com/products/simulink-real-time.html). There is also Simulink Desktop Real-Time, which will run on a PC or Mac (https://www.mathworks.com/products/simulink-desktop-real-time.html). Finally, there are ports for things like ethernet and serial in Simulink as well as the MATLAB / Simulink file sharing site - I was just working with a company in December that was driving a HIL sim with a regular ethernet port in a regular Simulink sim, not any of the real-time products. Obviously it wasn't real-time, but it worked well enough for what they were doing.

I would seriously consider whether you really need HIL / PIL testing or whether testing algorithms in Simulink is good enough. We setup our simulation so the vehicle dynamics are modeled in continuous time and the controller is modeled in discrete time. Our flight controllers use a fixed latency for sending actuator commands (i.e. we use a 100 Hz frame rate and send actuator commands 9 ms after we get the sensor data), so we're also able to either model that or analyze robustness against that time delay. Our flight control system is using one processor that is doing everything (data acquisition from sensors, real-time state estimation, control laws and data logging). My biggest issue with HIL / PIL is that I'd have to completely change the software to look at the serial port for sensor and timing data instead of reading the actual sensors or the MCU clock. We have been working on a newer product that federates functionality between multiple processors on a CAN bus. In that case, HIL could make a lot of sense, since our flight computer is looking for data from the CAN bus anyway, so I can test the actual flight software without modifications.

Anyway, hope that helps, sent you a DM.
 
You must log in or register to reply here.
Back
Top