Suggestion - how to make micropython much simpler

[thorwald]

Let's say our goal is to enable people to combine full systems.

No matter how generic you make your interfaces, you cannot simply combine two full systems by adding their corresponding software together (at least I have the impression that's what you're after) or in another simple way. Say you have code for chasing cats and code for not leaving the house: in the end both of these pieces are going to need access to the motion system of the robot to make it do whatever it needs to do, so you cannot just combine that because part A would be saying 'go X' while part B would be saying 'go Y'. Instead you'd use a single control loop in which you read from both sensors and then decide what to do based on that input. The more sensors you get, the more complicated thats get and a typical pattern to cope with that is to use a state machine.

Stijn,Some interfaces are much more generic than others. We do know that chips , as in electronic chips , are pretty generic and reusable real time systems - just the pattern of independent real-time work + receiving commands + answering queries - works pretty well.

As for the cat example, maybe you'll need to adapt the hexbot code - to return a movement status message once in a while.And than just check movement + cat in the main loop and build informal state machines(kids prefer it this way). And of course it would be nice if it was simple to do - to add the message part.

BTW another similar model is the actor model(but i think it';s a bit more complex from end user perspective) , and there's some research showing it could be very useful simplifying development of rt embedded systems:

https://www.usenix.org/system/files/con ... r-barr.pdf

[thorwald]

pythoncoder, of course you're right - it's possible and not very complicated. But the abstraction i talked about offered more than that, as i mention in previous comments in this thread.

[Turbinenreiter]

I don't really understand what you want.
Maybe write some code and then we can talk about that.

[thorwald]

Say i want to design an hex robot that takes care not to go outside, and that's easy for others to integrate in other real time systems.

Code: Select all

class HexRobotWithSensor(ConcurrentObject): 
        """
        This is a real time, concurrent object that takes care of servo motors and 
        sensors.
        It runs an hexbot, but stops when senses it's going outside.
        """
	def __init__():
	
		"""
		another concurrent object that runs 6 servos according to commands, 
		in real time
		Reused from the net
		"""
		self.servos = Servos(speed=default_speed, direction_deg = 0) 
		
		self.outside_sensor = OutsideSensor() # another concurrent object
		self.speed = default_speed 
		self.running = False 
		while True:
			if self.running:
			
				"""
				if we want to do a blocking read(for beginner simplicity), 
				we need to use 
				B_read_*** format, same with commands , B_cmd_***
				this lets people easily use blocking stuff, but make them think about 
				non-blocking which is better.
				"""
				If self.outside_sensor.B_read_we_are_outside() == True 
					self.cmd_stop()
					
         """
         Adding input automatically creates an input queue for the input data/cmd
         It also wraps the cmd with an interface that only works throught 
         this queue And it also creates the B_cmd_ methods for blocking actions
         """
	@input
	def cmd_start():
		self.servos.cmd_start()
		self.running = True 
	             
	@input
	def cmd_stop():
		self.servos.cmd_stop()
		self.running = False 
		
	@input
	def cmd_update_direction(degrees):
	     	self.servos.cmd_update_direction(degrees)
		
        """
        The output behaves similarly to @input - all return values are in a queue, 
        access only throught queue , and adding blocking method
        """
	@output
	def read_is_running():
		return self.running

I think that's covers the general idea - basically simplifying concurrent code reuse and writing for full systems.
Not a real time guy , just a hobbyist, so there might be some concurrency bug hiding - but it's just the general idea.

[torwag]

Let's say our goal is to enable people to combine full systems.

No matter how generic you make your interfaces, you cannot simply combine two full systems by adding their corresponding software together (at least I have the impression that's what you're after) or in another simple way. Say you have code for chasing cats and code for not leaving the house: in the end both of these pieces are going to need access to the motion system of the robot to make it do whatever it needs to do, so you cannot just combine that because part A would be saying 'go X' while part B would be saying 'go Y'. Instead you'd use a single control loop in which you read from both sensors and then decide what to do based on that input. The more sensors you get, the more complicated thats get and a typical pattern to cope with that is to use a state machine.

We need docker for micropython