FAQ [OG4]

PERASPERA / FAQ – Frequently Asked Questions

(This FAQ and Web portal reflects the PSA consortium’s view. The EC and REA are not responsible for any use that may be made of the information it contains)

Q13 [OG4]: Is the final deliverable of OG4 a complete, implemented hardware demonstrator sensor suite with all sensor elements mentioned on pp. 20-21 –SRC_Guidelines_Space_Robotics_Technologies (COMPET-4-2016).pdf? (“In detail, the reference implementations of the INSES shall include at least the following instruments on board of the robotic vehicle or spacecraft: ..”) 

A: The expectation from this OG is indeed as outlined in the specified pages.
As mentioned in the above, deviations from this expectation should better be justified and will be assessed by the Expert Evaluators.

As a matter of clarification, all types of sensors must be actually considered at this stage in the OG4 study. It is expected that:

  • the study will allow to establish the relevance of each type of sensor for the two reference implementations
  • the final delivery for each reference implementation shall include only the relevant sensors
  • the study leads to a “plug-and-play” (interface) solution for different types of sensors

It is assumed that the work will concern only the design of the Universal Interface Unit(s) (one for each reference implementation) since the different sensors will be COTS. They will be selected taking into account their respective mass, power and volume characteristics.

Most of the standardization work will therefore focus on the interface unit (data protocol, electrical, mechanical). However mechanical standardization will be considered also for the different sensors (to be treated independently from the Interface Unit since the sensors in most applications will be non collocated).

Q14 [OG4]: Is the objective of OG4 to develop the unified mechanical, data and power interfaces for all identified sensors, including potential redesign of the sensors to allow for such interfacing with INSES?

A: Yes, as explained in p.19. Sensor redesign may be applicable if necessary to meet the expectations in the Guidelines document.
The development of a unified mechanical, data and power interfaces for all identified sensors as detailed hereafter

  • a specific mechanical interface for the Universal Interface Unit – this Unit will unify all relevant sensors (for each reference implementation) from a data and power point of view
  • a specific mechanical interface for each type of sensor (or possibly one for several types)

This will allow the introduction of a flexible plug-and-play principal for sensor systems. It is not realistic from the budget point of view to redesign the sensors. As indicated here-above, the sensors to be included will be COTS

As mentioned in the long version of the guideline on the PERASPERA website, adaptation of existing COTS features may be necessary.

Q15 [OG4] [All OGs]: Will the reference implementations (Orbital, Planetary) remain in hardware with INSES for the next phase, or are leased sensors sufficient to validate its performance in the common demonstration scenarios? 

A: The common building blocks will need to demonstrate ability to be integrated together. It remains to be defined precisely how the outputs of the first phase of OGs will be used in the next phases. Such matters will also be regulated by the Collaboration Agreement.

The objetive is to keep the sensor hardware for the activities to be pursued in the subsequent calls (this is particularly true for the Planetary Track where only ground demos are targeted). It can be envisioned however to reduce the procurement cost by not duplicating the sensors that might be present in both reference implementations.

The UE will remain the owner of all OGs deliverables.

Q16 [OG4]: Does OG4 entail any kind of software development other than the basic needs for interfacing, sensor control and data provision to OG3?

A: It is expected that the OG4 addresses the necessary developments as outlined in the guidance document (further detailed in the long version on the PERASPERA website e.g., RCOS software components).

Essentially, the software development within OG4 shall concern the basic needs for:

  • interfacing with other OGs (commands sent by OG2, data to be provided to OG3),
  • sensor control,
  • collection of sensor data
  • control of potential other devices (illumination devices)

Some low level data processing might be envisioned. The real need will be identified during the preliminary design where the detailed interface between OG3 and OG4 will be defined.

Q17 [OG3] [OG4]: We try to determine whether our current project of standalone instrument for the orbital rendezvous that incorporates not only data acquisition but also high-level treatment to extract the desired measurement (features relating to both OG3 and OG4) is admissible for the COMPET-04-2016 call.

A: First of all, we draw your attention on the text of the compendium and particularly the summary of OG3 and OG4 challenge description:

  • OG3: The challenge is the development of a software framework implementing data fusion techniques for various sensors such as LIDAR, Imagers, radar, sonar, IMUs, sun sensors, etc.
  • OG4: The challenge is to realize a suite of perception sensors that allow localization and map making for robotic inspection of orbital assets (under space representative conditions) and for planetary surface exploration.

This short summary clearly states that the SW development foreseen in OG3 aims at dealing with a large variety of sensor data types and not focusing on a particular sensor. In the same way, the sensor suite to be considered in OG4 must deal with every kind of the specified set of sensors and not a single one. As written further down in OG4 description, the emphasis is put in the inspection suite modularity and flexibility:  “ INSES shall be implemented with high modularity and flexibility in order to allow the sensor suite sub-set re-configuration. Each sensor unit shall be designed to be self-consistent with unified interfaces in order to be added/removed easily, without affecting the overall system functionality (plug-in like concept)”.

In addition, the relevance of addressing two OGs in the same proposal is evoked in this FAQ page in a previous question Q12

Q19 [OG3] [OG4] [All OGs]: Should we show, at the end of the project, that we are mastering the whole set of sensors and that these sensors can offer the required interface and modularity capabilities or should we build a complete robotic system including data processing and fusion functionalities ?

A: The first part of the alternative is the right one. It is definitely not foreseen within OG4 to build a robotic system with data processing and fusion capabilities since this would overlap with OG3 activity.

Nevertheless, it shall be proven that the OG4 end product can be interfaced with OG3 functionalities to demonstrate various capabilities of perception/navigation system. This type of activity will be performed within OG6 in coordination with all relevant OGs (OG3 for the most part). The elaboration of the demonstration requirements will be also elaborated in a collaborative mode.

Bidders attention must be drawn on what is indicated on page 5 of the “SRC Guidelines Space Robotics Technologies (COMPET-4-2016)” document:

“Even though the integration of OG outputs is in the future, all OGs need to interact in order to prepare for the future integration. The interaction among OGs will be based on:

  • Cross delivery of interface specifications
  • Cross delivery of preliminary/final outputs
  • Integration and demonstration of the final outputs of OGs in common test platforms

Each OG Consortium is expected to nominate an “interface engineer” in order to coordinate establishment and maintenance of interface specifications with other OGs.”

Q25  [OG4]: Is the final deliverable of OG4 a complete, implemented hardware demonstrator sensor suite with all sensor elements mentioned on page 20-21 – SRC_Guidelines_Space_Robotics_Technologies (COMPET-4-2016).pdf? (“In detail, the reference implementations of the INSES shall include at least the following instruments on board of the robotic vehicle or spacecraft: ..”)

A: Yes, and this suite will be subjected to tests as defined by OG6. However, note that for the reference implementation, you would need to provide an integrated test module as a fully functional representative of space models (Bread-board / DM / STM / EQM). See this paraphrased text from the PSA Technical Compendium:

“In particular: procure / manufacture all parts needed to mechanical and thermal interfaces of each sensor to agreed standard one. Also, procure / manufacture all harnesses & connections connecting the sensors to the rover / spacecraft.”

Q26 [OG4]: Is the objective of OG4 to develop the unified mechanical, data and power interfaces for all identified sensors, including potential redesign of the sensors to allow for such interfacing with INSES?

A: See Q25. Note “development” may include adaptation of COTS components where environmentally viable.

Q27 [OG4]: Does OG4 entail any kind of software development other than the basic needs for interfacing, sensor control and data provision to OG3?

A: The sensors will require software components compliant with the Operating System (OG1), so as to communicate with other software components, ie from the Autonomy Framework, or the Data Fusion Framework. The sensors may also be required to undertake some basic preprocessing / filtration of data before passing it along to the Data Fusion Framework for full processing.

Q28 [OG4]: The OG4 mentioned contact sensors for exteroceptive category which are not mentioned in OG3. Are they referring to the force/torque sensors? 

A: Generally speaking, the contact sensors allow to detect an interaction between a part of the robot and some other object that belong to the environment (ex: claws of the gripper touching an object). Of course, in some rare situations, trying to detect a possible contact between the robot and some other part belonging to the robot itself cannot be excluded. Nevertheless, it is most reasonable to state that the contact sensors belong to the exteroceptive category.

An exteroceptive sensor is usually considered as a mean to get information about the outside world. It contributes to determine the measurements of objects relative to the vehicle’s frame. From this standpoint, the difference between a contact and a tactile sensor concerns the amount of information available (which is indeed richer with the tactile sensor). This criterion should not be used to sort the sensors into proprio and exteroceptive categories.

On the other hand, proprioceptive sensors are responsible for controlling the vehicle’s internal status (ex: IMU, GPS, …) and monitoring self-maintenance (ex:  battery, current, heat monitoring…). According to this definition, torque sensors while used to determine the vehicle’s attitude (slip estimation for rovers application) belong to the proprioceptive sensors whereas torque sensors used as contact sensors belong to the exteroceptive category as explained hereabove.