[Layout] - Dashware-like MotoWidget

[JimmyS83]

Hello all,

I am planning to recreate dashware layout like this

I dont need the compass arrow necessarily, maybe I will move digit speed inside circle, maybe not. PLYN and BRZDA bars meaning Acceleration, basically they are "Throttle" and "Brake", for which I could use zone-bar without issue I guess.

But the nice speedometer is the hard nut here. I like the one from dashware, because numbers are not overlapped by needle, effect of blue edge is nice, and modest combination small/wider ticks and numbers evokes real speedometer.

I think I must somehow combine

• cairo-gauge-round-annotated (and make needle totally transparent, as well the background of circle, if thats even possible(?))

• or asi, which seems to have a bit nicer numbers with better looking space from ticks

• and to the background of this widget put cairo-gauge-marker - again, with totally transparent ticks, if thats even possible (?). The background is important, because ticks from other widget needs to be displayed over it.

Is this good thinking? Is thats possible? Not sure about transparency of needed things from widget which I need to hide, and certainly I didnt know, how find/choose order of layers (I mean, whats in background and what is in foreground)

[time4tea]

I don't have an immediate answer for you.. but I can let you know about "gopro-layout.py" - The job of this program is to help you experiment with layouts. You just give the program the gopro file, and your layout file. Then each time the layout file changes, it will just render one frame. You can open this in a file viewer. Most of them will reload the image file when it changes, and so you can get "live" changes...

[JimmyS83]

I don't have an immediate answer for you.. but I can let you know about "gopro-layout.py" - The job of this program is to help you experiment with layouts. You just give the program the gopro file, and your layout file. Then each time the layout file changes, it will just render one frame. You can open this in a file viewer. Most of them will reload the image file when it changes, and so you can get "live" changes...

Thanks, thats very usefull!! I am use it and try to create auto/moto Dashboard..

As I thought, acceleration wasnt an issue (didnt test brake "negative" bar 0 ... -1 though yet), and the layering is done simply by order of widget in xml, no issues there.

But unfortunatelly, I dont know, how to make prettier Speedometer (like that one from Dashware).

• I cant find any option to hide/make transparent parts of asi widget (to get rid of needle, background, ranges etc.)
• I cant find any option to make numbers on cairo-gauge-round-annotated wider and more spaced from ticks
• I cant find any option to change size/diameter of cairo-gauge-marker (to place it carefully to the outter edge of round gauges, to not interfere with informations.

P.S.: Some widget parameters have option to change count (like ticks), but it cannot be set to 0 (like disable them - that leads to dividing by zero). So, you must use vne parameter for asi widget etc. If would 0 (or false, etc.) disabled that part of widget, that would leads to more customisation options.

Similiarly, in zone-bar, when unit is G, there is no point to restrict values to Int. Much more usual values would be there 0.1-0.5 for better graphical scale of zone. Workaround would be use another units, but still, when G's are available, it would make a sense to have option to use float min/max values

[JimmyS83]

Well, jumped from drawing board to the real data, and additional issues emerged :(

Its mystery for me, why I believe correct code
<component x="55" type="metric" metric="accl.y" />
shows no data, only -

From the same gpx (I even test generate overlay just from gpx, to rule out any other error aside; but the result was the same as with GoPro mp4), Dashware read correct acceleration/decceleration via the exact same metrics, at least I think its the same.


the CSV is just because Dashware transfer gpx to csv, but the contents is the same - list of measured points

DashWare GPX CSV File
Time,Latitude,Longitude,Elevation,AirTemp,HeartRate,Cadence,Power,Roll,Pitch

[time4tea]

Hiya, because of some performance issues (I am working on this) ACCL is not parsed by default.

Use --load ACCL

https://github.com/time4tea/gopro-dashboard-overlay/blob/main/docs/bin/README.md#loading-additional-gopro-data

[JimmyS83]

Hiya, because of some performance issues (I am working on this) ACCL is not parsed by default.

Use --load ACCL

https://github.com/time4tea/gopro-dashboard-overlay/blob/main/docs/bin/README.md#loading-additional-gopro-data

Thanks, I didnt notice that, my bad..

But from the first test, it seems that it acts kinda funny. ACCL.Y shows almost entire video -9,-10 values, even when a car moving steadily 50 km/h. When I load gpx to Dashware, they correctly showing +/- values, even when speed increasing/decreasing by few km/h..

Not sure, if its, because my test sample contains some NO LOCK frames (on the other hand, its great for testing, because NO LOCK could happen anytime)..

At top of that, brakes zone-bar doesnt show anything, nevermind if I setup min="-30" max="0" or min="-30" max="0"

[time4tea]

I will check. In general axes of rotation and acceleration are as in https://github.com/time4tea/gopro-dashboard-overlay/tree/main/docs/xml/examples/04-metrics#axes-of-acceleration--rotation One of the acceleration axes will be -9.8, as this is gravity... but like I say, I'll check. If you are OK with sending me your file, to gopro-overlay@time4tea.net I'm very happy to take a look. But also, please don't feel obliged. Cheers

…

On 30 Jan 2024, 19:32, at 19:32, JimmyS83 ***@***.***> wrote: > Hiya, because of some performance issues (I am working on this) ACCL is not parsed by default. > > Use --load ACCL > > https://github.com/time4tea/gopro-dashboard-overlay/blob/main/docs/bin/README.md#loading-additional-gopro-data Thanks, I didnt notice that, my bad.. But from the first test, it seems that it acts kinda funny. ACCL.Y shows almost entire video -9,-10 values, even when a car moving steadily 50 km/h. When I load gpx to Dashware, they correctly showing +/- values, even when speed increasing/decreasing by few km/h.. Not sure, if its, because my test sample contains some NO LOCK frames (on the other hand, its great for testing, because NO LOCK could happen anytime).. At top of that, brakes _zone-bar_ doesnt show anything, nevermind if I setup `min="-30" max="0"` or `min="-30" max="0"` -- Reply to this email directly or view it on GitHub: #176 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[JimmyS83]

I just send you an email :)

[JimmyS83]

I will check. In general axes of rotation and acceleration are as in https://github.com/time4tea/gopro-dashboard-overlay/tree/main/docs/xml/examples/04-metrics#axes-of-acceleration--rotation One of the acceleration axes will be -9.8, as this is gravity... but like I say, I'll check. If you are OK with sending me your file, to @.*** I'm very happy to take a look. But also, please don't feel obliged. Cheers
…
On 30 Jan 2024, 19:32, at 19:32, JimmyS83 @.> wrote: > Hiya, because of some performance issues (I am working on this) ACCL is not parsed by default. > > Use --load ACCL > > https://github.com/time4tea/gopro-dashboard-overlay/blob/main/docs/bin/README.md#loading-additional-gopro-data Thanks, I didnt notice that, my bad.. But from the first test, it seems that it acts kinda funny. ACCL.Y shows almost entire video -9,-10 values, even when a car moving steadily 50 km/h. When I load gpx to Dashware, they correctly showing +/- values, even when speed increasing/decreasing by few km/h.. Not sure, if its, because my test sample contains some NO LOCK frames (on the other hand, its great for testing, because NO LOCK could happen anytime).. At top of that, brakes zone-bar doesnt show anything, nevermind if I setup min="-30" max="0" or min="-30" max="0" -- Reply to this email directly or view it on GitHub: #176 (comment) You are receiving this because you commented. Message ID: @.>

Hmm, that could be it. It is true, that in test video camera laying backwards. It didnt comes to my mind, especially, when with Dashware ** shows good numbers in terms of acc/dec**. I checked other axis, and it show more modest -1 .. +1 ranges.. I must record new video. Is it possible, that dashware calculate acceleration/decceleration differently? Otherwise I dont know, why it has so much different results with the same gpx... But within Dashware its labeled like exactly same.

I know that in Dashware there are more gauges, which are related to G's. One is showing radar-like circle, where showing I believe 2 axis, x+y. Another one is Throttle/Brake, where is no direction, just acceleration or deceleration in bar(s). Dunno, if there is some clever algorithm behind it, but it really show that, nevermind if you are in straight line, or driving corner..

I am very appretiating your support! This specific video contains some bit of sensitive data. I will try to record some more videos on next days, shorter also, so if something will be strange I would be able to share them with you privatelly.

Anyway, any tip, how to make zone-bar showing negative values from G's?

[JimmyS83]

I use asi as template to create msi, and I think I am close enough with speedometer.

Only major thing missing is correctly bars for graphic representation acceleration and deceleration.

[time4tea]

This is great. Using accl it should be possible to understand whether accelerating or braking. In theory, it should be possible to fuse the accl information with GRAV to understand which direction the acceleration is happening in, by doing some vector maths, although I'm not 100% sure exactly what maths!

[JimmyS83]

Thanks. Its a bit rough still, but hopefully it will be a bit polished later on.. :)

Not sure, if I could pull this (Throttle/Brake) out by myself. Btw., did you received my emails? I tried to gather some info from Dashware, but I didnt find any hints, regarding math behind Throttle/Brage gauge though. For what I can see, it really didnt get away much info except "using Gs Y", which I am almost sure isnt just accel y axis.

[time4tea]

Yes, got email. Thanks!

[time4tea]

Hiya - @JimmyS83 - thanks for all your emails! I think it might be best to add them here in preference to email though, unless the content is private (like gpx/mp4 files for instance) - as its just much easier to manage the communications here.

[JimmyS83]

Sure. Maybe not gpx, but I guess streamable videos could be OK. I will try summarize all ideas within emails to one post here :)

[JimmyS83]

I found GoPro x/y. accl not much realiable. And knowing, that Dashware renders same gpx (its not even needed to use GoPro video, but just relativelly small, bare gpx file) with nice Throttle / Brake bars, I start thinking, whats different here.

Difference between using gopro-dashboard and Dashware, regarding Throttle/Brake could be seen here:
https://streamable.com/89x1sd - https://streamable.com/2p53bj

After some digging I found, that although using ACCL would be possible for Dashware also (I assume, as its developed by Gopro), even when using just bare gpx as input, not Gopro video, it calculates and interpolates Acceleration basically from GPS lat/lon + time, and it works very nicely:

It calculates own helping measures from simple gpx

into values, which is used by gauges like:

So I wondering, interested just about Throttle / Brake gauge, where it comes. It turns out, that gauge use "GPS AccelGs" variable. The chain, how its gathered is:

GPS-Based Acceleration Calculator -> RawGPS --> Linear Interpolator -> InterpGPS --> Averaging Calculator-> GPS AccelGs

where

1] GPS-Based Acceleration Calculator: Determine acc. and lateral G-Forces based on GPS position movement over time.

2] Linear Interpolator, used to fill in empty values with interpolated values (interpolated between the last non-empty value and next non-empty values)

3] Averaging Calculator, used to smooth data sets by averaging using previous and/or future values.

So I am thinking how to do the same within gopro-dashboard, which has own meters available. It already has cspeed as fallback where speed is not available, so it could have also "caccel", also calculated from GPS and time I thought.

I could find some formulas to do 1]. But I am guess, thats really dont needed, because gopro-overlay already counts speed, right? So, if we are interested just acc/dec, then we can use simple formula

a = Sd / Td

where Sd is speed difference between two measure points, and Td is delta time between them. (https://www.omnicalculator.com/physics/acceleration)

This should calculate raw data, which would be optimally went through 2] 3] to better graphical interpretation (I found 2] very usefull, for brief quick small GPS NO LOCKS + using charts, 3] is already implemented in some way I guess).

I tried to make some very rough POC (I am not familiar with gopro-dasboard much, regarding gathering and interpolating data), using just

 if a.speed and b.speed and time:
            accel = (b.speed - a.speed) / time
        else:
            accel = units.Quantity(0, units.mps)

within calculate_speeds() @timeseries_process.py (not sure, where fallback from speed to cspeed happens, and also I am not sure if points are from gpx or GoPro data, but just for test..).

Seems that (calculated) acceleration copies speed much better than accl.x/y (and it doesnt needs ACCL data as bonus), but timing seems to be a little off, as accel would be ahead of time.

https://streamable.com/3qbcxu

Any help appreciated :)

[JimmyS83]

Ok, I think I got it. process_deltas updates FIRST point, not the second. When I write separate method process_accel, which updates second one, and call separated calculate_accel(), which calculates just accel parameter, instead calculate_speeds(), results starts feeling like something what I want: https://streamable.com/thc8sc

Its not Interpolated, smoothed.. but as POC works OK for me and proove, that simple using speed(GPS location) and time from gpx is enough to offer nice (calculated) accel metric.

@time4tea - are you interested in incorporating these into code? I am sure there is need some polishing, and code could be more elegant, but I am happy with sharing my code with you (accel, msi's, later on also layout(s)) so others could use these also. If yes, there is a question: As propably quite a lot of polishing would be needed for you to accept code, is it better for you to just have code, and do own MR, or should I create my own..

[time4tea]

Thanks for this. Video looks great. - if you are ok.. then please do make a PR, but I will probably just take the commits from it rather than merge it as a PR, or maybe take the concepts and make something that works the same way. The PR is useful as it just makes a nice way to see a diff. Thank you!

[JimmyS83]

Sent :)