New OS free F4Light HAL

One of the devs has got the matek F4-Wing running the ChibiOS HAL, but doesn’t support osd yet.
I don’t think the F4Light HAL has been ported to that board yet.

1 Like

Thanks for your reply.Could you please direct me to the thread or discussion about Matek F4 wing board?

It’s in the gitter chat here: Join the chat in ArduPilot/ChibiOS
But @David_SpektreWorks did the work

1 Like

Really? Better not to mislead people by erroneous thinking.

Can this page be updated with a table of boards VS. supported OS ?

Is there a wiki page for the F4 Light OS ? I could not find one.

Apologies: it is hard to keep up. You do move things along very quickly!
I hope all is well.

in this post there is a link to the wiki

Yes this wiki: https://github.com/night-ghost/ardupilot/wiki is a good start.
But there is no central page/table where all the supported boads are listed :frowning:

It would be nice to add such an info to:
http://ardupilot.org/copter/docs/common-autopilots.html

1 Like

Is it possible to get this working on matek f405 aio?

Sorry don’t mean to sound like a complete noob! Just flashed N-G version of AP (Plane) from latest.zip to an Omnibus F4 Pro v2 board. Connects in mission planner just fine (after installing px4 usb driver). Configured on a z84 wing and all looking good. Trying to get the integrated OSD flashed, as my camera feed not coming through (so assume I need to flash the OSD to make this happen). I read the wiki article here: ardupilot/libraries/AP_HAL_F4Light/boards/f4light_AirbotV2/1_read_me.md at RevoMini · night-ghost/ardupilot · GitHub
and I see talk about:

Firmware supports connection to built-in OSD with CT from my MinimOSD (GitHub - night-ghost/minimosd-extra: Full rework of minimosd-extra with lots of news). To do this:

set HAL_CONNECT_COM parameter to 4, then reboot / power cycle
USB will be connected to OSD after reboot, supported load/store/fonts in MAVLink mode

OK, so I changed the parameter, and re-powered via USB cable. I now see a COM4 port as well as COM5 (which I used for MP). I assume this COM4 port is what I need to use for OSD connection (I had to install FTDI driver to get device manager to be happy)? I.e. not same port that MP used?
Next I see the comment about “MAVLink mode”, and a corresponding option on the MinimOSD GUI. If I select this menu option in the GUI then the “Update Firmware…” option is greyed out. so:

  1. How do I put the MinimOSD firmware on the board? Or is it included inside the AP firmware provided by N-G binary already?
  2. If I put the eeprom.osd and font.mcm files onto a SD card as suggested and then power up the board, will it just transfer these during boot? Or do I have to somehow upload these from within the GUI?

Sorry, the wiki doesn’t explain this too thoroughly.

Thanks, Paul

Edit - I have determined that the way to get the OSD eeprom and fonts files onto the board, are simply to write them to to the root of an SD card, place it in the FC and reboot (as per the readme on n-g github for this board) - but!!! now this is the real solution - I needed to use an older firmware binary for this to work - using the current binary (f4light_AirbotV2_bl.bin) from current latest.zip downloaded yesterday from github, this does not work. OSD files don’t get read from the SD card, so I needed to go back to an older version of the firmware which I obtained from the attachment in this RCG thread (msg 1): https://www.rcgroups.com/forums/showthread.php?3070417-Most-integrated-Arduplane-FC-solution

Not sure if @night_ghost monitors this thread, but if you do, then please see the above.

Thanks, Paul

Using Plane 3.9 stable I’m having troubes getting the RC signals from the receiver into a Revo. I tried two receivers that are working fine with a Pixhawk, but connecting the SBUS port of the receiver to pin 5 (or 6) of the “RC IN” in the Revo does nothing. Mission Planner still claims “NO RC Receiver”.

Comments in the code talk about pins 3 and 4 of “RC INPUT” for PPM signals (which are not used in LibrePilot, btw). However, the documentation here says that original pin assignement is respected, thus pins, 5 and 6.

I have tried all options (pins, 3, 4, 5 and 6) to no avail… Anyone with the same issue? Any idea?

[Edit some time later…]
From lines 24 and 25 here I see it is connected to pins 14 and 15 of the STM32F4, which are indeed corresponding to pins 5 and 6 of the “RC IN” port in the Revo (see the PDF inside here, top left corner).

So, pins 5 and 6 are indeed the places to connect the SBUS from the FrSky receivers but still I get “NO RC Receiver” in Mission Planner. :disappointed_relieved:

Got exactly same problem with the 3.6-RC10 arducopter firmware…did you manage to fix it?

Not really :disappointed_relieved:
I focused on other stuff and I plan to go back to this eventually. Maybe any of the new releases (3.9 onward in plane) will get this fixed.

Hi, I want to give a try to F4Light but have problems with figuring out its current status. Is it true that the support for Omnibus F4 and other boards is now provided by the ChibiOS version? Is any F4Light-supported board still available from the ardupilot’s master? Or I need to go to the night-ghost’s fork, which I have tried but I get errors when trying to compile? So many options with HAL and waf/make, help! :slight_smile:

99% of the collective energy of ArduPilot on F4-based <$50 flight controllers is ChibiOS-based. F4Light HAL is effectively dead.

Kelly

OK, thanks for answering, it was also my impression and it’s not surprising. However, F4Light is still very interesting if you want to learn about the details of the HAL layer. But I see that in order to compile it maybe I need to use a repository version from early this year, when the ChibiOS hasn’t been here yet…

Thanks, I’ve tried with several reverts, and suddenly one of them compiled :slight_smile: and even works fine, connects to the APM planner, the sensors are working, when I’ve changed the welcome message it has shown correctly… great! I think F4Light would make it a lot easier to learn about the AP internals and adapt to a new controller architecture, and that’s why it should be kept active at least for a single compilation target. Thanks once more!