Damian Axford
Hi All
Robert Longbottom
Here is an early video of Scob walking, the code has improved a bit since then: https://youtu.be/nfrh7tHPFYQ
And here's what he looks like:
He still needs a head top designing (I think) to stop his brains falling out!
And someone suggested that flexy arms which wobble around when he's walking would be funny!
Rob.
--
You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Damian Axford
As you can see, SCOB now has arms (two variants), and an initial mouth design using a neopixel strip :) There's also a cap piece for his head, not shown in the video.
Software-wise, the animation control is stable and fairly capable, plus very portable to other projects. It will co-ordinate keyframe animation across a set of servos, with tween control via a bezier curve. Command queuing is inherited from LogoBot, but with a more streamlined/efficient parsing approach. There are a couple of ino files in the repo illustrating how to apply the libraries in a very simple form as well as a more full-featured version.
Latest experiments are with further streamlining the state machine that is used for selecting between different behaviours (e.g. wander at random vs collision avoidance) in the full-featured firmware.
Today's discussion has been on:
- How to get more reliable sonar readings whilst his head is swinging around.... perhaps incorporating a neck servo to de-couple the sonar direction from the body orientation.
- How to take the state machine / behaviour model further - looking into things like "subsumption architecture"
Which leads me nicely to thoughts on how the subsumption approach could be implemented... (you'll need to look at the latest code for context and for this to make much sense):
Subsumption architecture is based on the principle of co-existing behaviours, vying for control over the "actuators" of the robot, achieved by more important behaviours being able to suppress/inhibit the actions of others. Read the wiki article for more background, but that's the gist of it. This is really easy to understand if you have a continuous parameter space for your control (e.g. wheeled robot with fine grain control over speed/direction), but harder when you have discrete control states (e.g. for SCOB, with a set of fixed movement animations).
In the discrete case (ala SCOB), the various behaviours need to fight it out to determine:
- the current animation/movement (e.g. walk forward, walk backward, turn left, etc)
- animation speed
- anything else we add (e.g. animation mode for the neopixel mouth)
Of course, you don't want to switch animations too fast, or poor SCOB will end up fitting. On the flip side, allowing each animation to complete may be too slow for some reactions (e.g. collision avoidance). So, animations may need to define valid points of "interruption"... given they are keyframe animations, this could be as simple as a boolean flag for each keyframe that indicates if it is interruptible.
There is also the challenge of behaviours needing to co-ordinate a sequence of moves to get something done (e.g. collision avoidance needs to back-up then turn).
The MIBE architecture is actually a better fit for this problem, and is derived from the subsumption approach.
In SCOB terms, he has a couple of simple behaviours:
- Don't hit stuff
- Explore (wander around)
- Have fun (do random movements to avoid getting bored)
- Update sensors (i.e. take sonar readings)
- Update behaviour urgencies
- Select and execute active behaviour
- Execute movement(s)
- Don't hit stuff - check sonar reading, if below threshold value then urgency = high
- Explore - static. low urgency
- Have fun - time based value, if time since last "dance" > threshold, urgency = high
- Don't hit stuff - state machine to co-ordinate a move back, then turn. Reset urgency level once complete.
- Explore - state machine to co-ordinate walk, look around, turn
- Have fun - generate random moves for a while. Reset urgency level once complete.
Robert Longbottom
- Makes use of a PCB cut on the hackspace PCB milling machine (rather than a veroboard circuit), so should be easier to reproduce. (which is what I've been doing with the PCB milling machine recently)
- Uses the new SPIFFS (on flash file system) from the staging version of esp-for-Arduino ( https://github.com/esp8266/Arduino ) What this means is that rather than having the web pages that you want to serve out generated in code (which is the way the Logobot code works) they are stored in a "proper" filesystem that is stored in a reserved area of the flash memory on the ESP. This is better because:
- It's easier to edit / develop the webpages because you can just work on a local copy of the files (no need to then copy/paste html into a c++ header, just upload the files directly)
- The code is now more generic as it just has to serve out pages from the filesystem - so adding a new page is easier. (there is still some specific code to handle the command interface, but thats fairly stable)
- Programming the ESP is quicker because you can update the sketch and webpages independently (and in general there is no need to update the sketch) On an ESP-01 module the filesystem is only 64k, which is a lot quicker to upload that the full 512k if you do the sketch + webpages.
- PCB - we can cut some at the hackspace
- ESP8266-01 module (the common little blue ones with 8 pins)
- 3.3V voltage regulator (LF33 are quite good because they are super low dropout - http://www.bitsbox.co.uk/?main_page=product_info&products_id=1319
- A few resistors, capacitors, leds.
- Potentially a 3.3V to 5V level shifter board (if your Arduino is 5V) - like this (you can probably get them cheaper elsewhere, I think I did) https://www.coolcomponents.co.uk/logic-level-converter-bi-directional.html
- The code for the ESP8266 from github
- Scob: https://github.com/snhack/SCOB/tree/master/software/firmware/Esp8266Controller
- Logobot: https://github.com/snhack/LogoBot/tree/master/software/firmware/LogoBotEsp8266 (doesn't use SPIFFS, but would be easy enough to convert)
Damian Axford
Robert Longbottom
copper clad board that are already the right shape / size and they should
make 5 ish boards. I'm going to cut a few more for myself so when I do
I'll just cut as many as will fit.
On 3 November 2015 19:31:18 Damian Axford <dam...@axford.me.uk> wrote:
> Awesome :) given I have a bunch of spare Esps, I'd love to make up some
> carrier boards on the mill!
>