cmu-robotics-club / robobuggy Goto Github PK

Implement Encoder Data logging from serial to text file

Should at least include encoder tick value and time of reading

How will we store and retrieve data from the map

The map should be readable from matlab, java, and possibly python
The map should be writable form matlab, java, and possibly python

Work on getting the IO interface done.

What computer should we use until we get the real one?

Link the IO and protocol layers

Implement GPS Data logging from serial to text file

Should at least include lat,lon,altitude and time of reading

Start sending the encoder messages to the surface

Good Debugging Tool.
Create a playback program that will allow us to see (preferably graphically) what is/was happening on the arduino. Could be as simple as storing the messages into a text file and seeing what happened around the time of the screw up and seeing what messages were being sent then.

Try to setup a pipeline to make this process easier in the future

Build a tool which can display where the buggy was when events occurred based on data log. Also allow for us to see the vents that happened in a specific time frame. Should also be able to read map files for seeing were all deteictions should be happending. This tool will be crucial for debugging the system and verifying that we have enough events to completely cover the course. depends on #44 #20

Build GPS/Camera other buggy data collection rig that can fit on top of another buggy be self powered and include a raspberry pi.

Create the protocol to receive messages in low-level
ie. surface -> arduino via Serial

I need a small program to test the receive module on the protocol on the low-level end. The program needs to send a packet to the arduino, which is outlined in the wiki under Embedded and packet structure.

Can you please make this working soon so I can confirm functionality and close an issue and move on to the next. Thanks.

If it is still unclear what to send to the arduino, just send 0xFC01DEAD. If you can send this packet over and over. Or just one time. Or something, that would be awesome.

After the packet is received, parse the packet into message and id.

Create the local function in lib_protocol.c
Prototype is already done in lib_protocol.h

when the message contains 0xFC, we need to handle that somehow

Implement Camera Data logging from video stream to .jpg

Should at least include camera frame and time of reading

Should we try to localize based on hay bails from vision?

Create a library that reads the encoder ticks

Create the timing loop for the nano so that the loop only sends messages at a certain time interval

We need a gui to control the buggy it should be written in java and have the following functionality

Toggle data logging {ON,RESET,OFF}
Button localization {RESET}
Toggle use GPS data {ON, RESET,OFF}
Toggle use Odometry {ON, RESET, OFF}
Toggle use vision {ON, RESET, OFF}
Toggle use IMU {ON, RESET, OFF}
Toggle Time {RESET}

Toggle Driver Profile {Alice}

NOTE: Alice will be the name of are first driver profile she will be a simple way point following driver that is not very aggressive.

ShowMap of coarse with:
our believed location super imposed,
our past path super imposed (button to turn on and off)
our planned path super imposed (button to turn on and off)
GPS reading marks (button to turn on and off)
Encoder reading marks (button to turn on and off)
IMU reading marks (button to turn on and off)
feature detection's (button to turn on and off)

Video Feed (raw)
Video Feed with detection's
easy way to toggle visual detectors on,off,reset

(NOTE: This would make for a very good 112 project)

Already created one for the arduino nano, port it over to the mega. Should be simple

Connecting the encoders to arduino nano

Ticks passed since reset
Speed (over a specific time -compiled in)
Ticks?...

Depends on data structure form #42

Generate a gps accuracy map of the entire buggy course

Write v1 of the path planner, should take in a series of way points and the current location of the buggy. Depending on what the next reachable point is the desired front angle of the buggy should be set.

Create unit tests and other test cases for the low-level protocol layer.

Set up a tool that allows for quick gps map generation.

When the reading is taken the user should select the gps coordinates of the receiver for ground truth, A picture should be taken for later verification.

currently we built a surveying station that records the gps signal and takes a picture.

It would also be nice if the camera were to display a live stream until the picture is taken.

Fixed this by downloading driver from code laboratories http://codelaboratories.com/products/eye/driver/
Note that the $2.99 driver is needed for the sdk to work. Not sure yet if sdk was actually needed.

Tested and works on surface pro 2

Implement IMU Data logging from serial to text file

Should at least include yaw value and time of reading

consider adding, roll,pitch,linear X, linear Y, linear Z, magnetic north

Create a makefile to link the libraries in the parent directory to the 2 arduino sketches. Arduino doesn't allow you to create a relative link to your libraries in your parent folder. Create a makefile that allows you to connect the libraries in a parent folder so that the shared libraries may be updated together in one go.

The weakest point of failure in Buggy today are humans. By removing them, we optimize the sport for human safety, speed, and profit.

Everything we do in pursuit of closing this issue.

Created the send protocol

Create a system that when given an arbitrary java class converts the data in the class to an entry in the systems database for latter lookup

Should be forward facing and (mounted low to avoid shacking?)

I would like it to be forward facing to maximize ability to detect useful features. I think it would do well where the GPS receiver was mounted. exact Height off the ground is not important, it would also be cool if we mount it to the front of the buggy in front of the wheel.

If we can add some damping that would be nice, but not required.

Needs to be steady state rigidly mounted, if bumped it should return to the same location after minimal osculations.

Depends on data structure from #42

Find and decide a method of handling multiple packets.
Determine if loop send/receive check.
Code it up