Let's Make Robots!

Subsumption based robots

An awesome presentation on subsumption-based robots by David Andersson, it's a bit long, but it's totally worth it.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I don't see the link in the orginal post.

Did a software upgrade take out the link?

I believe this is the video Gabrial_f linked to.

It's a great video IMO.

Almost done watching and it's totally worth it!

I have yet to figure out how to program subsumption architecture into a robot. The explanations in the books are just too broad stroked for me. I hope, when I watch this video, I will be able to get a better grasp on the subject.

Thanks for posting it.

Apart from that I'm not sure(code wise, but can't be that hard) on how to do the priorities, I think I understand it now. Got some really interesting ideas at least :)

It seemed like a set of tiered behaviors that would control the robot, with higher priority tiers 'subsuming' lower ones when triggered.

The lowest tier is 'user defined behavior'. So if you want your robot to find and pick up ping pong balls, that is the user behavior. If a sonar sensor detects a wall in front of it, that is an obstacle avoidance, that is a higher tier. The robot will stop what it is doing and avoid the obstacle, then return to user defined behavior of hunting ping pong balls.

I just came across this video a week or so ago. It did take awhile to get through, but it is packed with great info and guidance. 

I may have to watch it again with a notebook in front of me!

nice link:)

What I found especially interesting from the first half of this lesson is:

  • A robot must be able to turn on place. Rotate without travel.
  • Whenever there is something abuts out of the robot it will stuck on to that somewhere sometime.
  • 50Hz frequency. David Anderson proposes 50Hz as sufficient frequency. In Arduino that would be a 20 millisecond delay in the end of the loop function. This is due to physical issues of the sensors.
  • Leaky integrator. What can we do if our robot is stuck in a symmetry like a corner? Use a leaky integrator to count i.e. bumber hits to then when the hit count gets to a defined high level the robot has to change the behavior to get out of the symmetry.

About the delay thing, I think that can be bypassed actually, it might not of course be necessary, but speed is always nice.

If you take your sensors various delays and such in to account when you code, you wouldn't need that "wasteful" delay there. It's good to read data as often as possible, what if something happens during your sleep time?:)

 

And I agree on the "leaky integrator", I've used this type of thing before, just didn't know there was a word for it :)

Two hours and twenty eight minutes packed of experience and knowledge. Thank you for sharing this!