Page 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 79

Thread: Just released: create your own stage notes with voice commands

  1. #41
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    I'll review the use of 'over' and think about it. It's kind of a catch-all for "drive over a crest" but I guess it's quite personal as to whether that feels right or not.

    Regarding missing notes, this may be a bug or something that's not correctly wired up (for some modifiers or non-core notes), but if a corner call is missing entirely then it's clearly very serious. I've not encountered this myself but will keep an eye out for it.

    Call placement is difficult to get right. The app expects the call to be created (in recce mode) at the end of a corner or obstacle (because you won't know if that 'long 4 left' should have 'tightens' until you actually complete the corner). This feels sensible to me because it allows the corner and it's modifier(s) (tightens, narrows, etc) and associated additional notes (rocks outside, etc) to be logged at the same time and allows you to create the call when you know all the details of the corner. However, the disadvantage of this is that the app has to modify the pace note's location to account for the obstacle / corner length in order to derive a sensible trigger point. We want to put the trigger point at the start of the corner but we can't create the pace note until the end of the corner. So the app has to estimate. It uses some finger-in-air values for how long a corner is (taking into account 'long' / 'very long' modifiers and a few other things). It's not perfect but it really shouldn't need to be - as long as the corner start point is approximately correct any error in the call timing should be small compared to the look-ahead time.

    When you make a single voice command this command can contain a corner, a couple of modifiers and a couple of additional notes. For example, "right 3" [the corner]; "tightens", "don't cut" [the modifiers]; "rocks outside", "caution" [the additional notes]. In this example the app creates 1 entry for the corner and its modifiers, and one entry each for the additional notes. The app uses the stage distance at the point where you pressed the radio button for all of these notes to allow it to group them together so they are all called at the same trigger point. If you run the app with 'always on' voice recognition the app doesn't know when the voice command started so it has to use your stage distance at the point where it acknowledges the command. For this reason, it's far far better to use 'push and hold' voice recognition mode. If you must use 'always on' then you need to do your recce much slower so the pace note trigger point isn't too far from where you started your command.

    The app should never move a call down the road but there may be cases where a particularly long corner gets called a bit late, if you create the pace note on the exit of that corner. I.e. an unusually long fast corner might be 300 metres long, you make the call at the end of the corner, the app assumes that 'very long right 6' corners are 200 metres long, so the app places the pace note trigger point 100m into the corner. In most cases like this being late shouldn't have a huge impact - if you're travelling 50m/s the call would be 2s late, and with a look ahead of 4 seconds it should be OK(ish). But it'll never be perfect - I could make the corner length estimates more generous but the downside of that is that calls will be earlier. When I'm doing a recce I wait till the end of a corner before making the pace note command but in cases where the corner is really really long I make the command earlier because i know that the corner start estimate will be a bit off.

    The default look ahead is 4 seconds, for rushing there are 2 parameters - speed ('Codriver rushing speed threshold') and distance ('Codriver rushing look ahead'). The speed param means "always use rushed calls when going faster than this". The look ahead param means "use rushed calls if there's another batch of notes coming up in the next X seconds". The idea here is that we rush in cases where the notes are coming thick and fast, and in cases where the codriver is shitting himself because we're going a million miles an hour. So the default values do make sense and they work correctly (but I have to be honest, I don't like how the rushed calls sound so I change the 'Codriver rushing look ahead' value to be 0 to disable that behaviour).


    Andreas - the release version is definitely worth trying - it's generally better than the beta. There's an additional property in there which adjusts the look-ahead time a little to account for a corner's expected speed. The goal is to delay calls about stuff after a very slow corner. Without this, the app uses the current speed to decide which notes need to be played. If we're approaching a slow corner but are still going fast, the app may decide it needs to tell the driver about lots of stuff after the slow corner, before he reaches that corner. This isn't necessarily what you want so this option ('Dynamic co-driver distance look ahead', enabled by default) should help a little here.

  2. #42
    It works great with the new version!
    I'm realized that I am missing a note, I would like to have for example.
    "Right 5 tightens 2", "right 2 opens and tightens 1", having a number after the tightens so I know how much it tightens.
    Other than that it has become apparent that the pacenotes now have become so good that it's my own note making skills that are the weakest point of the entire system haha.
    Great job!

  3. #43
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    Yes, the "X tightens to Y" notes are a pretty glaring omission. I avoided them because I'd assumed they added a load of complications but perhaps it's not as bad as I'd feared. I'll do some digging. Maybe it would be safe to add a limited selection of all the possibilities or something. Will report back

  4. #44
    I have sometimes used very long notes such as "Right 5 tightens bad over crest into gravel keep in" and the voice detection has no problems with it, gets it 100% of the time so I'm really impressed by the voice recognition. So I don't believe that "right 5 tightens 4" would be any problem for the program since it can handle my very long notes otherwise hehe.

  5. #45
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    the challenge is what to do with the corner modifiers. The implementation assumes that a command can contain zero or one corners, so any modifiers are applied to the corner (if it's part of the command). So the command
    "right 4 opens, tightens to 2" would be interpreted correctly to 2 separate notes - 'right4+opens' and 'tightens2'. However, the command "right 4 tightens to 2, opens" would be incorrectly parsed. The "opens" modifier would be applied to the initial corner like the previous example so it would be parsed to the same calls - 'rght4+opens' and 'tightens2'. Which might end badly.

    I think I have a way to make this work and place the modifiers in correct calls but i'm getting right to the limit of what the current parsers can handle without pulling it apart and re-doing it.

    The other issue is that these tightens calls naturally encourage the use of connecting words like "and" / "then". These aren't handled at all by the speech recogniser - they're not part of its grammar so would interfere with recognition and would not be parsed. I'll think on that

  6. #46
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    OK, I think I've managed to crack this. I've reworked the parser a bit as part of some ongoing work to stop the app reordering elements of a call and added some more stuff. So now the app correctly recognises and parses commands like

    "right four over crest don't cut and bridge then tightens to three"

    "and" and "then" are, in this case, separate pace note calls so this parses into
    right4+don't cut
    over crest
    and
    bridge
    then
    tightens to three

    It should put the modifiers on the right note now too

  7. #47
    That's great to hear! So then or and needs to be called for when I want to link corners into one? How much can I stretch this? Say for example "Right 5 tightens 4 tightens 3"? Could I get this call by saying "Right 5 then tightens 4 then tightens 3"?

  8. #48
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    yes, that should work. I've just tested "right four over crest don't cut tightens to three then left five tightens to two", which works, as does "right four over crest don't cut tightens to three then tightens to two". Bear in mind that doing all this as a single command will result in each item having the same trigger distance - they'll be read togther.

    When I say "works", I mean it's parsed correctly when I give the parser the text and it generates the expected pace note entries in the correct order. I need to do actual testing to confirm that the speech recogniser works correctly and that there are no nasty surprises. There's a limit of 8 items in a single command, where 1 item can be a corner; a 'tightens to'; a modifier; a link word (and/then/into); or an obstacle (crest, rocks outside, etc). So there's a limit to how much you can stack into a single command.

    "Left four don't cut rocks inside tightens to three then ford and right two bad camber" works, but any more items would be missed off. But I'm way past what the parser was written to handle. I'm not expecting any issues with the speech recogniser here except a possible timeout (it takes a while to make the command)

  9. #49
    Crew Chief Mega Corp CEO mr_belowski's Avatar
    Join Date
    Feb 2017
    Posts
    1,815
    ok.. further tests show the speech recogniser can't really handle this. The parser and logic works correctly but the speech recogniser gives up after a few seconds. The example of "Left four don't cut rocks inside tightens to three then ford and right two bad camber" works up to the end, where "right two bad camber" is mis-recognised (often as "right entry chicane" on my system). I'm seeing the speech recogniser stop listening and kick off the processing / parsing work while I'm still talking as well, if the command is very long.

    So there's a practical limit here to what the recogniser can cope with but it's quite a lot already. I think it's unlikely you'd reach this limit unless you're deliberately testing unrealistic edge-cases like this. So it's looking promising. With any luck the changes will be in the next build, it feels like it's a major improvement.

    One outstanding question is what to do with "caution" / "danger" items. Currently these are a special case and are always inserted at the front of a batch regardless of where they appear. So "right three caution rocks outside" would be read as "caution, right three rocks outside". I'm thinking this behaviour is probably not what's wanted and I should take it out and leave the caution / danger in the batch at the position it was inserted

  10. #50
    I totally agree with the caution, especially now that you can have several turns in a note that the caution is not placed in front of everything. Will be interesting to see what can be done with the new version

Page 5 of 8 FirstFirst ... 34567 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •