on 08-15-2018 12:35 PM
here is one from me, using time, location and altitude from a GoPro video; speed, distance, grade and course are derived from that data.
Tire pressure, outside temperature and heart rate are from other Garmin sensors...
08-15-2018 01:15 PM - edited 08-15-2018 01:16 PM
Wow, that's mind blowing! Both the car (is that legal?) and the way you presented the data. Syncing it with Google Earth is brilliant.
Can we know the software(s) you used in the process?
Thanks for sharing
on 08-15-2018 05:56 PM
yup, the car is legal. It’s actually a motorcycle, since it has only 3 wheels…
On the hardware side I have used a GoPro 5 that is mounted to the roll bar behind the driver seat. The camera is wrapped in a ”GoPro WindSlayer” to reduce the wind noise. I have written some code mostly based on https://github.com/gopro/gpmf-parser/blob/master/README.md to extract the GPS info and create a GPX file that can later be used in Garmin Virb Edit.
I’m wearing a Fenix watch to track my heart rate and the outside temperature. It syncs the track to Garmin’s server and from there I can download a GPX file with the data. Sampling rate is pretty non-constant - mostly between 0.1 and 1 Hz.
The wheels have Garmin TPMS valve caps that measure tire pressure and air temperature in the tire every 30 seconds. Data gets transferred to a Garmin navigation system in the bike via ANT protocol, and stored there in a SQlite database. I use a SQlite browser to read the file and save the contents into CSV files (https://sqlitebrowser.org).
Then I have written some code to read the three files (GoPro GPX, Watch GPX and TPMS CSV) and merge them together into GPX files based on their time tags. Since Garmin Virb Edit supports only one pressure sensor in their GPX format, I’m creating three files here - one for each tire pressure sensor.
After that I load one of the GPX files into Google Earth Pro and create a “tour” from it. The tour can then be recorded as a movie.
Next step is to load the video files (4GB each) from the GoPro into Final Cut Pro X, merge them together and save them as one long video file. Then load the video file into Garmin Virb Edit, add one of the GPX files, sync between GPX and video and add the overlays for distance, speed, heart rate, grade, course, GPS coordinates, outside temperature, map and tire pressure.
The merging of the 4GB chunks could be done directly in Virb too to save time - but I found it has problems then syncing up all chunks correctly with the GPX file. So using FCP for this step avoids that.
The bike “gauge” is created by using a drone to take an overhead picture of the bike and removing the background in Photoshop…
Once the video is created, I load the next GPX file to get the tire pressure overlay for the next wheel. Here I store as video (discarded later) and as a set of PNG files, that just contain the overlays. Then repeat this for the last GPX file to get the third wheel.
At this point I have two sets of PNG files that I need to merge together into a movie. That was a bit challenging: FCP can do that in principle, but its not good in handling a large number of clips - each set contains about 47000 PNG files for the length of the original video. I tried using ffmpeg but that doesn’t seam to support transparency (alpha channels) in PNG files or video files. Looked at OpenCV which seems to handle transparency, but can’t create video files larger than 2GB. Finally went with Quicktime Player 7 Pro that can do that pretty efficiently. However, it can’t handle the large number of files so I had to split into chunks of 10000 pictures and create 5 videos for each set.
The final step then is to load all the video files into FCP, use the first Virb video as background, overlay and shrink the Google Earth video, overlay the 10 videos for the additional two TPMS sensors and crop those down to the area with the pressure numbers. I added the GoPro logo in this step too. Then sync up the TPMS videos with the background layer - based on the offset found above in Virb Edit between video and GPX. Sync the Google Earth video with the background layer visually - based on markings on the street.
And then save the final video…
It would be better to create another set of PNG files in Virb for the first sensor, instead of creating a video file with the overlays.
That would allow you to use the original GoPro 4GB video chunks as background layer in FCP and would maintain a better video quality (the procedure above encodes the video three times - to merge the chunks, to add the overlays and for the final video).
But the original video is 4K/30fps, so quality is still good enough in the end for youtube or facebook.
I haven’t used all the sensor data yet. I could show the air temperature in the tires, but that’s not really useful - would need the surface temperature. GoPro camera temperature is also not that interesting.
I have the accelerometer and gyroscope data from the GoPro that I could use to show acceleration and braking, but the data is not really good. I think the accelerometer might be recording vibrations from the engine more than the driving motion of the bike - need to test that. I didn’t stabilize the video and that doesn’t seem to shake too much.
And the gyroscope data has a lot of drift, when you try to calculate camera angles - could correct the data for that, but not sure if the result would be interesting. In principle it should be possible to calculate gear shift points from this data, so I could keep track of which gear the bike is in…
The bike has an AIM dashboard, but this model doesn’t have data logger capabilities - otherwise I could get gear, rpm, water temperature, oil pressure and battery voltage from there…
Also still looking for improvements in the workflow above. Would be nice if Virb could just create a video per gauge, support multiple sensors of one type, support CSV instead of GPX, and had some bug fixes - e.g. the grade calculation in this video is not correct.
Here is another video that adds a 360 camera to the mix: https://www.youtube.com/watch?v=lL6eoulviv0&t=673s
and one with a different camera perspective: https://www.youtube.com/watch?v=kSyar2eGbkc
on 08-16-2018 09:02 AM
Regarding the gyro, yes, not sure what relevant information can be derived from that considering the drift. Or the fact that when you turn around one axis the others produce unexpected behaviours (maybe I'm not interpreting it right).
I did find acceleration to be relevant after smoothing vibrationsout, and that was on some pretty rough roller coasters.
10-18-2018 06:15 AM - edited 10-18-2018 06:17 AM
I have been trying to use the telemetry data with Virb only because these gauges design seems to fit better, non intrusive, more contemporary, IMHO.
But nothing seems to work.
1. Recording the GPS data simultaneously with my cell phone, using Geo Tracker, a discontinued app only for Android devices. Save the tracks as GPX and applying them with Virb > inconsistencies
2. Extracting the data with the @kajuna flow (https://community.gopro.com/t5/GoPro-Metadata-Visualization/Extracting-the-metadata-in-a-useful-form...) and applying them with Virb> inconsistencies
3. Using GoPro Quik Desktop to aplply the gauges > works beautifully
Apparently, Quik has inner resources to precisely calculate velocity, distance, etc, that we cannot reproduce in others places.
Video examples below of my trip in the Paray colonial city (Rio de Janeiro). You can't drive into the old downtown streets.
on 10-18-2018 09:16 AM
@edsonm27 What were the inconsistencies with my workflow? I can't spend much time on it at the moment, but would like to add any issues to my to-do list :) We assume that Quik deduces altitude using additional data, but were there other problems? Were you using the latest version of the tools? Thanks
on 10-18-2018 11:06 AM
There are no inconsistencies with your workflow. I can extract successfully the GPX, KML, JSON and CSV files with the last version of your tools.
What I call inconsistencies is that the gauges barely move themselves from 0 (zero) when loading the GPX log in VIRB.
If I load the same GPX data in DashWare, for example, I get the same accurate results as we see in GoPro Quik.
So, there is nothing wrong with the files generated by your GPMD2CSV.