Acceleration vector

[Aoife Ryan]

Hi Thomas,

Wondering if there is a way to capture a body's acceleration vector in a lua script?

Thanks,
Aoife

[Thomas Geijtenbeek]

Hi Aoife,

The easiest way to do that is to store the velocity of the previous frame, compute the difference, and divide by model:delta_time().

[Aoife Ryan]

I'm having some trouble calling in stored values. I'm using the store_data function to store the acceleration but I can't figure out how to call that value back into the update function in the next iteration. I'm also trying to use one of the joint.load values that is automatically output in the analysis window at each optimisation. Is there a specific function which allows me to call these values?

[Thomas Geijtenbeek]

You can use a global Lua variable to store the previous velocity, something like this:

Code: Select all

function init( model, par, side )
	...
	previous_com_velocity = vec3:new( 0, 0, 0 )
	...
end

function update( model )
	...
	local com_velocity = model:com_vel()
	local com_acceleration = (com_velocity - previous_com_velocity) / model:delta_time()
	previous_com_velocity = com_velocity
	...
end

Joint load is currently not available in the SCONE scripting engine. Feel free though to post a feature request for that at https://github.com/opensim-org/SCONE! In the meantime, perhaps the ground reaction force is a useful alternative?

[Aoife Ryan]

Hi Thomas,
I implemented what you recommended in terms of storing data, using the z component of angular velocity. I can see in the analysis window that this is definitely changing through the simulation (using a more basic version of the simulation), however, when I run the scenario, it returns a flat fitness. If I multiply by 1 rather than "right_pedal_acc" in the last line of code, this does not happen, so it must be to do with the calculation of "right_pedal_acc". Do you have any idea where I might be going wrong?

Capture.PNG (18.52 KiB) Viewed 1189 times

[Thomas Geijtenbeek]

Flat fitness means that all fitness values are the same during a single iteration. As a result, the optimizer can't deduct how to improve the parameter values based on the fitness differentiation. This usually has one of two causes:

• The measure returns the same value even when simulations are different. This could be the case when a measure becomes zero when within a certain threshold, or if there's an error in the simulation. Evaluating the measure (Ctrl + E) and checking the result in the Messages window is a good way of detecting this.
• The controller produces the same excitation patterns even when parameter settings are different. For instance, all excitation values could be smaller than the minimum (0.01) and get rounded to that value. Checking the excitation pattern of a single evaluation (Ctrl + E) is usually a good way of detecting this.

In order to find out what's going on in your case I need a little bit more information on what you're trying to accomplish. If you wish to keep this information private, you can also mail me directly.

[Aoife Ryan]

I have tried to evaluate the model, however I am getting an error related to the length of the hamstring muscle:



I have checked the muscle and it is defined in the same way as the model used in the tutorials and definitely not of 0 length. That said, the model will still attempt to optimise and from trying more basic versions of the scenario, I am fairly sure neither of the conditions you have mentioned for flat fitness are true.

I am trying to create a cycling scenario where there is a feedback loop defining the level of excitation of each muscle. This is the overall SCONE scenario:

Code: Select all

CmaOptimizer {
	signature_prefix = DATE_TIME
	
	SimulationObjective {
		max_duration = 6
		
		# Model used in simulation
		OpenSimModel {
			model_file = Models/FESCyclingModel_Rev12.osim
		}
		
		# Controller for the Model
ScriptController {
				target_speed = 8.38 
				# in rad/s as retrieving angular velocity in controller
				
				script_file = "Scripts/AdaptiveControllerCycling_RIGHT_SIDE.lua"
				script_file = "Scripts/AdaptiveControllerCycling_LEFT_SIDE.lua"
			}
		<< Scripts/MeasureCycling80rpm.scone >>
		# Fitness measure for jumping
	
	}
}

I'm using two controllers - one for the left side and one for the right. I am regulating the phase and frequency of the excitation with the difference in target and instantaneous velocity of the gear, which seems to work fine. I am trying to regulate the amplitude of the excitation using the y-component of acceleration of the pedals, which is what appears to cause the flat fitness.

Code: Select all

function init( model, par, side )
	-- keep a list of offsets and slopes to compute the excitation
	
	side = -1 --controller for right side of body
	gain_phase = {} -- l pedal cycle 0-180 deg for pushing phase TDC to BDC (top dead center to bottom dead center) and vice versa 180 to 360 deg for recovery phase
	gain_frequency = {} -- # RPM = pedal cadence
	gain_amplitude = {} -- # Watt = pedal intensity
	
	

	-- keep a list of all actuators
	actuators = {}

	target_speed = par:create_from_string( "target_speed", scone.target_speed )
	
	leftPedal = model:find_body( "Left_Pedal" )
	
	gear = model:find_dof("gearToGround_coord_0")

	
	previous_lp_velocity = vec3:new( 0, 0, 0 ).y
	
	-- iterate over all actuators in the model
	for i = 1, model:actuator_count() do
		-- store the actuator in the list
		actuators[ i ] = model:actuator( i )

		-- create parameters for both slope and offset
		local name = actuators[ i ]:name()
		
		gain_frequency[ i ] = par:create_from_mean_std( name .. "-gain_frequency", 1, 0.5, 0, 2)
		gain_amplitude[ i ] = par:create_from_mean_std( name .. "-gain_amplitude", 0.5, 0.3, 0, 1 )
		gain_phase[ i ] = par:create_from_mean_std( name .. "-gain_phase", 3.14, 3.14, 0, 6.28)
	end
	
end

function update( model )

	-- get the current simulation time
	local t = model:time()
	
	local gearVel = gear:velocity()
	
	
	local left_pedal_y = leftPedal:com_vel().y
	local vel_diff = left_pedal_y - previous_lp_velocity
	local delTime = model:delta_time()
	local left_pedal_acc = vel_diff/delTime
	
	previous_lp_velocity = left_pedal_y

   

	-- iterate over all actuators
	-- define here the sinewave function!!!
	for i = 1, #actuators do
	
		local argumentFrequency = 2*3.14159*gain_frequency[ i ]*(gearVel-target_speed)
		local argumentPhase = gain_phase[ i ]*(gearVel-target_speed)
		local argumentAmplitude = gain_amplitude[i]*left_pedal_acc
			
		excitation = argumentAmplitude*math.sin(argumentFrequency + argumentPhase)
		
		actuators[ i ]:add_input( excitation )
		
	end
	
end

[Thomas Geijtenbeek]

I'm not sure what's going wrong, I'd have to dig deeper into it. Could you send me a zip file with all required files, so I can try to reproduce the issue?

But first, did you try the most recent release (1.4.0)? There's a change the issue may be resolved there.

[Thomas Geijtenbeek]

It appears your actuator input is not a valid number. This is probably due to a division by zero, because model:delta_time() is zero on the first frame. Adding a check for that should solve the problem!