Skip to first unread message
Kristian Klausen
Jan 20, 2016, 7:44:44 AM1/20/16
to LSTS Toolchain
Hi,
We have a couple of external sims for multiple copters, but when running on normal desktops we do not get the real-time performance nescessary for timing requirements on integrators and timeouts, etc.
So I've been playing with the idea of having dune step the time based on an IMC-message, say SimulatedState. To make this work, a compile-flag could alter the Clock-module, and have a task that sets the "current" time based on a timestamp on an incomming IMC message.
Any thoughts on such an endaveur?
Regards,
Kristian
We have a couple of external sims for multiple copters, but when running on normal desktops we do not get the real-time performance nescessary for timing requirements on integrators and timeouts, etc.
So I've been playing with the idea of having dune step the time based on an IMC-message, say SimulatedState. To make this work, a compile-flag could alter the Clock-module, and have a task that sets the "current" time based on a timestamp on an incomming IMC message.
Any thoughts on such an endaveur?
Regards,
Kristian
José Braga
Jan 20, 2016, 2:08:29 PM1/20/16
to LSTS Toolchain
This is by no means trivial, I think.
Pedro Calado tried in the past some solutions.
I am not completely aware of his accomplished (I know he had some positive results, but I do not know how much fast, or if anything was degraded etc.). I know that he dropped his efforts as it wasn't easy and he other things to do first.
For us, in the past this was more important that it is now. When we need something we either test it in the real world, or use the simulations to test neptus, or other high-level stuff.
The simulation task is a thread that's launched by the task manager. Without putting much thought into this, it seems to me that you won't be able to manipulate time using an IMC Message that is launched by a task that, in itself, is managed by a class (task manager) that's working using "real" time - The DUNE core Time class provides the functions necessary to provide timestamps/delays
Forgive me if I use the wrong terms here, but I think there are two possible solutions:
a) Ricardo mentioned in a meeting this week, that it is possible to have something between OS time and DUNE time (using a linux library) (if I understood correctly, that is! :D)
b) Have a simulated clock and modify output of DUNE::Time classes depending on profile
Regards,
José Braga
--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at https://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/bb955489-40be-48cf-9058-832da9b775e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kristian Klausen
Jan 21, 2016, 10:46:27 AM1/21/16
to LSTS Toolchain
Hi,
Glad to hear there are some experience with this.
To clarify what I had in mind: My simulator is running in Matlab. Say I'm running a simulation with a fixed timestep of 0.01s. For each step, I would send an IMC-message (SimulatedState), whos timestamp is the accumulated simulation time (k*h)+some offset to bring the time up from 1970. In Dune, the Clock-class is set to just hold some set value, not using any clocks at all. A task listens for SimulatedState, and sets the current clock-value to the incomming timestamp. This means the clock would always have values like 10.0, 10.01, 10.02, etc. Basically, all in Dune would run in discrete time-steps. This would probably mess up everything that runs faster than the simulator though, but for my usecase, which is only about testing the implementation of some controllers, might not matter.
To close the loop, the simulator continues the simulation after it has received a new control input (Say DesiredControl) from Dune.
My proposed solution involved a compileflag to alter the behaviour of the static Clock-task. This is a small hassle. Does such static classes have access to the current Context? Then, I could get the profile or other run-time flags from there.
Kristian
Glad to hear there are some experience with this.
To clarify what I had in mind: My simulator is running in Matlab. Say I'm running a simulation with a fixed timestep of 0.01s. For each step, I would send an IMC-message (SimulatedState), whos timestamp is the accumulated simulation time (k*h)+some offset to bring the time up from 1970. In Dune, the Clock-class is set to just hold some set value, not using any clocks at all. A task listens for SimulatedState, and sets the current clock-value to the incomming timestamp. This means the clock would always have values like 10.0, 10.01, 10.02, etc. Basically, all in Dune would run in discrete time-steps. This would probably mess up everything that runs faster than the simulator though, but for my usecase, which is only about testing the implementation of some controllers, might not matter.
To close the loop, the simulator continues the simulation after it has received a new control input (Say DesiredControl) from Dune.
My proposed solution involved a compileflag to alter the behaviour of the static Clock-task. This is a small hassle. Does such static classes have access to the current Context? Then, I could get the profile or other run-time flags from there.
Kristian
José Braga
Jan 25, 2016, 9:34:17 AM1/25/16
to LSTS Toolchain
It seems to me that what you suggest it'd be really hard to implement. To be honest I do not think I am able to comprehend all the modifications required and I would not even know how to begin doing that..
One thing that comes to my mind is that you suggest sending a SimulatedState that will impose discrete timesteps to the system.
As it stands now, everything at the Tasks/Task level uses DUNE::Time. All delays/counters use that class as well. Several controllers use direct timestamps from message to compute time differences, and I'd bet a lot of PIDs to as well..
To start using discrete timesteps, I think you'd either have to change several tasks plus core classes or add something inbetween Dune::Time and Tasks that would, somehow, relate current timestamps with discrete timesteps.
By no means I have a clear understanding of this subject, but it seems to me the practical solution would be either:
a) use something at the OS level to manipulate the time given to DUNE, or
b) modify Dune::Time to produce a virtual time, although keeping track of real time.
Best regards,
José Brag
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/2461e349-1bcc-4919-849c-133cf166d438%40googlegroups.com.
Kristian Klausen
Jan 25, 2016, 12:59:33 PM1/25/16
to LSTS Toolchain
Hi,
Hehe, yes I'm fully aware this is a rather hackish suggestion, and by no means something that should be put upstream :) I would have to be quite conservative on which tasks to run. It's mostly meant to test the implementation of a small part of a non-linear controller. (vs the implementation in matlab)
Thanks for the inputs, I really appreciate it. I'll let you know if I decide to spend some time on this.
Regards,
Kristian
Hehe, yes I'm fully aware this is a rather hackish suggestion, and by no means something that should be put upstream :) I would have to be quite conservative on which tasks to run. It's mostly meant to test the implementation of a small part of a non-linear controller. (vs the implementation in matlab)
Thanks for the inputs, I really appreciate it. I'll let you know if I decide to spend some time on this.
Regards,
Kristian
Reply all
Reply to author
Forward
0 new messages