Project notes

[skaman82]

Will be posting further notes in here. Any feedback is also welcome!

[skaman82]

Konstantin: "While hydra stays silent about this, may I suggest another feature? It would be great to have a wizart to calibrate the receiver (ask user to center all sticks, move them to their maximum deflection to properly set up rxrange feature). For the general idea please have a look here https://librepilot.atlassian.net/wiki/display/LPDOC/RC+Transmitter+Wizard (video from 1:02)"

[skaman82]

@enly1 You can have a look in the PSD, but do not simply copy and paste it please :D https://github.com/skaman82/CF_GUI/tree/master/Archive

[enly1]

@skaman82 - thanks for the reference, but not sure what you mean

I've seen the screenshots before and have refrained from grabbing stuff as you indicated the license terms in the repo (although technically your other repo makes them gpl if you didn't realise).

Tried to open in paint.net with the psd plugin, but it blew the 16GB ram in my laptop and pushed the SSD for 150MBytes.Sec paging ... off to try GIMP instead (failed - moaned about something outside borders before crashing .. oh well)... to take a look.

Photoshop trial sorted the issues with memory consumption etc - had a good look around - thanks. Once we have all the assets out as items that can be included in the giu, I'll try and make use of them as and when you give me the okay - will also try and keep my UI screens in line with the css tag naming etc so am more familiar with this new UI when I get to work on it.

[skaman82]

@enly1 great that this worked out for you. I already put things in motion and do the heavy lifting by implementing the design into configurator. If you have a little time I would very appreciate some help with things I can't sort out. Just have a look at the issue tracker here: https://github.com/skaman82/cleanflight-configurator/issues BTW. I exported all icons as svg files.

[skaman82]

PR is ready to go! :) https://github.com/cleanflight/cleanflight-configurator/pull/266

[skaman82]

@NightHawk32 I noticed that you started to contribute to cleanflight-configurator. I just redesigned the configurator during the last month and I am currently working on some planed features and concepts but I am actually stuck on JS at the moment. I am a graphic designer and not a dev so my coding skills are not so great (CSS/HTML is ok but no knowledge in JS). I also noticed you can get things done inside the firmware and this is very handy for the future tasks.

If you like what I'm done so far, do you interested in work on further things together? I have so many ideas how to make Cleanflight-Configurator much better and more user friendly but I never would accomplish this alone.

The GUI concepts are stored in this repo, the actual work ist going on in here https://github.com/skaman82/cleanflight-configurator/issues/1 and "new_stuff" branch of that repo.

[skaman82]

@NightHawk32 It is also helping that you are also from Germany - this could make communication easier :)

[NightHawk32]

Wow the positive feedback in this project is great and I really appreciate your work on the new configurator, it just looks amazing.

I have been using cleanflight for quite a while but I decided to start contributing my Ideas. I'm really interested in woking with you. Maybe we can have a chat about your Ideas and how to start.

[skaman82]

@NightHawk32 Great to hear that! The current issue tracker is more a todo list. https://github.com/skaman82/cleanflight-configurator/issues

I want to implement three things for the next PR:

• Dataflash status in the Header • Global profile switch in the Header • GoogleMap in the GPS tab that uses the LAT/LONG information to generate a map if the device is online

There are more ideas in place for other things like a failsafe tab, but some of them are based on GPS stuff digitalentity is currently working on.

So you can pick something you like to figure out :) Wanderzell and ozziegt also like to help on github. It is better to coordinate the work here because everyone of us has limited time to work on this.

[skaman82]

First thoughts on a separate failsafe tab with integrated RTH event @digitalentity what do you think?

[digitalentity]

@skaman82, Looks good, however only "RTH nose in" is supported by iNav at the moment :)

[skaman82]

@digitalentity I know, but I've seen that you considered to implement also "tail in". At the time this tab becomes reality you might have done this already ;)

[digitalentity]

@skaman82 I would rework this tab a little:

[skaman82]

@digitalentity will do that, thanks for your feedback

[skaman82]

@digitalentity done that. What du you think should also be configurable in this tab?

[digitalentity]

@skaman82 We have several CLI parameters related to failsafe:

failsafe_delay = 10
failsafe_off_delay = 200
failsafe_throttle = 1000
failsafe_kill_switch = OFF
failsafe_throttle_low_delay = 100

I think at least failsafe_delay, failsafe_off_delay and failsafe_kill_switch should be configurable from GUI. rxfail command is also related to failsafe. @ProDrone, what do you think?

[marksev1]

Skaman regarding GMap, will you make it save the "map tiles" so could use it offline. Also may I suggest adding the AHI and compass in addition to basic telemetry info into the GMap area.

[skaman82]

@marksev1 Still to have figure out the basic functionality first :). The things you mentioned could be done as enhancement in the future. In the first step it is required to be connected to the internet to see the map. btw. it would be nice to discuss this here https://github.com/skaman82/cleanflight-configurator/issues/14

[ProDrone]

@digitalentity @skaman82 Failsafe has two stages.

Stage 1 is intended to cover short dropouts and to preset all channels for a possible stage 2. In this stage bad (out of range) pulses are substituted with the values defined with CLI rxfail command, valid pulsrange is defined with rx_min_usec and rx_max_usec.

Stage 2 has to handle the persistent failsafe condition and currently only has a simple auto-landing procedure.

I think it is ideal to have both stages configurable from a dedicated failsafe tab.

A dropdown selection box for the desired procedure in stage 2 would be nice (maybe the GPS assisted procedures need their own setup-tab). Next to that it is desirable to have access to the other failsafe related variables:

failsafe_delay = 10
failsafe_off_delay = 200
failsafe_throttle = 1000
failsafe_kill_switch = OFF
failsafe_throttle_low_delay = 100

I actually tried to make a sort of prototype for this last week, but deleted my efforts in frustration. html, css is not really my thing. I can provide the needed MSP messages and process these in the configurator using JS. But my JS knowledge is limited.

[skaman82]

@ProDrone I can make a HTML/CSS prototype of the failsafe tab for you to work with. I think here has to go everything what has to do with failsafe procedures - even the gps stuff if RTH or POSHOLD can be triggered on failsafe. The other options for different GPS flight modes will go into a separate tab, as @digitalentity proposed. I need to make a sketch of all available options and input fields before I can do the actual html work. Do you maybe have a sketch of this already?

[skaman82]

@ProDrone if I understand this right, the failsafe tab could look like this. Feel free to put your notes on this layout. I am personally not sure if it is wise to present so many configurable options to the user. So as it is this looks overwhelming and complicated - cleanflight should be easy, right? Is there a way to make this easier with limited set of options?

[skaman82]

@ProDrone this is a sample of user friendly failsafe tabs. Just select your desired behavior and the system does the rest. This one I trust to do the job. This looks easy, not the layout above. Given so many config options I would never feel safe because I might configured something wrong. Some ideas?

[skaman82]

Why would someone want to select disarm the craft instantly on failsafe? This would never come to my mind. This just intentionally crashes the aircraft and could do some damage to objects underneath.

[skaman82]

@ProDrone Rearranged some things and deleted the instant disarm option. Now the general things come first and the advanced settings second.

[ProDrone]

@skaman82 For racing quads it is common to just drop the quad when the failsafe stage 2 is entered. It is the safest thing to do and probably causes the least damage to equipment and property (or people).

I wish i could communicate the layout with pictures, like you do. But that would take me forever...

What i was thinking of is a left pane that has the stage 1 settings and a right pane that has the stage 2 settings. The stage 1 pane should have the rxfail values for all channels (labels similar to receiver tab) and the rx_min_usec and rx_max_usec The stage 2 pane should have the procedure selection and other failsafe settings.

[ProDrone]

Instant disarm is not a separate procedure but happens when you set failsafe_throttle to minimum and failsafe_off_delay to a very low value.

I also want to get rid of the switch to enable/disable failsafe, because it makes no sense. If you switch it off, the quad will hold the rxfail values forever (fly away?) So it should become a requirement to configure stage 2 (default could be to just drop the quad unless configured otherwise).

[skaman82]

@ProDrone Could you just make a sketch of the layout of the config sections of the two stages to clarify. Just make it on a sheet of paper and post a photo of it :)

[ProDrone]

@skaman82 (i feel embarrassed, but here it is... :disappointed_relieved:)

[skaman82]

@ProDrone Thank you for your piece of art :). I can make this as layout first before I start to work on the HTML Template.

Some thoughts on this. I personally don't think that throwing a bunch of settings at the users will make cleanflight more accessible. I fact it makes the config even more complicated. I see this every day at my work. The problem is that the people who make/produce the product often think absolutely different about the product and have a whole different knowledge base than they customers. I think the cleanflight devs should always think about the simplest user who is not a pro flyer and uses cleanflight just to get his model in the air to have some fun. Most cleanflight users are not pro racing pilots or devs.

This is why I started to work on the configurator in the first place because i have the feeling that cleanflight is developed BY tech people (=good) FOR tech people (=bad). The average dummy user (like me) gets frustrated if the config is not self explanatory and he has to go through the docs to understand the half of it. So why some other consumer drone software does the failsafe setup with 2-4 options to choose from to get things configured and in cleanflight you have to go through a bunch cryptic settings to get the same thing done? In my opinion it is critical to keep the complicated tech stuff in the background and not place it in main configuration. The magic should be happening in the background. Just keep it in the CLI for now and put it in a parameter browser if the cli is gone for people who are enjoying to play with different settings to configure the hell of their quads.

[ProDrone]

Now i REALLY find your thoughts interesting! Because i feel that you what you are telling me is exactly what i tend to tell others: make things as simple as they can be (but not simpler). The point is that, in order to configure failsafe, you may need to tinker with these settings to get it right.

The reason for this is that there are many different RX's, connection types, settings etc. Other consumer drones have a closed system with a dedicated TX/RX and flightcontroller. All streamlined for one goal. This is not the case for cleanflight.

The real challenge is to make even a complex thing like this, accessible for the average user. For each and every item i like to see a help icon (question mark). Good defaults should prevent the necessity of setting it up by changing every item. I am really curious what we will end up with for this. It may need a few revisions...

[skaman82]

Cool, then we have the same goal here :) Quick question: what about the NAZA-M V2 Screenshot above? That is designed to work with different RX and the failsafe tab is so simple. It just works without the config fuzz.

[skaman82]

@ProDrone Question II: If we do this work then we should do this right. Could you consider making autonomous flight modes available as a failsafe event?

1. POSHOLD+ALTHOLD
2. RTH (i hope @digitalentity iNAV makes it soon into master)

[skaman82]

@ProDrone Question III on you drawing: It is really necessary to make AUX 1-12 configurable? - this would be a pretty long list most people don't care about. Most pilots have a 6-12 channel RX. Could we make just AUX 1-4 configurable?

[ProDrone]

@skaman82 Q1: The naza screenshot is simple because in the first screen you only make a choice between landing or RTH + landing (both GPS assisted modes). The second screen seems to only set the altitude for the RTH function. The explanation in the first screen simply says: "...when the main controller looses the signal from the TX", that by itself requires quite a lot of settings in Cleanflight.

Q2: As soon as @digitalentity has finished his project it can be added to the failsafe procedure pull down selector. Configuration of RTH settings should be done on a separate tab i think.

Q3: Cleanflight simply has the possibility of having 16 channels, freely assignable to several functions. In case of a failsafe event these should be manageable. We can limit the number of channels shown to the number of channels configured (like in the receiver tab). But the design still needs room to show them all 16, in case the user has a 16 channel configuration.

[ProDrone]

Maybe it is good to select the channel with a dropdown and then apply the mode and value with two other controls? Just to limit the amount of info on screen (and occupied screen space)?

[digitalentity]

Q2: I agree, RTH configuration should be done on a separate tab. Failsafe merely activates GPS assisted functionality (RTH, position hold, landing or whatever else).

[skaman82]

@ProDrone I did a mockup of your scribble and added some notes. Please correct me if I done something wrong.

[ProDrone]

@skaman82 Make a single mode setting for Roll, Pitch,Yaw and Throttle combined (called flight channels). Adding a help icon to that line for explanation.

All Aux channels can be accessed like i proposed above. Just one channel drop down selector and two elements. One for mode and one for value. What do you think?

I agree that names should be self-explanatory and not cryptic, but that is easy to change later, right?

Guard time for failsafe can be moved to stage 2.

We should not repeat the word failsafe on the failsafe tab i think.

Failsafe Stage 1 can be changed to Stage 1 Fallback Settings

Stage 1 Settings can be changed to Valid Pulse Range Settings

Yes, illustrated procedure selection is better. But how would you illustrate drop quad mode :joy:

[skaman82]

@ProDrone Drop quad : )

[ProDrone]

Haha, yes that will do :)

[Yamaford]

@skaman82 can you help us create a beta flight configurator?

[skaman82]

@Yamaford I can if it is not time sensitive. Have no time in the next weeks for this. But if we start just with some theme changes, it is doable for me to get this done in june.

[Yamaford]

Thanks. That is still faster than i could learn to do it myself. Maybe in the meantime we should start a branch. I find setting a stage gets more people with the skills to do it motivated and it would ve a good place for ideas. On May 17, 2016 7:15 AM, "Albert Kravcov" notifications@github.com wrote:

@Yamaford https://github.com/Yamaford I can if it is not time sensitive. Have no time in the next weeks for this. But if we start just with some theme changes, it is doable for me to get this done in june.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/skaman82/CF_GUI/issues/1#issuecomment-219731046

[skaman82]

@Yamaford as a start I created a repository :) https://github.com/skaman82/betaflight-configurator

[skaman82]

@Yamaford See https://github.com/betaflight/betaflight-configurator/pull/2