Hired help with sketch! I'm in over my head

Status
Not open for further replies.
Hi All,
I’ve got a data collection project I’m working on and am currently struggling to write a sketch that can do what I need it to do. I’m looking to hire someone to write a sketch for me and, if needed make some hardware/software recommendations if what I’m trying to achieve is not feasible with my current setup.

Objective: I’m building a telemetry device with 5 motion inputs, speed, GPS, and altitude. I’d like to be able to record for up to an hour but realistically won’t record for more than 5-10 minutes at a time. I don’t need the sketch to do anything other than capture the data right now. I will reshape the data, and perform calculations and analysis on the backend.

Deliverable: First and foremost I’m looking for a sketch that works. I’m not going to be too prescriptive in terms of how you get there. If it will work better with MicroPython or log it in binary that’s fine (if binary I’d also need a way to convert it to a CSV or other delimited file). The only things that I do want are thoroughly commented code (I’m also going to use this to speed up my learning) and easy to change variables for things like sampling rates for the MPUs.

I’ve attached a fritzing of the setup as well.

If you are interested message me and we can discuss the details that aren’t here and you’re expected time and price.

Hardware:
• 1 X Teensy 4.1 – 600 MHz CPU more onboard storage and SDIO write to SD
• 4 X Adafruit MPU-6050 – Sampling rate between 200-800Hz each (final freq. TBD based on post hoc analysis, but expect ~400Hz)
• 1 X Adafruit LSM6DS33 + LIS3MDL – Sampling rate between 200-800Hz (most likely closer to 200Hz)
• 1 X Adafruit Mini GPS PA1010D – Sampling rate between 5-10Hz
• 2 X Adafruit LTC4311 I2C Extender / Active Terminator – 2 of the MPU-6050 will have about 1 meter of wire between the sensor and the MCU
• 1 X Adafruit BMP388 - Precision Barometric Pressure and Altimeter – Lower priority
• 2 X KY-003 Hall Sensor – Lower Priority
• 1 X Momentary Switch – Long press to start and stop recording, short press to log point of interest
• 1 X LED – On while recording, blink when POI is logged
• 1 X 36 GB class 10 micro SD card

Fritzing:
telemetry_fritz_V2.jpg
 
So this is more complicated than I thought. What if I scaled it back to two of the MPU-6050s, the GPS and the recording/flagging functionality with the momentary switch and led?
 
Five or ten years ago, I would have bid on this project at a price that would send my wife and me to Europe for a month of travel in Switzerland and along the Rhine river in Germany. However, I'm retired now and European travel is on hold while we figure out the pandemic situation. Instead, I'll give you a few ideas and questions.

You specify 4 MPU-6050 triple-axis gyros and accelerometers. Do you really need 12 axes of gyro and accelerometer data? You need to add a bit more information here. Are the four MPU-6050s on the limbs of a quadruped? Is that overkill as, unless they can wander off on their own, they will still be connected to the T4.1 and share acceleration and gyro data to some extent. They would also share some acceleration data with the Adafruit LSM6DS33 + LIS3MDL.

1. I would suggest logging binary data as it looks like you have perhaps 30 to 40 items to log at 800 KHz max, which could mean 20 KBytes/second or more. My approach in situations like this is to log everything in binary, upload via Serial, or plugging in the SD card and transfer to a PC for analysis. Then you can use Matlab or your favorite analysis program to examine and plot your data.
2. What powers this device and what is your power budget?
3. Does it start automatically or wait for user input?
4. If the data has to be time-stamped, do you have a backup battery for the T4.1 real-time-clock? Or do you have to wait for GPS to get a signal and provide a time reference?

Getting a talented and experienced programmer to work on a project like this can mean a lot of preliminary work by you. A lot of the projects I've worked on over the last few decades started with a request for quotation accompanied by a 10 to 20-page specifications document. Remember the Rule of Many Ps: "Proper Planning Prevents Perusal of Pathetic Proposals."
 
Thanks for the feedback. As I said in my follow-up post I realized that I was asking a lot and scaled back the request substantially. But I've responded to your questions below.

You specify 4 MPU-6050 triple-axis gyros and accelerometers. Do you really need 12 axes of gyro and accelerometer data? You need to add a bit more information here. Are the four MPU-6050s on the limbs of a quadruped? Is that overkill as, unless they can wander off on their own, they will still be connected to the T4.1 and share acceleration and gyro data to some extent. They would also share some acceleration data with the Adafruit LSM6DS33 + LIS3MDL.

I may not need the gyro data from all of the 6050s but definitely will need the acceleration data. Yes, they will be highly correlated but the differences are exactly what I will be studying in this project. Regarding the LSM I may only end up using the magnetometer data but that is an empirical decision that is hard to make without experimentation and analysis. I'm an experienced data scientist and have learned to start out with more data than I need. Too much data is an easy problem to deal with but I realize that in this environment the cost of collection changes that calculation. Part of the reason I posted this request was to get some feedback on what was feasible.

1. I would suggest logging binary data as it looks like you have perhaps 30 to 40 items to log at 800 KHz max, which could mean 20 KBytes/second or more. My approach in situations like this is to log everything in binary, upload via Serial, or plugging in the SD card and transfer to a PC for analysis. Then you can use Matlab or your favorite analysis program to examine and plot your data.

I figured binary was the way to go. BTW I said logging at 800 Hz max, not KHz. Matlab? no way, R and Python, both more capable and open source. :D


2. What powers this device and what is your power budget?
Lithium-ion batteries. The power drain is one of the items I will be testing and experimenting with so the size of the battery is TBD.

3. Does it start automatically or wait for user input?
The momentary switch described in the original post would be used to start/stop recording


4. If the data has to be time-stamped, do you have a backup battery for the T4.1 real-time-clock? Or do you have to wait for GPS to get a signal and provide a time reference?
Yes backup battery for the T4.1 and GPS sensor, but at this point in the experiment, the timestamp isn't critical.

Getting a talented and experienced programmer to work on a project like this can mean a lot of preliminary work by you. A lot of the projects I've worked on over the last few decades started with a request for quotation accompanied by a 10 to 20-page specifications document. Remember the Rule of Many Ps: "Proper Planning Prevents Perusal of Pathetic Proposals."
I get that and have responded to hundreds of RFPs over the years. In most cases the final deliverable is well understood, in this case, it is an experiment with a very nebulous outcome. I am very serious when I say that all I want is the raw data within the parameters set and otherwise don't care how it happens. This is far from a long-term or robust solution, but very quick and dirty.
 
Status
Not open for further replies.
Back
Top