qiuchengxuan / pro-flight

Flight control software written in rust, provides more flexibility for customize and better OSD experience
GNU General Public License v2.0
25 stars 1 forks source link

A few questions #5

Open Cightline opened 2 years ago

Cightline commented 2 years ago

Where did you learn about the 1.0g limit for autopilots?, I've only seen it in DCS, and neither INAV or Ardupilot have support for it. (I'm not in the aerospace industry so all of my knowledge comes from DCS or YouTube). You should advertise that you have features that the other open-source autopilots don't have; ie: 1.0g limit, flight path marker, AoA indications, etc..., hopefully that'd bring in more developers.
Also, can you setup monthly donations?, I won't be able to donate a lot but it'll be better than nothing. Lastly, I'm not sure if you're aware but the drone-os creator is Ukrainian and hasn't been working on drone-os for a while, it does appear that he's contributing to private repositories though. I don't know if that has any affect on what you're doing.

qiuchengxuan commented 2 years ago

Thanks for your paying attention.

Where did you learn about the 1.0g limit for autopilots?, I've only seen it in DCS, and neither INAV or Ardupilot have support for it. (I'm not in the aerospace industry so all of my knowledge comes from DCS or YouTube).

F/A-18C will maintain 1g without any force on the stick according to the manual.

You should advertise that you have features that the other open-source autopilots don't have; ie: 1.0g limit, flight path marker, AoA indications, etc..., hopefully that'd bring in more developers.

Currently it's code structure is not stable yet, and I even didn't successfully takeoff my drone with it.

I think when I finished sdmmc/ExFAT/blackbox, and successfully fly my drone with it, I'll advertise to others that it's a project that worth to join.

Also, can you setup monthly donations?, I won't be able to donate a lot but it'll be better than nothing.

The main factor that affects progress is time, so donation probably won't help.

Lastly, I'm not sure if you're aware but the drone-os creator is Ukrainian and hasn't been working on drone-os for a while, it does appear that he's contributing to private repositories though. I don't know if that has any affect on what you're doing.

I indeed aware, currently drone-os is sufficient enough for pro-flight, so it won't affect for now.

Cightline commented 2 years ago

The main factor that affects progress is time, so donation probably won't help.

No worries. Do you plan on creating a trait framework for others to implement at some point? Embedded-hal does that and it seems to work well.

qiuchengxuan commented 2 years ago

No worries. Do you plan on creating a trait framework for others to implement at some point? Embedded-hal does that and it seems to work well.

It's already exists as hal crate, while DMA implementation differs from embedded-hal, which is the primary part that I'm unsure whether to replace it.

Hardware unrelated parts are probably stable enough

Board initialize procedure is quite ugly while I'v no idea how to improve it.

Actually I have some idea, while it requires a lot of modification to drone-os.

Cightline commented 2 years ago

Board initialize procedure is quite ugly while I'v no idea how to improve it.

Are you talking about this area?

You could design a trait/struct framework that way others could implement the hardware initialization (and other details) for their specific target. I'm not an expert on doing that, I only have a rough idea from using atsamd-hal, embedded-graphics, etc..

If you do the trait framework you could focus on the core flight control logic while others deal with the hardware. You probably already know enough about the hardware to not create any difficulties for people implementing the trait framework.

qiuchengxuan commented 2 years ago

Board initialize procedure is quite ugly while I'v no idea how to improve it.

Are you talking about this area?

You could design a trait/struct framework that way others could implement the hardware initialization (and other details) for their specific target. I'm not an expert on doing that, I only have a rough idea from using atsamd-hal, embedded-graphics, etc..

If you do the trait framework you could focus on the core flight control logic while others deal with the hardware. You probably already know enough about the hardware to not create any difficulties for people implementing the trait framework.

Yeah

It's board specific, not target specific, so trait/struct framework won't help. If there's really someone willing to help, I'd prefer someone help me to fix JSBSim based simulation, which is not working properly.

Cightline commented 2 years ago

Can you explain the JSBSim issue in more detail? I don't know if I'll be able to help but someone reading these comments might.