Sensors and Messaging

[ryan1248]

Currently we pull data directly from the physics engine and tgModels for controllers and logging purposes. I would propose that we add sensors that can pull the data from the environment and models and provide the data in standardized message formats. These messages can then be consumed by controllers, loggers, etc. without having to have knowledge of the underlying implementation.

Some basic considerations:

• Sensors should be generally limited to what is available in the real world to facilitate transition of control code and analysis to actual robots
• ROS has quite a lot already in place around sensors, and we should be able to use their formats for this. This will have the added benefit of easing ROS integration down the line.

Components:

• Sensors (e.g. position, force, GPS, ground contact, torque, etc.) -- responsible for collecting information from the elements in the simulator
• Samplers -- responsible for pulling info from the sensors at configurable intervals
• Collectors -- responsible for marshaling the sampled data and making it available to a message handler (likely a message queue of some type).

[vsunspiral]

Thanks for adding detail to this. I like the general layout, and we should certainly be looking at ROS and Gazebo for how they handle sensor data. If we can use their infrastructure for that, even better.

ROS2.0 should include an improved middleware system based on DDS. Not sure how much that will change their messaging format.

vytas

On Sep 10, 2014, at 11:02 AM, ryan1248 notifications@github.com wrote:

Currently we pull data directly from the physics engine and tgModels for controllers and logging purposes. I would propose that we add sensors that can pull the data from the environment and models and provide the data in standardized message formats. These messages can then be consumed by controllers, loggers, etc. without having to have knowledge of the underlying implementation.

Some basic considerations:

Sensors should be generally limited to what is available in the real world to facilitate transition of control code and analysis to actual robots ROS has quite a lot already in place around sensors, and we should be able to use their formats for this. This will have the added benefit of easing ROS integration down the line. Components:

Sensors (e.g. position, force, GPS, ground contact, torque, etc.) -- responsible for collecting information from the elements in the simulator Samplers -- responsible for pulling info from the sensors at configurable intervals Collectors -- responsible for marshaling the sampled data and making it available to a message handler (likely a message queue of some type). — Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral
Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

[kcaluwae]

They already have some examples for the ROS 2.0 message format. It seems similar to the old, but I guess that the API is not stable yet. for example: https://github.com/ros2/examples/blob/master/simple_msgs/msg/AllDynamicArrayTypes.msg

2014-09-10 22:30 GMT+02:00 Vytas SunSpiral notifications@github.com:

Thanks for adding detail to this. I like the general layout, and we should certainly be looking at ROS and Gazebo for how they handle sensor data. If we can use their infrastructure for that, even better.

ROS2.0 should include an improved middleware system based on DDS. Not sure how much that will change their messaging format.

vytas

On Sep 10, 2014, at 11:02 AM, ryan1248 notifications@github.com wrote:

Currently we pull data directly from the physics engine and tgModels for controllers and logging purposes. I would propose that we add sensors that can pull the data from the environment and models and provide the data in standardized message formats. These messages can then be consumed by controllers, loggers, etc. without having to have knowledge of the underlying implementation.

Some basic considerations:

Sensors should be generally limited to what is available in the real world to facilitate transition of control code and analysis to actual robots ROS has quite a lot already in place around sensors, and we should be able to use their formats for this. This will have the added benefit of easing ROS integration down the line. Components:

Sensors (e.g. position, force, GPS, ground contact, torque, etc.) -- responsible for collecting information from the elements in the simulator Samplers -- responsible for pulling info from the sensors at configurable intervals Collectors -- responsible for marshaling the sampled data and making it available to a message handler (likely a message queue of some type). — Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-55178159 .

[ryan1248]

Just wanted to add some great resources from Brian and Zack Moratto: https://github.com/ros2 http://design.ros2.org/

And from Vytas: "I just chatted with the ROS lead from OSRF and he confirmed that they have a full prototype of ROS working on top of DDS with QOS management."

So, that may tip the scales a bit toward targeting the ROS 2.0 messaging.

[vsunspiral]

sounds like it may be a year before ros2.0 is released. we should consider starting with ROS as is, and hang with them as they migrate.

On Sep 17, 2014, at 5:00 PM, ryan1248 notifications@github.com wrote:

Just wanted to add some great resources from Brian and Zack Moratto: https://github.com/ros2 http://design.ros2.org/

And from Vytas: "I just chatted with the ROS lead from OSRF and he confirmed that they have a full prototype of ROS working on top of DDS with QOS management."

So, that may tip the scales a bit toward targeting the ROS 2.0 messaging.

— Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral
Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

[ryan1248]

So it seems that the messaging is really a separate entity from the message transport/queueing. Basically, messages are defined in a text format and then a code generator is used to create appropriate classes/structs/etc. for different languages. In the case of c++, there is a generator that takes the message definition files (.msg format for ROS 1.x; DDS's .idl format for ROS 2.0) and turns them into c++ header files that contain usable message structs. This can be fairly easily incorporated into our build procedure (e.g. look for new/updated .idl files in a particular directory; if found use the generator to create the header files and put them somewhere appropriate; then continue with the build process).

I believe that this is something that we can do now regardless of any further integration/dependency on ROS.

[vsunspiral]

awesome! love it! yes, getting onboard with their messaging system is the first step. From there we can choose what other services that we would like to start using out of the broader ROS ecosystem. vytas

On Sep 17, 2014, at 5:11 PM, ryan1248 notifications@github.com wrote:

So it seems that the messaging is really a separate entity from the message transport/queueing. Basically, messages are defined in a text format and then a code generator is used to create appropriate classes/structs/etc. for different languages. In the case of c++, there is a generator that takes the message definition files (.msg format for ROS 1.x; DDS's .idl format for ROS 2.0) and turns them into c++ header files that contain usable message structs. This can be fairly easily incorporated into our build procedure (e.g. look for new/updated .idl files in a particular directory; if found use the generator to create the header files and put them somewhere appropriate; then continue with the build process).

I believe that this is something that we can do now regardless of any further integration/dependency on ROS.

— Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral
Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

[ryan1248]

@vsunspiral Sounds great -- translating messages between the .msg (ROS 1.x) and .idl (ROS 2.0) formats seems pretty straightforward.

As for pub/sub message transport, it is quite possible that we can write a simple internal pub-sub engine that is compatible with the ROS pub-sub API. It wouldn't be able to talk outside the application, but it would allow us to start building things in such a way that we can swap out our internal pub-sub for the ROS service later without requiring significant code changes.

[chiku00]

Sorry to be a noob here but I didn't get how can I pull information regarding forces in the various elements from the physics engine. I need to collect data regarding nodal positions and forces being transmitted. Could someone please help me in regards to acquiring data mentioned in the above lines? If 'sensors' have indeed been added, how can I use it dump necessary information into, say, a text file?

[brtietz]

tgSpringCable.getTension() can provide that information: https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/blob/master/src/core/tgSpringCable.h

the tgBasicActuator class inherits this method. You'll have to extrapolate from there to individual nodes.

As far as dumping this to a text file, we have the classes that are in src/sensors. These needs to be implemented within the controller class currently (see examples/learningSpines/BaseSpineCPGControl).

Brian

On Tue, Sep 15, 2015 at 11:05 AM, chiku00 notifications@github.com wrote:

Sorry to be a noob here but I didn't get how can I pull information regarding forces in the various elements from the physics engine. I need to collect data regarding nodal positions and forces being transmitted. Could someone please help me in regards to acquiring data mentioned in the above lines? If 'sensors' have indeed been added, how can I use it dump necessary information into, say, a text file?

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-140485683 .

[chiku00]

By implementing, you mean I need to add the header files 'tgDataLogger' and 'tgDataObserver' to, say, NestedStructureSineWave.cpp from NestedTetrahedrons?

I also found, in 'NestedStructureSineWave.cpp', that I'm able to get Tension values (Line 74) from 'stringList'. So in the data logger, I can call 'std::vector<tgBasicActuator*> stringList' to call stringList to get the current values of tension?

It would be great if you could tell me using this example of NestedTetrahedrons as I'm able to understand what's going on inside much better as compared to BaseSpineCPGControl. I believe both do use controllers (Impedence for the former)

[brtietz]

The data logger is actually a little bit savvier than that, it takes care of all of that for you, via the dataObserver.

Adding one to your controller only takes 4 steps:

(1) Define data observer in your header, including the include. You may also need to add the sensors library to your cmake file to make it link properly.

(2) Declare it in your constructor, including the folder where you want logging to occur (relative path)

(3) Call dataObserver.setup in your controller's onSetup function

(4) Call dataObserver.step in your controller's step function.

Finally, I recommend adding conditional compiles around 3 & 4 so you only log when you want to log.

To utilize the example I recommended, try doing a search (find or ctrl-f) on tgDataObserver and m_dataObserver in BaseSpineLearning Controller, that should filter out the noise for you.

On Thu, Sep 17, 2015 at 9:00 AM, chiku00 notifications@github.com wrote:

By implementing, you mean I need to add the header files 'tgDataLogger' and 'tgDataObserver' to, say, NestedStructureSineWave.cpp from NestedTetrahedrons?

I also found, in 'NestedStructureSineWave.cpp', that I'm able to get Tension values (Line 74) from 'stringList'. So in the data logger, I can call 'std::vector stringList' to call stringList to get the current values of tension?

It would be great if you could tell me using this example of NestedTetrahedrons as I'm able to understand what's going on inside much better as compared to BaseSpineCPGControl. I believe both do use controllers (Impedence for the former)

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-141132419 .

[chiku00]

I compared 'NestedStructureSineWaves.cpp' and 'BaseSpineCPGControl.cpp' and was able to identify the 'onStep' part of your instructions (Step 4). So I guess the logger (when it does data acquisition) can only be implemented via a controller. Now, if I just want to use my mouse and prod the object and still acquire data regarding the elements, I only need to make sure that I'm not messing around with the string tensions (setTension, line 93, NestedStructureSineWaves.cpp). The logger needs a way to look at the state of the structure at every time instant. Now, I can ether some how implement it directly into the simulation engine and acquire data (regardless whether there's a contoller (NestedTetrahedron) or not (3Prisms)), or I can couple it with a controller which gets called at every time step. This, hopefully, I understand.

Now regarding the 'onSetup' (Line 200, BaseSpineCPGControl), the logger, I guess, needs to log the initial conditions of the system. But then, if that is its purpose, can we not skip it all together because the logger in 'onStep' will record the data at time = 0, right?

That and the fact that, like in '3Prisms', my initial conditions are defined in the 'PrismModel.cpp'. So, do I call the 'onSetup' function of 'DataObserver' in that file after I've setup the entire model (defined rods and strings)? Or do you want me to call it inside the function 'applyImpedanceControlOutside' (Line 84, NestedStructureSineWaves.cpp)?

Apart from this, I did step 1 (add include) inside 'NestedStructureTestModel.h'. Declared it inside the constructor in 'NestedStructureTestModel.cpp' along with the file name. This is what I'm getting when I build it:

You can see the error description in the Terminal and behind it is the text file in which the error is popping up. The files themselves are in the '3_prism_data_acquisition' folder here: https://www.dropbox.com/sh/fm1x423373u5aw4/AADE8wTX3ppPx6KAoJ7p_ckta?dl=0

You recommended adding 'Conditional Compiles' around the logger to log when I want. Regarding this, how do I ask it to start logging? Is there some sort of flag that I raise to start logging or something?

[brtietz]

Answers inline:

On Sun, Sep 20, 2015 at 2:02 AM, chiku00 notifications@github.com wrote:

I compared 'NestedStructureSineWaves.cpp' and 'BaseSpineCPGControl.cpp' and was able to identify the 'onStep' part of your instructions (Step 4). So I guess the logger (when it does data acquisition) can only be implemented via a controller. Now, if I just want to use my mouse and prod the object and still acquire data regarding the elements, I only need to make sure that I'm not messing around with the string tensions (setTension, line 93, NestedStructureSineWaves). The logger needs a way to look at the state of the structure at every time instant. Now, I can ether some how implement it directly into the simulation engine and acquire data (regardless whether there's a contoller (NestedTetrahedron) or not (3Prisms)), or I can couple it with a controller which gets called at every time step. This, hopefully, I understand. Now regarding the 'onSetup' (Line 200, BaseSpineCPGControl), the logger, I guess, needs to log the initial conditions of the system. But then, if that is its purpose, can we not skip it all together because the logger in 'onStep' will record the data at time = 0, right? That and the fact that, like in '3Prisms', my initial conditions are defined in the 'PrismModel.cpp'. So, do I call the 'onSetup' function of 'DataObserver' in that file after I've setup the entire model (defined rods and strings)? Or do you want me to call it inside the function 'applyImpedanceControlOutside' (Line 84, NestedStructureSineWaves.cpp)?

The controller needs to have an onSetup function and it needs to be called there. This initializes some model dependent aspects of the observer and writes the log file's header.

Another question: what is the difference that you intended to make between 'applyImpedanceControlOutside' and 'applyImpedanceControlInside' (Line 64, same file)? They both look the same, apart from the fact that at one place, the tensions are getting changed.

The control argument in outside takes a velocity, whereas in inside it defaults to zero. This is what allows for the velocity trajectory in the control of the outside cables, and therefore movement.

Apart from this, I did step 1 (add include) inside 'NestedStructureSineWaves.h' and defined the 'm_Observe' inside its private class (mimicking BasePineCPGControl.h).

You recommended adding 'Conditional Compiles' around the logger to log when I want. Regarding this, how do I ask it to start logging? Is there some sort of flag that I raise to start logging or something?

I was referring to lines like:

define LOGGING

ifdef LOGGING

#endif This is an easy way to turn logging on when you compile, since by commenting out one line you can turn off whole behaviors. If you just leave the lines in without the conditional compile it will log every time (assuming you have the correct call in onSetup and onStep). Note you may also have to add notifySetup() to the model in order to run onSetup in the controller. > — > Reply to this email directly or view it on GitHub > https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-141759422 > .

[chiku00]

But I see that 'NestedStructureSineWaves.cpp' only has a onStep function and no 'onSetup'. So how about this: In 'AppPrismTetrahedrons.cpp', I initialize 'm_DataObserver' with the path where I want to log the data. Inside 'NestedStructureTestModel.cpp', I call m_observer.onSetup' after setting up the children by passing the '*this' pointer. This takes care of 'onSetup'. Coming back to 'AppPrismTetrahedrons.cpp', while I initialize 'pMuscleControl' (type NestedStructureSineWaves), I'll pass the address of 'm_observer' to the constructor of 'NestedStructureSineWaves'. This way, I'll have taken care of 'onStep'.

Other than this, I see no other way as neither 'NestedStructureSineWaves.cpp' has a 'onSetup' (it is a controller, right? It's job is to control the structure after all) nor do controllers like impedance controller have 'onSetup' nor 'onStep'.

[chiku00]

The main problem that I see in the above approach is that DataObserver.onSetup() and DataObserver.onStep() both need 'tgModel'. Going back to 'BaseSpineCPGControl.cpp', I see that it accepts a class called 'BaseSpineModelLearning' which does not appear to be the same as tgModel. So how can that work? BaseSpineModelLearning I was able to take care of 'onSetup' because I ran it inside 'NestedStructureTetrahedron.cpp' where 'tgModel' was being used. But for 'onStep', where would you have me run it?

[chiku00]

Ok, I've tried every way I could think of to implement what you suggested but I'm always getting errors like 'not defined' and what not even though I defined them publicly. Here's the working model I wanted to acquire data from: https://www.dropbox.com/sh/98fnicme0t417j5/AAAx756Xfz5vToY6bAPaYTR1a?dl=0 If someone can add the necessary lines which would allow me to acquire data regarding forces in the members, it would be most appreciated.
'BaseSpineCPGControl.cpp' actually has both onSetup and onStep in it. But the model I'm after has it in discrete files: one where the model and children are put together (onSetup); another where the forces in the string are made to change incrementally (onStep).

Don't know if this will help but here are the same files with the attempts I made to incorporate the changes: https://www.dropbox.com/sh/fm1x423373u5aw4/AADE8wTX3ppPx6KAoJ7p_ckta?dl=0

[brtietz]

The trick is to define the onSetup function for NestedStructureSineWaves. It already has these functions since it is a subclass of tgObserver (located in core), but you need to override them to use the logger. Add onSetup((NestedStructureTestModel& subject) to NestedStructureSineWaves.h, and then add it to the .cpp file with your implementation (just calling tgDataObserver.setup(subject)).

Our definition of sensors vs controllers is a little fuzzy right now, this is something we want to refine in the future. For now, its better to have these functions in the controller than in the model.

On Tue, Sep 22, 2015 at 1:12 AM, chiku00 notifications@github.com wrote:

Ok, I've tried every way I could think of to implement what you suggested but I'm always getting errors like 'not defined' and what not even though I defined them publicly. Here's the working model I wanted to acquire data from: https://www.dropbox.com/sh/98fnicme0t417j5/AAAx756Xfz5vToY6bAPaYTR1a?dl=0 If someone can add the necessary lines which would allow me to acquire data regarding forces in the members, it would be most appreciated.

'BaseSpineCPGControl.cpp' actually has both onSetup and onStep in it. But the model I'm after has it in discrete files: one where the model and children are put together (onSetup); another where the forces in the string are made to change incrementally (onStep).

Don't know if this will help but here are the same files with the attempts I made to incorporate the changes: https://www.dropbox.com/sh/fm1x423373u5aw4/AADE8wTX3ppPx6KAoJ7p_ckta?dl=0

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142208609 .

[chiku00]

Well, upon adding 'sensors' to the 'CMakeLists.txt', it compiled alright but the executable only runs when I comment '#define LOGGING'. Else, upon clicking the executable, it opens and then closes immediately (my guess it's crashing). Could someone else run it on their system and see if it compiles and runs? Also, where would the log file be created? In the same directory where the source code is? https://www.dropbox.com/sh/fm1x423373u5aw4/AADE8wTX3ppPx6KAoJ7p_ckta?dl=0 Regarding that, this is what I wrote:

[chiku00]

Under learningSpines, only 'AppTetraSpineSerial' is working when I un commented '//#define LOGGING' in 'BaseSpineCPGControl.cpp'. They all start working when I comment '#define LOGGING'. If indeed these modules were working for you on your PC, it is possible that something might be amiss with mine, right? I checked 'tgDataObserver.cpp' and this seemed interesting: " throw std::runtime_error("Logs does not exist. Please create a logs folder in your build directory or update your cmake file"); " (line 91). I guess this means that, inside the build directory, there has to be a folder called 'logs'. In fact, going back to 'BaseSpineCPGControl.cpp', I find that the input to 'm_dataObserver' is 'logs/TCData'. Does this mean that I have to also create another folder inside 'logs' by the name 'TCData'? Also, since I'm using Ubuntu, I noticed a 'lock' icon on the 'build' folder inside 'NTRTsim-1.1'. So I guess, I'll have to remove that lock before I create those two new folders.

[chiku00]

I tried to create a folder 'logs' inside builds and 'TCData' inside that, but even that didn't work. That last part of line 91: "...or update your cmake file" ; what do I update it to?

[brtietz]

Sorry for the slow response. The logs folder needs to be in the same folder as the executable. So if your path is build/examples/NestedTetrahedrons then the logs folder would be at build/examples/NestedTetrahedrons/logs

TCData is the file prefix, the date and time will be appended to that.

On Wed, Sep 23, 2015 at 12:55 AM, chiku00 notifications@github.com wrote:

I tried to create a folder 'logs' inside builds and 'TCData' inside that, but even that didn't work. That last part of line 91: "...or update your cmake file" ; what do I update it to?

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142523625 .

[chiku00]

I've yet to try it out, but is that why it didn't run? It compiled alright. And it was not just my code; even the code under LearningSpine did not execute (except one, read my previous comments). Hopefully this works and I start getting some outputs. BTW, do I need to be concerned about the cmake file? I mentioned it in the previous comment.

[brtietz]

Yes, there is an exception in the data observer code if the logs file does not exist.

The CMake file can be configured to create the folder automatically, but we've moved away from that after introducing the resources directory.

On Wed, Sep 23, 2015 at 8:51 AM, chiku00 notifications@github.com wrote:

I've yet to try it out, but is that why it didn't run? It compiled alright. And it was not just my code; even the code under LearningSpine did not execute (except one, read my previous comments). Hopefully this works and I start getting some outputs. BTW, do I need to be concerned about the cmake file? I mentioned it in the previous comment.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142645772 .

[chiku00]

It is still not executing. Compiles fine and even executes when I comment #define Logging. But not without comments. Can someone else try to running it on their pc?

[chiku00]

I made a logs file inside TetraSpin (build/...) and tried to execute AppTetraSpineLearning but even that is failing to execute.

[brtietz]

What is the error when they fail to execute?

Is the code on your dropbox from the other thread the code that fails?

Have you gotten rid of the lock on the build folder? If not, how did you build? - you should have full write access to the folder.

On Wed, Sep 23, 2015 at 9:11 AM, chiku00 notifications@github.com wrote:

I made a logs file inside TetraSpin (build/...) and tried to execute AppTetraSpineLearning but even that is failing to execute.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142650637 .

[chiku00]

When I execute build.sh, I use sudo. The files I'm having trouble with are here: https://www.dropbox.com/sh/fm1x423373u5aw4/AADE8wTX3ppPx6KAoJ7p_ckta?dl=0 Just cut and paste them in the folder 'NestedTetrahedron'. Everything is there. You can see for yourself: comment the #define logging and it executes without any hic-ups. Un comment it and the executable doesn't even run. I'm having the same issue with the executables in 'LearningSpine' (see my comments). From what you said before, I see the build folder should be unlocked. FYI, I made those folders (logs) using sudo also. Since the executable will be writing logs while the program is running, I see I need to unlock the build folder.

[chiku00]

There is no error message. It builds just fine. When I click the executable, it opens and closes almost immediately.

[brtietz]

Delete the build folder, run bash build.sh (no sudo), and then rebuild the logs folder

If you run the executable from the command line, you will get more useful error messages. Navigate using cd, then put ./ in front of the executable name.

On Wed, Sep 23, 2015 at 10:13 AM, chiku00 notifications@github.com wrote:

There is no error message. It builds just fine. When I click the executable, it opens and closes almost immediately.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142667489 .

[chiku00]

Yes, I got the error: Segmentation fault (core dumped) I'm looking up what that means right now. I ran yours and it executed without a hitch (after I made the logs folder). And my god. You weren't kidding about data I needed getting dumped. It's a mountain of data. And the simulation ran only for like 6 sec before I closed it. Anymore, and I would have run out of space.

[chiku00]

I think this might be the issue: Where do I call 'void NestedStructureSineWaves::onSetup(NestedStructureTestModel& subject)' ? I've only created it inside the 'NestedStructureSineWaves.cpp' (and defined it in the header file). I don't see where I can call it from This is the only place this can be an issue as the only other place m_dataObserver was used was inside 'void NestedStructureSineWaves::onStep...' where things were already working.

[vsunspiral]

have you run with GDB to see where the segmentation fault is happening?

vytas

On Sep 23, 2015, at 11:19 AM, chiku00 notifications@github.com wrote:

Yes, I got the error: Segmentation fault (core dumped)

— Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral
Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

[brtietz]

onSetup is called after notifySetup() in your model. I don't expect that would cause a segfault though...

Here's a good GDB tutorial: http://www.cs.umd.edu/~srhuang/teaching/cmsc212/gdb-tutorial-handout.pdf

On Wed, Sep 23, 2015 at 12:05 PM, Vytas SunSpiral notifications@github.com wrote:

have you run with GDB to see where the segmentation fault is happening?

vytas

On Sep 23, 2015, at 11:19 AM, chiku00 notifications@github.com wrote:

Yes, I got the error: Segmentation fault (core dumped)

— Reply to this email directly or view it on GitHub.

---

Vytas SunSpiral Dynamic Tensegrity Robotics Lab cell- 510-847-4600 Office: 650-604-4363 N269 Rm. 100

Stinger Ghaffarian Technologies Intelligent Robotics Group NASA Ames Research Center

I will not tiptoe cautiously through life only to arrive safely at death.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142699494 .

[chiku00]

If you say so, because i didn't set that in notifySetup(). I don't even know where it is.

[brtietz]

Ah, not calling it might cause the fault. Put notifySetup(); at the end of your model's setup function.

For details see the subject and observer base classes in core: https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/blob/master/src/core/tgSubject.h https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/blob/master/src/core/tgObserver.h https://en.wikipedia.org/wiki/Observer_pattern

On Wed, Sep 23, 2015 at 12:14 PM, chiku00 notifications@github.com wrote:

If you say so, because i didn't set that in notifySetup(). I don't even know where it is.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142701424 .

[chiku00]

It worked. I looked through the files pertaining to 'AppTetraSpineLearning' but found no mention of notifySetup(); being called. I remember it vaguely because i just noticed where i actually saw it: in '3-prism'. It seems a bit strange that you would notify a controller which ought to be non-existent inside '3-prism' (it's not using a controller, it's not moving, atleast) while it is missing from files related to a model that is actually being controlled.

[brtietz]

This is handled as a part of BaseSpineModelLearning::setup(world);

Brian

On Wed, Sep 23, 2015 at 9:15 PM, chiku00 notifications@github.com wrote:

It worked. I looked through the files pertaining to 'AppTetraSpineLearning' but found no mention of notifySetup(); being called. I remember it vaguely because i just noticed where i actually saw it: in '3-prism'. It seems a bit strange that you would notify a controller which ought to be non-existent inside '3-prism' (it's not using a controller, it's not moving, atleast) while it is missing from files related to a model that is actually being controlled.

— Reply to this email directly or view it on GitHub https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/issues/74#issuecomment-142806992 .

[apsabelhaus]

To folks following this issue: see master as of commit dd5b3b7. There is a new sensing framework that takes care of a lot of what's being discussed here, and has functionality for message passing if other folks want to implement it.