Re-support TUI

[Grazfather]

1. Revert the revert
2. Fix the issue.

[zombieCraig]

A few questions on the TUI.

1. Why is the keyboard not automatically enabled when you enable the text interface?
2. When using the keyboard it doesn't seem to generate the proper packets, for instance, if I run the gui icsim, I should be able to test it with the text interface for controls but it does not respond to any of the controls or match what the TUI is showing.
3. How is TUI designed to work in a headless environment? Will a raspberry PI be the controls on a real can bus with the ICSim GUI on another listening system?

[Grazfather]

1. Without -k you can use the text ui but still control it with a playstation controller.
2. It absolutely should. Which seed are you using? Please give me the command line options for both and I'll try to reproduce. Make sure the GUI one is freshly built and not the old repo one.
3. We have to figure out why you're seeing communication issues, but as you designed it it only uses CAN to transfer data, so as long as their seed is the same they should be able to communicate. So yes for sure.

[Grazfather]

I have it tested this branch locally

• text mode ic, text mode/keyboard controls
• gui ic, text mode/keyboard controls

(I don't have a controller to test with a gamepad)

* d981cd8 2017-09-18 (HEAD -> support_tui, mine/support_tui) Improve speed calc accuracy

DISPLAY=:0 ./icsim vcan0&
./controls -d -t -k -X vcan0

[zombieCraig]

@Grazfather Excellent! I'll remerge in a bit.

[Grazfather]

Cool, but let's make sure it works for you, your point 2:

When using the keyboard it doesn't seem to generate the proper packets, for instance, if I run the gui icsim, I should be able to test it with the text interface for controls but it does not respond to any of the controls or match what the TUI is showing.

It's totally reasonable that there's something funky going on here.

Also I just realized that if the raspberry pi has a different prng than the other computer, then even if their seeds are the same the random values could be different. Now I don't think that this is the case, but it could be something to look into. Easy enough to test, of course.

[zombieCraig]

@Grazfather Hmmm, I grabbed the new version and it no longer crashes when loading the GUI (sweet!) both text and gui changes are visible in the IC. However the response is really really slow. Throttle works OK. but the turn indicator is practically non-functional. The acceleration should be smooth and instantaneous for me it seems that maybe the polling loop is messed up? Speed jumps at 5 mph increments and idle barely moves. I haven't been able to spend any time digging into it yet to track down the source of the issue.

OT: small suggestion, when keyboard control is enabled, print a legend of keys.

[Grazfather]

Yeah, I noticed that also. The reason it's slow, I think, is because it's so much faster to run the loop, and the delay is only 5ms. With the GUI it might be 5ms + 5ms drawing, with TUI maybe 5ms + 0.5ms drawing. This floods the CAN bus faster than the GUI can read it. I've noticed, for example, that the indicator will keep blinking on the UI for a few seconds after I kill the controller. This can be fixed by increasing the sleep, but the correct fix would be to actually maintain a frame rate.

I'll add a legend for sure.

[Grazfather]

I've added the changes mentioned. Care to try them out?

[Grazfather]

Took another look, and improved the rate limiting (currently it'll send at most 100 messages (per ID) per second. This can be slowed down by the GUI since the redraw happens in the same thread.