Python peripherals

[jakerye]

Summary

This change introduces a way to interface with sensors and actuators directly from the pi. The goal of this is create the option to run the brain without the use of an arduino.

Motivation

Before the bespoke serial messaging protocol, the communication between the raspi and arduino was unreliable. This was a parallel development effort to create a stable system as fast as possible. It was also required for integrating the brain box code into the main software stack. Furthermore, running all code on a single board simplifies the system.

Details

New nodes are added and named with a functional prefix. E.g. sensor_am2315 or actuator_relay. Nodes manage rostopics and event loops. The nodes call a helper module for each device (e.g. am2315 or relay) found in the peripheral directory. It is here where all the code for actually interfacing with the device sits.

This PR interfaces with the following:

• Sensors

  • am2315 temp & humid sensor
  • ds18b20 water temp sensor
  • mhz16 co2 sensor
  • atlas ph sensor
  • atlas ec sensor

• Actuators:

  • hid 16 channel relay (driven via usb)
  • individual relay (driven via gpio)

• UI:

  • touchscreen (official raspberry pi 7") that simple displays the sensor values

Drawbacks

Running timing sensitive code will not be possible from this approach.

Alternatives

• Bespoke serial protocol w/arduino
• Beaglebone where timing sensitive code runs on one of the x2 programable real time units (PRUs)

[CarrierDirectJoe]

So this is going to pull out support for PFC1? I'm finding myself stuck trying to figure out where I'm going to take the legacy hardware. There are a number of design flaws including weak sensors in PFC1 but the cost to retrofit it to be entirely a PFC2 ecosystem I might as well just toss them and build PFC2s. At least the PFC1's have working lights tho. :-)

[sp4ghet]

We're kind of exploring a couple different configurations to see which method of implementation will provide the most value for us in regards to hardware. Either way, we will probably be heading in a way where anyone with different hardware needs to write a way to interface that with ROS.

The contract will be publishing and subscribing to environmental variable topics defined under the launch/personal_food_computer_var_types.yaml and everything else aside from that will be considered free reign.
The way I would do this for PFC1 hardware would probably be to write a node that handles the arduino (similar to nodes/arduino_handler.py under the bespoke_serial branch) and an accompanying Arduino sketch. (The analogy for this would be hardware manufacturers writing firmware and a driver for their hardware).

[rbaynes]

Is this the correct path? You sure it shouldn't be source ~/catkin_ws/devel/setup.bash ?

[sp4ghet]

For this install script it's the correct one, but it no longer works with this install script so I will rewrite accordingly

[rbaynes]

LGTM. I'll leave it up to @spaghet to merge this if it is ready.

[rbaynes]

Si, es bueno.

[edcafenet]

Practicing Spanish Rob? ;)

…

On Jun 23, 2017 8:49 AM, "Rob Baynes" ***@***.***> wrote: ***@***.**** approved this pull request. Si, es bueno. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#278 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASauPKJQxCEdF0J8aNvNXUsAZIYq-0SNks5sG7RqgaJpZM4N6al_> .

[rbaynes]

LGMT