5 replies to this topic

[FredericG]

With the recent CC code, it seems I need to set ActuatorCommand and ManualControlCommand to readonly in order to get control.
Before only ActuatorCommand needed to be readonly.

def driveServo(self):
		print "Taking control of self.actuatorCmd"
		self.objMan.ActuatorCommand.metadata.access.value = UAVMetaDataObject.Access.READONLY
		self.objMan.ActuatorCommand.metadata.updated()   
		self.objMan.ManualControlCommand.metadata.access.value = UAVMetaDataObject.Access.READONLY <<<<<<<<===
		self.objMan.ManualControlCommand.metadata.updated() 	<<<<<<===
		
		while True:
			self.objMan.ActuatorCommand.Channel.value[0] = 1000
			self.objMan.ActuatorCommand.updated()
			time.sleep(1)
			
			self.objMan.ActuatorCommand.Channel.value[0] = 2000
			self.objMan.ActuatorCommand.updated()
			time.sleep(1)

Is this intentional?


Frederic

[peabody124]

No, it's not intentional.  However I think I know why.  Probably if the input module is in the error condition (no input detected) then there won't be any updates on ActuatorDesired so actuator.c goes into the error condition and doesn't process ActuatorDesired.

I'm not sure this is really a bad thing though since you normally wouldn't want to enable the outputs without a transmitter or gcs control.  However I can see the argument of adding a ActuatorCommandSet / ActuatorCommandGet in actuator.c:474 to fix this.

[FredericG]

I did not analyze the code so why this has changed.

For what I am doing, this does not need fixing, the workaround is very simple. One could however argue that this is a bug... when setting  ActuatorCommand to READONLY, it should just work IMHO.

Quote

However I can see the argument of adding a ActuatorCommandSet / ActuatorCommandGet in actuator.c:474 to fix this.

I would propose that we introduce a completely separate code-path for this feature so that all other (normal) code does not have any influence, at the beginning of the big while-loop, before the xQueueReceive.

Frederic

[peabody124]

I really don't like code before the failsafe check.  Ick ick.  Failsafe is most important.  I feel like that whole code needs a big of reorganization though looking at it.  There are enough control paths and things like that I don't think it's easy to be sure it's safe (I think it is, but the code could make it more obvious).

I'd also almost like to know the failsafe overrides even that readonly myself, but I agree it's a bug in the sense of not expected outcome.

[jes1111]

peabody124, on 21 June 2011 - 05:18 PM, said:

I really don't like code before the failsafe check.  Ick ick.  Failsafe is most important.  I feel like that whole code needs a big of reorganization though looking at it.  There are enough control paths and things like that I don't think it's easy to be sure it's safe (I think it is, but the code could make it more obvious).

I'd also almost like to know the failsafe overrides even that readonly myself, but I agree it's a bug in the sense of not expected outcome.

I know it's the dullest part of programming, but Unit testing would confirm the safety, wouldn't it?

[peabody124]

jes1111, on 27 June 2011 - 05:10 PM, said:

I know it's the dullest part of programming, but Unit testing would confirm the safety, wouldn't it?

This is more like defining the expected behavior, so your unit testing always tests for that.  Fred is working on a unit testing framework though.