-
Notifications
You must be signed in to change notification settings - Fork 0
Data Logger
This project is currently fairly stable but it's functionality needs to be implemented throughout the code.
See below for details about why we need this and other archived writing
- Implement logging of events; it works!
- Log error messages
- Add support for logging Error messages to the data logger where the messages go to a separate file from the main datum
- Log all metadata from any vision software we write.
- Will be logged to a separate file; UDP broadcast as well
There are 3 parts of the Data Logger:
- Collection
Data Fields that are to be logged are stored in DataField objects which are part of the DataCollator class. Subsystems update these fields periodically.
- Sending
The DataLoggerPublisherThread sends Strings over the network via UDP broadcasts. The first character of the String denotes what type of data is being sent(h for header, d for data, e for end logging). UDP does not guarantee that every packet will arrive in the same order, or arrive at all. A int_32 sequence number is then included to sort the packets later and then the data is sent. Every 100 data messages, a header message is sent. This allows the recorder to either create a new file or to insert a header into the current file if the previous header message was missed.
- Recording
The DataLoggerRecorder writes incoming messages to a file created at when the program starts titled with the time and date. When an end message is sent, the recorder closes the file writer and gracefully shutdown. Header messages that are sent when there is already a header in the current file are ignored.
Software currently located in initialROBOT on the DataLoggerDavid branch. Will be soon tested on the robot and moved to CompetitionReady and then following onto RustyComms.
Logging data is probably the single most important software project for our team. This project will enable us to better analyze our robot and improve all aspects of it: mechanically, electrically, and with software.
As mentioned before, at our first competition we were attempting to draw too much power from our robot and caused brownouts. When the roboRIO shuts off due to a brownout, it takes at least 30 seconds for it to power back on. To this date we do not know what causes these brownouts. To help us pinpoint exactly what is causing our brownouts it would be helpful if we could record data points such as:
- Battery voltage
- Current draw of motors,
- Rate of turn (Gyroscope)
- Acceleration
This information is invaluable to the electrical, mechanical, and software elements of the robot. Knowing why things are occurring will enable us to comprehensively assess issues and address as appropriate.
For example, let us take a closer look at our brownouts. To solve our problem we decided to take an electrical approach; we disconnected 1/2 of our motors -- reducing our torque by a factor of two. This made it harder to cross the moat, and harder to cross the rough terrain.
Our solution was not very eloquent. There are many other ways that we can solve this problem but they all require more data. They all require knowing exactly what is causing the surge in power draw. If we could pinpoint the cause we could possibly prevent brownouts by:
- Changing our driving style
- Preventing the robot from drawing too much power in risky situations through software limits
- Mechanically changing the design of the robot
Once we have our data logger working, and some data collected, I plan for us to re-enable the other 2 motors and try to brownout the robot so that we can determine what is causing it.
The value of data logging goes well beyond brownouts. Data logging will help us better analyze our robot’s design, improving efficiency, and enabling us to more gracefully solve any problems that come up. Data logging all error messages, and the transitions of state in our robot can help us to better analyze and improve our software. If we had had data from our robot up until the software tried to initialize the cameras, then we would have known during the build season that we needed to switch to IP cameras. Our cameras were the major reason why we performed much worse at our second competition at UMASS Dartmouth.
Besides being a very important project, this project also has aspects which everyone can contribute to.
Our robot’s data logger will have two parts; a part on the roboRIO, and an external part.
The following is the beginnings of a list of fields of data that we will want to track. We will very likely be adding to this in the future.
- Software output power to each motor
- Rate of turning (Gyroscope)
- Acceleration (Accelerometer)
- Battery voltage
- Total current draw on the PDP
- Current draw on each motor (PDP Object will have this data.)
- Switches between each stage of the competition
- Please email me any other ideas you have -- dmatthewsshs@gmail.com
The roboRIO is not a good place to save our data. In the event of a power failure it may not write the data to disk and thus we may be unable to capture crucial data to assess a problem. The data is only useful to us if we can access it easily. Broadcasting the data will provide us flexibility to store long histories of data, record it to a computer and/or view it live when addressing a problem.
The roboRIO software will have two parts; collecting the data in static fields of a public class (This would be similar to the RobotMap.java except with non-Final variables), and broadcasting the data as a string via UDP to our local network (To repeatedly send data, we could create a subsystem and set the default command to send the data. This would provide flexibility to also receive data from a raspberry Pi via UDP if desired.).
The raspberry pi is a good place to store our data. They are a fairly cheap credit card sized fully functional computer that is easy to learn linux on. All of their information is stored on a micro SD card which means that they are very easy to revert back to previous copies of the code through git. They are also powered via 5v, which will not cut off even if the RoboRIO has a brownout.
A few teams:
- Publishing data fields to static fields in a public class.
- UDP Broadcasting strings to a local network: Possibly a good starting place
- Receiving a UDP packet on the raspberryPi and writing it to file as a string.
- Saving files in a directory in a way that makes logical sense.
- Should create a new file when robot powers on, and at other key points so each file does not contain too much data.