jeanlemotan/silkopter

UAV autopilot

silkopter's Issues

RC: add deadband to the sticks

FC: create a new CPPM RC node

This will take a CPPM stream and output a Multirotor_Commands stream.
Useful for using silkopter with classic RC systems like Frsky

RC: In RTH mode, yaw cannot be controlled even if the brain allows it

Brain: after disconnecting the GS, the process latency increases linearly

RC/Brain: Add a message for the brain to reset the battery

This will be used when changing the battery

GS: performance drops a lot when the simulator window is rendered at the same time as a plot

FC: Make the entire FS read only

This is to prevent sd corruption in case of power loss.
A single partition should be made RW for saving videos and settings to it.

FC: add a flight recorder node

This should accept a variable number of input streams, each with its own type and rate and record them to disk in a way that would withstand a crash

FC/RC: mode switching error are not sent to the RC

Any pre-flight check fail is only logged now. If it fails the user has no idea why

RC/Brain: When reconnecting the RC after a signal loss ALT reads 4194732m

Distance reads a huge value as well.
For sure that home is not sent after signal loss.

Brain: add health indicator for the ADS1115

Brain: In Idle mode, the yaw target angle should be reset

RC: The vhy display should show '---' in RTH mode

Now it displays the last vhy modes. This is misleading and the user cannot control vhy modes while in rth mode.
Maybe only the YMode is controllable.

FC: use settings for the RC_Phy class.

In particular the wlan & spi interfaces, spi speed, etc

FC: Convert the is_healthy flag in the IStream to a bit mask

I'd like to have more info instead of just a good/bad binary flag.

Some possible flags I could use:

VALID - when the stream contains usable info. If this is false, the stream contains garbage (and should be treated as such)
PRIMARY - when the stream is reliable and the data comes from a primary source. Example - ECEF position comes from GPS as opposed to being computed from baro + accelerometer

FC: position hold is unstable

I think I need a velocity PID instead of a PI only

Viewer: Video aspect ration is wrong

FC: figure out a way to deal with sensor failure.

GS: The map widget resets the zoom level when resizing the window

Question / Prompt

Have you checked out OpenHD? Looks like there is some overlap in interests
https://github.com/OpenHD/Open.HD

Nice work on this project!

Luke

Brain: Rename to FC

GS: The map widget cannot be scrolled as it continually resets the position to the incoming brain positon

Brain: when in RTH mode, after the RC signal comes back the UAV starts to spin continuously

The RTH mode allows yaw control and the bug is there for sure

FC: implement hardware glitch filter for some nodes

It could work by discarding obviously broken samples.
For example if the GPS receives a position that is 100m away from the previous one, chances are it's not accurate
Or if the IMU receives gravity pointing left or a sudden huge rotation rate on one axis, smth is broken.

The node could skip the invalid sample at first, and if they keep happening it could mark the whole stream as invalid.

FC: When the RC disconnects, all motors spin to full throttle

RC: mode switching doesn't consistently set the throttle actuator

Fly mode, ALT vmode -> RTH -> Fly mode results in a disabled actuator

Viewer: create a hud

I need altitude, horizontal and vertical speeds, distance to home, direction to home, battery info etc

FC: sometimes the ANGLE hmode is unstable

There is constant wobbling. Switching to RATE and back to ANGLE fixes the issue.
The repro so far:

• get some distance away from home
• disconnect the RC
• wait for the UAV to get back home
• reconnect the RC
• the UAV starts spinning due to a yaw bug *not sure it's related to this bug
• sometimes the wobble starts

GS: sometimes the value editors don't show up

Seems to happen when focusing another main window when an editor is open

Viewer: After the focus is lost, the frame interval reverts back to 1

This results in a FPS of 60 and some increased latency

RC: save all incoming info in a flight log, in case smth happens

I need a viewer for this - probably the GS

FC: the brain should remember the last battery data when restarted.

Unless the voltage is above a certain threshold, like 3.74V per cell. In this case it should consider it a new pack.

FC: Add a way for nodes to raise exceptions

The purpose is to have a way for communicating to the GS/RC various errors or warnings.

I could use logging with special topics for this purpose or better yet - a specific set of functions.
Smth like:
raise(Error, "Bus {} is unresponsive: {}", m_bus->get_name(), error_str);

FC/GS: Deleting a node leaves the brain in an inconsistent state

There are still nodes pointing to the deleted node.
The 'fix' now is to manually delete the settings.json file to remove the dangling references

RC: When reconnecting, the rc should send some reset message so the brain can send some vital info

Like home position, current extended status (vhy flight modes etc).

RC: simpler disarm button assignment

Now disarming is done by releasing the ARM button while moving the stick to the low-left corner. It's a bit inconvenient.
Alternative ways would be press 2 distant buttons simultaneously.

I need this to be ale to quickly disarm in case of emergency.

FC: add some missing config params for the Multirotor_Brain

Check the TODOs in code

RC: fix modes when coming out of RTH

Ideal modes:
vmode: ALTITUDE
hmode: POSITION
ymode: ANGLE

FC: Add public configurable parameters for each node

The idea is to have some of the params from the config structure of each node public, so it can be changed live form the RC/Viewer.
For example the Rate PID, H/V/Y PIDs etc.
I don't need the whole config, just some of its params.
I'd also need some API to enumerate them, their type and ranges (including the items for enums) and assign them to the RC knobs for quick tuning.

FC: after disarming, the home location says 0, 0, 0.

The RC stops receiving the home location even if the Brain says 'Home acquired, sending to RC'

FC: implement a failsafe for GPS loss

If GPS signal is lost the ECEF Position, Velocity and Linear Acceleration streams will get lost as well.
So Position HMode and Altitude VMode will stop working.

Possible solutions:

1. Use Baro for Altitude VMode
2. Switch to still functional modes: Angle hmode and throttle vmode and alert the user
3. Switch to Dead Reckoning for both Altitude and Position. Altitude might work with the baro but Position will diverge instantly.
4. Add GPS hardware redundancy to minimize the chances of this happening

FC: check every single node that they don't stall the pipeline under no circumstance

Some problematic nodes:
ADS1115
SRF0x
UBlox