Further information query regarding rig configuration

struct dwVehicle contains following fields: driveByWireTimeConstant, driveByWireTimeDelay with a description that does not say much.

What time parameters these two actually represent? Where in a system are these times measured?

My guesses are:

  1. driveByWireTimeConstant implies the time it must pass between each control signal/command. For example driveByWireTimeConstant: 0.25 => we can issue commands 4 times each second.

  2. driveByWireTimeDelay implies command reaction time - time it takes for signal/command to start modifying state.

  3. In addition, is brakeActuatorTimeConstant/thrustActuatorTimeConstant meant as a time it takes from 0 signal value to reach to goal (actuator position relating to signal 1)? To put it simply, time it takes fro actuation to move from 0 position to max position.
    For example, position is 0, brakeActuatorTimeConstant: 1.0 => it takes 1 second for actuator to reach goal for given signal 1; 0.5 seconds for 0.5 signal (goes linearly).

Is my understanding of these time parameters correct?

As an extra, where could I find mathematical vehicle model that uses these parameters from dwVehicle?

Dear marek.piirikivi,

We will check internally on this topic and update you. Thanks.

Hi marek.piirikivi,

Are you able to share a bit more about what you are trying to accomplish with these parameters? I’d like to make sure we are giving you some relevant information. Are you working with a specific drive-by-wire box?

Feel free to PM me or open an bug request if you’d like to discuss anything offline from the forums.

Hello,

I am trying to understand the reason behind these parameters and where these are (or should be) used.
Since they are included in API dwVehicle structure, there must be some idea behind it. I want to know where in a flow these times should be measured when configuring vehicle. If they are not implemented in modules and it’s open for implementation and to reason about, then it would be great to receive such information.

Hi Marek.piirikivi,

These parameters are used when actuating a physical vehicle via a drive by wire interface box. Such as NVIDIA’s BB8 development vehicles.

There is more of a description of the DriveAV and Roadrunner Architecture in the Roadrunner documentation available here:
https://developer.nvidia.com/DRIVE/secure/docs/NVIDIA_DRIVE_SW_10_References.zip
Specifically the drive by wire interface is Vehicle IO module further documented in the architecture section in this file: DRIVE_SW_10.0_References/DRIVE_Software/Roadrunner/arch_vehicleIO.html

Please give it a review and let us know if you have further questions or are looking to further leverage the VIO interface.

Hi LukeNV,

Thank you for your reply and linking excellent resource to look into.
Do I understand you correctly that these parameters are BB8 specific? I failed to locate further details on what they represent, sadly.
Can you confirm whether my initial guess about these parameters were correct (or can be considered somewhat correct)? I see from example rig files that driveByWireTimeConstant is around 0.25 and driveByWireTimeDelay is around 0.1. Assuming these are in seconds, delay appears to be bit too much when I consider it to be response time (but then again, if there are additional works to be done by lower lever controls, then it would be understandable). 0.25 could indeed be sufficient time interval between each new command.

If no existing module provided by API cares for these parameters, then indeed, I’ll consider this thread closed and note

as accepted answer.

Please write back your thoughts on this.

Hi Marek.piirikivi,

These parameters are not BB8 specific, but they are utilized for interfacing with our DBW box that we use in BB8 to interface with the vehicle. These parameters are not used in their raw form as you commented in your initial post, but rather part of a control algorithm model. It is part of the control algorithm to obtain initial control tuning constants for the particular DBW interface being utilized. Typically DBW boxes themselves have their own limitations for command frequencies that are similar to what you describe but usually much higher frequency(>50Hz).

Hi,

Thank you for your reply. I’ll accept “These parameters are used when actuating a physical vehicle via a drive by wire interface box. Such as NVIDIA’s BB8 development vehicles” as answer to this question.
Although I didn’t get explicit answer to question about the essence of driveByWireTimeConstant and driveByWireTimeDelay, I did get an answer that they are up-to DBW box to define and used by control algorithm. (If you have any complaints or corrections about that sentence, please do let me know).

Hi marek.piirikivi,

That sounds good. If you have a specific need to discuss our control model algorithm in more detail or have a usecase to discuss please feel free to direct message me!