smallsatgasteam / openspa Goto Github PK

• Work out of the tutorial branch
• Initialize a component in the test and call the sendMsg method
• Understand and utilize the file's test fixture
• The test should pass if bool sent is true

As documented in Appendix B of Jacob Christensen's dissertation

A median filter is a useful algorithm for when you need to rely on valid data points from noisy data. It is well documented in this short writeup. Nick wrote a median filter for our previous payload, but it wasn't tested very extensively and may require modifications.

The median filter should be placed in lib/components and inherit from Component

• Write the marshalling/unmarshalling to not require elevated privileges (i.e., don't change read-only memory)
• Get a localHello/localAck dialogue working
• Remove every instance of typedef Com. It's a little too vague, especially with multiple definitions across the projcet.

Particularly testing the listen method

Update doxygen documentation. The alliteration was necessary.

The aggregator component needs to receive all of the data from every other sensor and aggregate it into a single string for transmission to things such as a screen, radio, or SD reader. It should be a class in lib/components and inherit from Component

This assignment will involve working with physical hardware in the GAS laboratory.

We are finally at the point in which we can start writing SPA wrappers for our physical devices! A SPA wrapper is basically a class that takes the drivers for a given sensor and arranges its functionality into something that is SPA-compliant. Essentially, it should arrange the sensor's output into SpaData messages, handle incoming messages in a meaningful way, and handle other sensor-specific logic.

The SPA wrapper should be in lib/components and inherit from Component

The Boom component will receive filtered barometric readings from the MedianFilter and commands from the radio.

This, of course, requires interfacing the device with the Beaglebone Black. Study our previous payload code to get an idea of how things will work!

• Need to research and develop more fine grained communicator tasks

• Physical communicators, especially the local communicator need to be able to send actual SPA messages.

• Should implement both send and listen methods, and be able to effectively handle received messages

Weehaa!

• The subnet manager now can handle receiving messages. This can be seen in src/subnet_manager_driver.cpp. We now however need to add logic to deal with messages when they arrive.
  This will include:
• Adding component List
• Responding to messages
• Component health checks

This assignment will involve working with physical hardware in the GAS laboratory.

We are finally at the point in which we can start writing SPA wrappers for our physical sensors! A SPA wrapper is basically a class that takes the drivers for each sensor and arranges their functionality into something that is SPA-compliant. Essentially, it should arrange the sensors' output into SpaData messages, handle incoming messages in a meaningful way, and handle other sensor-specific logic.

The SPA wrapper should be in lib/components and inherit from Component

The SensorData component will specifically be a wrapper to handle all of our strictly data-producing components:

• BNO055 Gyroscope
• MCP9808 Temperature sensor
• DS1307RTC Clock
• CoolSat Barometer
• TinyGPSPlus
• uCamII Camera

This, of course, requires interfacing the sensor with the Beaglebone Black. Study errno_3's code to find the necessary libraries and see how to use each sensor!

This assignment will involve working with physical hardware in the GAS laboratory.

We are finally at the point in which we can start writing SPA wrappers for our physical devices! A SPA wrapper is basically a class that takes the drivers for a given sensor and arranges its functionality into something that is SPA-compliant. Essentially, it should arrange the sensor's output into SpaData messages, handle incoming messages in a meaningful way, and handle other sensor-specific logic.

The SPA wrapper should be in lib/components and inherit from Component

The logging/radio component will specifically be a SPA wrapper for the radio, SD reader, and printing to the screen. It will receive data from the SensorData component in the form of strings, and the radio will send commands to the camera in SensorData and the Boom.

This, of course, requires interfacing the devices with the Beaglebone Black. Study our previous payload code to find the necessary libraries and see how to use each one!

• Develop more fine grained local subnet manager tasks
• Should contain Local communicator
• Should be able route messages to components, and other subnet managers

Figure out how to get GMock working, and then integrate that solution into the Vagrantfile

This assignment will involve working with physical hardware in the GAS laboratory.

We are finally at the point in which we can start writing SPA wrappers for our physical sensors! A SPA wrapper is basically a class that takes the drivers for a given sensor and arranges its functionality into something that is SPA-compliant. Essentially, it should arrange the sensor's output into SpaData messages, handle incoming messages in a meaningful way, and handle other sensor-specific logic.

The SPA wrapper should be in lib/components and inherit from Component

This, of course, requires interfacing the sensor with the Beaglebone Black. Study our previous payload code to find the necessary libraries and see how to use each sensor!

• Components need to be able to send messages. How should this work?

• We should implement a barebones "hello world" sort of component that just registers itself with the local subnet manager

When components send the local hello message one of the fields is 'Component Type'. This allows a subnet manager to know if it is talking to another subnet manager, or other special component. The actual values of this field and there meanings appear not to be documented. We need to come up with a good way to list out these component types and there meanings such that they can be shared across the entire system.