OSD Config tool for Linux ?
No offense, but any chance on getting configuration tool that runs on civilized operating system ?
Why not using something that is cross-platform ?
No result found
I should consider to make the CT cross-platform. The another reason is that some users couldn't get CT works when running on a virtual machine.
The linux binaries linked in the readme now are always latest master when the build succeeds.
Windows and OS X are a bit older atm, trying to get that to work the same way
Work goes on
How about splitting software into ?
- Library interacting with hardware
- Command line client
- Graphical client
And using something that does not involve Microsoft, but is truly open-source ? Maybe Mono if it really has to be C#, or Java, or C/C++ and Qt or even Python+GTK ?
Andy has built a command line app for PlayuavOSD board. We can make it works with the latest firmware.
For graphical client, QT maybe a choice because we can refer to the QGC like the current CT is based on MissionPlanner. I should learn how to build a graphical app with QT and take a look the codes of QGC.
The link you provided is only a firmware upload tool, not a configuration tool. It contains binary committed to the git this already should light up a red alarm in the head. But I checked if it compiles anyway. It does not, because it depends on missing or not committed header file ;)
This was originally made just so I could build PlayUAV on Linux. I am sorry it didnt work for you.
I added a README. Let me know if it builds ok for you?
It should be possible to extend it to upload params using the parameter file format. It would be great if someone wished to do that!
Thanks for cleaning it up, you could re-create repo just not to have binary file in the history, if you want, since it's such a fresh project. Then just use branches for new stuff and before committing to master rebase that branch on master.
Having command line tool would be cool. So questions are
- Does it talk UAVTalk after flashing ? Can I find wiring diagram somewhere ?
- What is used for rendering, is it STM32 itself for higher quality OSD or is it MAX for with lower resolution images ?
I don't know what are the parameters or how to configure them, but maybe having an uploader and json file with configuration would work ?
The Linux uploader was only a quick hack to get PlayUAV to upload on Linux. Works well and is much faste than the Mono one :) if there are strong feelings about the binary image I'll happily remove it, but its only 54 k and convenient atm.
There is a schematic and docs for PlayUAV OSD on the PlayUAV repo.
Parameters file is just simple format:
param = value
I am working on the parameters setting on PlayUAVOSDUploadHack. I will commit a pull request to the master once it completed.
Just needs someone to do GUI now :) Also should get around port serial port to windows etc ( looking to stm32flash for inspiration there)
It is not a bad thing to use command line apps as basis for GUI anyway, I think. The GUI can possibly be simpler, more modular and easier to script ( so can use Python, Java etc) and use the command line apps to do the hard work :)
We should probably add some more helpful exit codes to the app too !
(Mateusz, I removed the binary from the repo)
Feel free to clone it as starting point. I might try making layout with GtkBuilder on the weekend if I find time.
Looking good. Did a quick test and the basic app window popped up for me, so all in order. I see you added a menu since then..
Do you plan to make a simulation of the real display with movable widgets? That is probably the hardest part to get right I would guess..
I will try to make something usable as starting point for the GUI.
How about adapting the minimOSD configuration tool? It's written in Java and works on Linux. I like that the current screen rendered by OSD is shown on-line in a window displayed by the tool.
Another question: I run windows in a virtual machine and, for the configuration tool, the board resets the connection several times, what forces me to enable the USB device visible from the guest. This happens for example when reading/writing parameters. Can this be solved somehow? Is this an expected behaviour?
EDIT: I've found that Piccolo2D library
is very promising. It allows for defining several clicable, draggable and resizable widgets, what perfectly matches our aim. Questions:
-are widgets/texts resizable? For example, the compass, GPS position, etc?
-can the widgets overlap? (I guess that yes, it wasn't possible in text-based OSD)
I did some experiments. Piccolo2D seems to be a perfect candidate for a OS-independent GUI for graphical OSDs.
Clone the whole repo or just OpenPlayUavOSDGui/piccolo2d.java/examples/RUN.txt and the jar as defined in this file, and execute ./RUN.txt. Then choose the "Group Example MS" demo. It's almost done (I mean the implementation of clicking, dragging, grouping widgets) and I've written less than 20 lines of code! The window will be embedded in a JPanel, with additional configuration options.
Any comments about connecting to the board from Java? A plain serial port connection will suffice?
macfly1202 - 38y, France, Britany
Hi @maciek_252, I run you jar and test it. I don't understand what is it for.
I suppose you want to do a tools for moving 'objet' but it must be help with align function (like on minimosd). I think priority is to have a multiplateform config tools OR cleanflight/betaflight support on Naze32/SF3 before a tool for moving text and objet area. I'm not saying it's not cool feature. I'm just saying it's not a feature that I would like to see first. But well done !
https://www.dropbox.com/s/v8rv ... l%3D0
Hi @macfly1202, I wanted simply to test with which programming language it could be worth to begin coding. Now I know that Java is a good choice, better than say Qt, because of this library. I've done the serial port transmission (using the JSSC lib and not rxtxSerial, because the latter uses dynamic libraries specific to OS and I've got a version conflict on linux). I will try to rewrite the algorithm of decoding the byte array into OSD parameters.
And maybe I've got it wrong. You say that "priority is to have a multiplateform config tools", but there is such a tool - namely PlayUAVOSDUploadHack. Do you mean GUI or something more convenient?
I took some time in the last couple of days and starting making a config tool from scratch.
It can configure all settings now and most of the settings have previews (missing AttitudeMP, Attitude3D, compass (CWH), radar (CWH), climb rate, wind, map and warning)
It is build on electron and runs on windows, linux and osx.
I hope to get the preview better than in the original tool by reimplementing the font and general rendering (seems to work out good so far)
I will put it on github and publish binaries once me and a friend did some more testing and preview rendering is complete.
A screenshot as teaser is attached ;)
@gnrc - wonderful, was just preparing to configure my new PlayuavOSD and hit the wall when trying to launch the config tool under wine or mono (does it work for anyone?). Can't wait to use your config tool.
Finally, it is available for os x and windows here: https://github.com/TobiasBales ... rator
Linux binaries will be added the next couple days, but it does work.
There is also a hex file linked which is the latest code of my fork (pr has been put up to get it back to the upstream-repository) it includes the following things:
simple ahi mode (minimosd extra style)
efficiency panel (W/KM or W/M)
% sign for small font so no more RSSI: 98/
switching between panels/video inputs using fixed pwm signals (select switch for the corresponding mode, the old option is cycle). The video gets switched to input 2 at >= 1500us and input 1 at < 1500.
The panel gets switched to the panel that corresponds to an even distribution between the range of 950 and 2050us divided by the number of panels
Thanks gnrc, great work. Setting up npm was an absolute disaster on ubuntu (either ubuntu screwed up or npm is just that bad at handling the passing of time and version dependencies, and also at being time and disk space efficient...) but after that the configurator works well.
Some nitpicks I have: it seems rc5 is duplicated in the channel selection dropboxes and they have no scrollbars on my system making it seem as if there were only 9 channels. On my first run, when I plugged in the OSD, I think the configurator tried to stat /dev/ttyACM0 too son and got a Permission Denied exception. After that the settings would not update after hitting "READ FROM OSD" or would update only partially. With the OSD plugged in before starting the configurator, everything was fine.
Good catches, mind opening issues for those on the repo?
I will take a look but I tend to forget things if they are not in one central place ;)
Edit: I fixed the duplicate rc 5 entry, if you could open an issue for the other problem that would be great.
And yes getting node/npm running can be somewhat of a pain point but there are some somewhat easy solutions (ndenv), I will add info on that to the readme the next couple of days