Please note the update to the Message structure. A unique random ID has been added to each message (auto-generated upon instantiation). Timestamp implementation has also been added (also auto-generated). The code has been added below (Just kidding, formatting fail, here's a Gdrive Link instead). It currently resides in the MonitoringAndLogging section of the 411 repository - Whoever is keeping the repos updated should update the 440 one with version 5 of the Message class.
As an example, here is how you create a message - notice the order of the parameters, this is important. Also notice how you are not passing in timestamp, checksum or uuid parameters - these are automatically created.
In order to decode a message coming from the serial port as a JSON string, you should use the following method. It returns a fully populated message object:
Health Code implementation rules and dictionaries are currently in development - We are still deciding whether this assigns a priority to the message, designates its type (error, control, info, ect) or both. If you have any ideas, feel free to contribute in the comments. The Payload formatting is still up to teams to decide - if nobody puts out anything in the next two weeks, the monitoring and logging team will step in and start putting together a standard.
Thursday, September 29, 2016
Tuesday, September 27, 2016
Drivetrain System Team Meeting and Progress Report
The Drivetrain System primary focus is on the basic movements of a Tesla car; getting the car to drive forwards, backwards, turn left and right, reverse, and stop. Below, are the details of our team member roles and the progress of our Drivetrain System project thus far.
Team Member Roles:
- Rahul - Team Leader, Project Manager, Python Developer, Linux, Pi,
- Tapan - Android Developer
- Gee - Python Developer, Linux, Pi
- LaQuelle - Android Developer
- Joe - Android Developer, Linux, Pi
- Klaus - Python Developer, Linux, Pi
Team meetings take place twice a week.
Recent Meeting - Monday, September 26, 2016
Python & Linux Development Progress:
The programming for the basic movements of the Tesla car has been making progress. We managed to get the car able to drive, park, and reverse. Work is still being done on enabling the car to make right and left turns. We are also currently working on getting the speed of the car to increase and decrease.
Android Development Progress:
- Downloaded and installed Android Studio
- Managed to have installed Android Studio up and running and programmed it to communicate with the Nexus 7
- We are making tests for the Raspberry Pi Camera to link to the Nexus 7
- Rough drafts for the dashboard are being made
Team 4 Lighting System Meeting notes
Team Meeting
9/26/16 (1 hr)
- · Discussed tasks that need to be completed.
- · Went over how to use JIRA properly and how to create a new task.
o
Acceptance criteria: don’t say a story is
complete without all tasks being meet.
o
Additional noted: anything that needs to be done
before you complete (ex. Talk to Joe)
- · Discussed Android app and choose to use toggles and let it ssh into the pi.
o
Decided we may need to get more led lights from
Joe.
§
Thought of possible issue with displaying two
lights at same time.
§
Going to ask if we can get more leds.
- · Discussed what we are going to go through in class tomorrow.
- · Andrew caught group up to what is happening in 411.
o
Talked about socket programming.
Team Meeting
9/27/16(Class time)
- · During this meeting we started to finalize out requirement docs.
- · Some group members went over the Android Studio app and how to add more buttons and how to code it correctly.
Energy Management - Team 5
1. Overview
·
This project is to
create an automotive system with use of Raspberry Pi and Grove Pi sensors.
·
The project will provide
technical and functional requirements for the automotive system to the IST 411
course, which is an Integration Development Company.
·
The Energy Management
system intends to communicate with other sub systems to alert any changes in depletion
of power and provide further instructions to follow.
·
This project is based on
open source energy-monitoring system that will support sensors for electricity,
gas and oil usage and subsequently reduce the energy costs.
·
The Grove-Pi supported
sensors will be used for sending data to another web-connected Raspberry Pi
systems.
2.
Requirements
·
Sensor indicating when
we need an oil change----at what mileage
·
Sensor indicating when
emission testing is scheduled for---yearly
·
Sensor indicating when
battery is low--range indicator
o GrovePi LED Bar
·
Sensor indicating when
heating/cooling is depleting energy level
·
Android App
o Design UI to enable users to understand how much
energy is being consumed
3.
Team Roles
|
Project Team Roles
|
|
|
Chaitali Patel
|
Project manager:
Monitoring and reporting project progress, Updating Requirements and other
documentations, Resource and Budget Planning.
|
|
Shubham Patel
|
Android Studio
programmer, UI designer
|
|
Amanda L. Neal
|
Android Studio
programmer, UI designer
|
|
Vinh Nguyen
|
Linux operator and
shell scripting, Python programmer
|
|
Brian Hoyer
|
Linux operator and
shell scripting, Python programmer
|
|
Jeannie Rodriguez
|
Linux operator and
shell scripting, Python programmer
|
Braking System Team Meeting and Concept Overall
The current status of our Braking System project and progress are listed below. Please keep in mind, these concepts are subject to change. This is not the final concept, and it will change depends situation.
Project Role
Project Manager, Linux Operator: Abu Bakar Sakif
Python Developer: David Austin, Qili Jian
Android Developer: Qili Jian, Abu Bakar Sakif
Android UI Design: Chakman Fung, Gary Martorana
Code modifier: Abu Chowdhury
Bill of Material
Two Types of Braking System
System requirement
Android UI
Meetings Times :
Previous Meetings :
08/26/16 : Discussion on what needs to be done for Braking System
09/17/16 : Discussion on Android development
09/21/16 : Discussion on the requirements and development
Meetings after class done every week to follow up on progress.
Braking System will be using a relay to simulate braking. The GoPi Go will use the ultra sound sensors to detect approaching object and cut power to the engines and run the wheel backwors if needed.
Project Role
Project Manager, Linux Operator: Abu Bakar Sakif
Python Developer: David Austin, Qili Jian
Android Developer: Qili Jian, Abu Bakar Sakif
Android UI Design: Chakman Fung, Gary Martorana
Code modifier: Abu Chowdhury
Bill of Material
- Relay (connect to Raspberry pi and Electric motor or clamp)
- Electric motor (backward for braking)
- Electric clamp (clamp the rotor for braking)
Two Types of Braking System
- Electronic Braking System (Using ultrasonic Sensor)
- Disc Braking System ( will be simulate in the project)
System requirement
- The vehicle should stop within a reasonable distance.
- When brake applied, it should give message to lighting system to turn on the braking light.
- Using Nexus tablet to control the communication between Android and Raspberry Pi
- When brake applied, it should have braking actions going on in the clamp or electric motor.
- Ultrasonic Sensor should detect obstacle in front of the vehicle and apply brake as needed or cut down the engine.
- Anti-skid braking system ( if achievable).
Android UI
- Display a button to apply the brake (Mechanical Braking System)
- Display a button to turn on E-Brake ( Electronic Braking)
- Display a button to turn on ABS (Anti-lock Braking System)
Meetings Times :
- Monday : 5:20 pm to 6:00 pm
- Friday : 5:20 pm to 6:00 pm
Previous Meetings :
08/26/16 : Discussion on what needs to be done for Braking System
09/17/16 : Discussion on Android development
09/21/16 : Discussion on the requirements and development
Meetings after class done every week to follow up on progress.
Braking System will be using a relay to simulate braking. The GoPi Go will use the ultra sound sensors to detect approaching object and cut power to the engines and run the wheel backwors if needed.
Monday, September 26, 2016
Climate Control System Team Concept Overview - Monday 9/26
The current document for our project’s progress will be elaborated below. Please keep in mind that these concepts are subject to change, and most likely will be as the bill of materials for the team has not be entirely solidified for backing our project’s implementation.
Project Roles:
- Project Manager/Team Leader, Climate Control Research and Material Concepts: Mohammed Ammouni
- Android Developer: Ahmad Alhaddad, Niravkumar Patel
- Android UI designer: Amanda McLean
- Linux operator: Niravkumar Patel
- Python Developers: Jacky Chen, Yusef Savage, Amanda Mclean, Mohammed Ammouni
Bill of Materials:
(This is currently what the Climate Control System materials are comprised of, REMINDER: construction of these materials is still a work in progress and is subject to change)
- Relay: Primary component to connect the following materials
- Fan: Adjusting coolness of temperature
- Resistor: Control the voltage produced to LEDs
- LEDs: Adjusting heat for temperature
- Case: A makeshift box that will contain the separation of temperature zones for temperature sensors (Does not require object ID)
Identifying System and User Needs:
- System UI
- Display both exterior and interior temperature
- Display both exterior and interior humidity
- Display buttons for raising or lowering temperature
- Display temperature in both fahrenheit and celsius
- Display if defrost is on or not (Auto enabled and disabled)
- Dual Interior Climate Function
- Interior temperature configurations will be allocated for Driver and Passenger
- Acquiring Outside Temperature
- In order to find the most optimal schedule the value of outside temperature has to be sent every time together with the inside temperature. This value could be obtained from an open weather service API like Weather Underground.
- Interior Temperature Limitation Features
- Maximum temperature allowed: 90 degrees Fahrenheit
- Minimum temperature allowed: 60 degrees Fahrenheit
Project communication and inquiries
If any team has questions for our system, please adhere to the team’s project roles and feel free to contact via email:
Team Leader: Mohammed Ammouni
|
mohammedammouni@gmail.com
|
Niravkumar Patel
|
niravhpatel1990@gmail.com
|
Yusef Savage
|
yusef.savage@gmail.com
|
Ahmad Alhaddad
|
procom22@gmail.com
|
Jacky Chen
|
cjackychen@gmail.com
|
Amanda McLean
|
Safety and Access Control System Team Meeting - Monday, 9/26
We reviewed and edited our document consisting of the class outline, roles, and requirements.
As of now, our requirements are: (these concepts can possibly chance as the project progresses)
As of now, our requirements are: (these concepts can possibly chance as the project progresses)
- Android App
- Must contain interface that allows doors to be locked or unlocked, and keypad for unlocking door.
- Must be able to communicate with car in order to perform all interface functionalities/controls.
- Emits noise based in what car functions are activated.
- NFC Unlock System
- Upon card key coming into proximity of NFC chip mounted on robot and finger is on key pad, doors will unlock.
- Automatic Door Lock System
- When the car reaches a certain speed detected by the accelerometer, the doors lock.
- Airbag System
- Upon detection of sudden stop (force applied opposite of current direction), airbags will be deployed emitting sound from speakers.
- Backup Detection Sound
- Upon reversing, car will make backup beeping noise.
We also discussed our current and additional tasks in Jira.
If you have any questions for our team, feel free to contact Phuong - plu396111@gmail.com or the other team members:
- Team Leader/Python Developer: Joey - jaeinatkor@gmail.com
- Android Developer: Matt - matthandwerk@gmail.com
- Python Developers:
- Shivang - ravipatel5152@gmail.com
- Ashish - ashishbaby46@gmail.com
Wednesday, September 21, 2016
IMPORTANT: Message Formatting Standard
Introduction
In order for our systems to effectively communicate with one another, members of the IST411 class met up and determined a standard for messages. If you have any issues with the proposed standard, or need to add more functionality to them, please discuss in the comments section. Requests will be followed up on via email and changes will be made to the standard.We designed this message format so that all systems could use it for their inter-system communication needs. We have also defined a message handling protocol in Python.
Message Format
Each message shall be sent as a JSON string. If originating in a Python environment, a dictionary object shall be created with the following UPPERCASE keys (followed by data type):CID: car identification code (str)
OID: origin identification code (str)
DID: destination identification code (str)
HC: system health code (Long)
TS: message time stamp (str)
TTL: message time to live duration in milliseconds (int)
PLD: message payload (str)
UID: message unique identifier (str)
CKS: md5 payload checksum (str)
This is a graphical representation of how each message should look:
This is an actual message sent in JSON format:
{"CID": "car10393", "HC": 3, "UID":"3h3453d3426da463d743", "DID": "brs", "CKS": "8fcffdcd1c1dbd62c199aa2a13c9043a", "TTL": 100, "OID": "ccs", "PLD": "payload: This message format defined by subteams", "TS": "1235542453.24325"}
Abbreviations and IDs
The car ID will be the same throughout the car. This is used to ensure that the systems in this car do not attempt to communicate with systems from other nearby cars. The OID and DID correspond with the subsystems that are communicating.Each subsystem has a 3 letter code (note, it should always be LOWERCASE):
- brs = braking system
- clc = climate control system
- ems = energy management system
- ccs = command and control system
- mls = monitoring and logging system
- cns = connectivity and notification system
- dts = drivetrain system
- lis = lighting system
- sac = safety and access control system
Health Code Formatting
The health code will be a number scale (to be determined) signifying the status of a system or the urgency of a message. This is needed for monitoring purposes - more info to come later.
Payload Formatting
The payload formatting will be up to the individual subteams to decide. It would be nice to have something standard like a code and then a parameter (ie: br70 = braking power 70%) but that's up to you guys at this point.
Time Stamp Formatting
To be derived using the time taken from system clock and signifies the time the message was sent. This uses the time module in python and called automatically when a new message is instantiated. (The call is time.time() and it returns the seconds passed since the Epoch in local time) There is also a method in the Message class that converts the timestamp and returns a human readable time format. In order for this and the time to live functions to work, all system times must be synced at the beginning of vehicle operation. At the moment, we are assuming that all RPis will be synced via internet when initially deployed and then use a real time clock module to keep accurate time. A method may still be developed to sync system times across subsystems, but that is still being decided on.
Sample Code
When used in a Python environment, each message should be stored in a Message object. It can be found in the github MonitoringAndLoggingSystem directory under the name "Message.py"If you would like to test the class and its associated methods, we have put together a python script called TestMessage.py in the github MonitoringAndLoggingSystem directory. I have simulated the steps involved in sending and receiving a message.
When sending, the protocol is as follows:
- Create Message object, populate with data you are sending (don't worry about checksum, it is autocalculated at instantiation)
- Convert message to JSON string with message.ConvertToJSON() method
- Send resulting string
When receiving, the protocol is as follows:
- Store message as a string
- Convert message to dictionary object
- Create Message object with data from dictionary object (in this case, checksum needs to be included in parameters)
- You have a message object! Profit!
FYI, the code for the receiving algorithm is located in the ConvertFromJSON() method in the TestMessage.py script. It's a simple copy and paste job from there. IST440 members - Joe should be making it available to you in your git repo soon.
Thursday, September 15, 2016
Subscribe to:
Comments (Atom)