Ripley v2.0: Let Her RIP

What’s In A Name?

During this re-design phase, I’ve been thinking about what Ripley actually is. She’s not really a robot as she doesn’t perform any specific tasks, she’s not a drone as a) she isn’t remotely controlled and b) she has no specific purpose and nor is she an android as she doesn’t look remotely human.

Eventually I did discover a way to describe her: she’s a RIP: Roving Intelligent Platform:

  • Roving: She moves around under her own power and can be given planned routes or decide her own, depending on the environment.
  • Intelligent: She can make decisions based on what her senses tell her about her immediate environment and resolve conflicts should they arise.
  • Platform: She has no current purpose except that of an experiment, but can be tailored to whatever function is required.

I hadn’t named her with the RIP acronym in mind but, fortunately, it fits quite nicely.

 

Intelligent Design?

As a basis for the redesign, I have managed to cobble together the following diagram, mainly to organise my thoughts into some form of coherent pattern and also to give me a bit of a starting point. I’ll eventually expand on each of the topics (the bits with the thick blue lines) to a point where there is actual code but, for now, this will serve as the basic description.

RIPleyIdeas_IV_ALPHA_v1a

RIPley: Initial Design Layout

As you can see, the left-hand part of the diagram is the hardware/software interface, featuring the RC2014 & the Pi. The right-hand portion shows my thoughts on the management software and the intelligence functions (decision making, conflict resolution etc). This is wholly Pi-based, written in C/C++ and running under Linux (Ubuntu).

 

Hardware Management:

In the Hardware Management pane you can see the Operations topics of Forward, Rear & Tilt sensors and the camera. These are the functions that will control the hardware and are detailed in the Software Control pane on the left. These function names are leftovers from the original software build used to test Ripley’s hardware, prior to this re-design.

Further Operations functions are:

  • GPS (location services) which will be provided by theĀ Adafruit HAT GPS module,
  • GSM/GPRS (mobile data) provided by a DROK SIM800 GSM module &
  • WiFi services provided by the Pi’s builtin Broadcom wireless NIC.

 

All of these Operations functions are controlled by the Management functions:

  • Forward, Rear & Tilt sensors are managed by Spatial Management (SM), giving Ripley a sense of her external environment (what’s in front, what’s behind and the direction of any incline she’s on, as well as a feed from the GPS so she knows how far from her OP (origin point) she is).
  • Camera Management (CM) controls the camera, including pan/tilt/zoom and whether nor not image recognition is required or just a feed to the ‘net.
  • Location Management (LM) monitors the GPS feed and provides GPS data to other functions as required.
  • Remote Control Management (RCM) switches between WiFi and GSM/GPRS (depending on whether recognised WiFi is in range or not) to maintain the network connection and also manages remote control instructions when requested.

 

Logic/Intelligence:

These functions provide Ripley’s ‘brain’, such that it is:

  • Image Recognition (IR) utilises basic object recognition to allow Ripley to distinguish between static objects (such as rocks, fences, walls etc) and mobile objects (cats, dogs, humans etc). This gives her the ability to decide whether or not to go round an object (as in a rock or a fence) or to wait for the object to move of its own accord (as in human or canine obstacles) or even to run away. IR works alongside the forward and rear ultrasonic sensors.
  • Collision Avoidance (CA) works alongside IR, Spatial & Location management to avoid roads (LM), mobile obstacles (IR) and static obstacles (SM).
  • Decision Making is fairly self-explanatory and works hand-in-hand with all of the other functions including :
  • Conflict Management. This function is for resolving conflicts in decisions, being the final arbiter. Not much is known about this function at the moment.

 

Epilogue:

This has been a fairly short intro to the current layout. I’m sure that it will change with time but any changes will be documented here in the blog. As each topic is developed, I will post an individual explanation of each. I’m sure there is someone out there who will find this vaguely interesting.

As always, if so inclined then leave comments but keep them clean. Ta.

Christine x