Servers by jDrones

New OS free F4Light HAL

ardupilot

(Moobsen) #61

For the OpenPilot Revolution I followed night-ghosts instructions here https://github.com/night-ghost/ardupilot/wiki/Flash-firmware to get a bootloader. Then I just fetched the latest ardupilot mainline code (commit f75dea3), did a submodule update

git submodule update

and build with waf

./waf configure --board revo-mini
./waf --target bin/arducopter --upload

Building and uploading worked fine for me. I know it has been said before, but this is very cool, very nice work! :slight_smile: Can’t wait to see how this FC compares to a Pixracer.

Anyway, I also have a CC3D Revolution Mini here, which I would also like to try, but I don’t know how to get it into BL mode. Any hints?


(Moobsen) #62

OK after another hour of searching I found it: http://drone.hjns.net/openpilot-cc3d-mini-revo/
Same method as above worked. Weird is that it will only boot every other time, but I’ll have to test this more. For now I am very happy. :slight_smile:


(basti) #63

@moobsen, correct me if i’m wrong, but what you‘ve built with the above mentioned waf command is chibios for revo-mini, which in fact is nice too, but not exactly f4light.

cheers, basti.


(Andrea Belloni) #64

Yes Basti, what @moobsen has done with waf command is build for revo-mini with chibios HAL.
To build for revo-mini with F4light HAL:

cd ArduCopter
make f4light-clean
make f4light

I think that it would be better to be able to also build F4light with waf.
It would be more convenient especially for uploading and would easily allow you to switch from F4light to Chibios (and viceversa) for testing.


(Moobsen) #65

Indeed, I got confused there, sorry. So many options these day… :wink:


(night ghost) #66

Required changes already merged. Unfortunaly, PRs can hang for a time somehow.


(basti) #67

andrea,
i‘m quite far from considering myself in a position to judge different build environments, but yes, for someone like me who builds code only if it can‘t be avoided, waf seems like a pretty convenient solution.
that being said, the required definitions are way beyond my scope as per now, having successfully set up the build environment for the first time only a couple of weeks back. but eventually we‘ll get there :wink:

basti.


(night ghost) #68

this was not an issue of compile environment but result of changes in Dataflash_backend API while Dataflash_File_SD was left unchanged. So may be WAF is much much better than old Make, but it would not be able to prevent that build error.


(Andrea Belloni) #69

@night_ghost what I said about waf was only relative to the easy of building and uploading, I never thought that could solve those kind of problems, and I think also the comment of Basti was in that direction.

Anyway my problem with uploading is when I try to go back and forth between f4light and chibios (for omnibus f4 pro as example):

  • with your bootloader and f4light firmware I am able to flash new release with reboot in DFU and flash with dfu-util
  • with the same bootloader I am able to build and flash chibios based firmware
    ./waf configure --board omnibusf4pro
    ./waf copter
    ./waf copter --upload
  • when I try to flash again f4light firmware at this point I have no more the possibility to boot in DFU and I think I have to flash a .apj file in this way, but it doesn’t works.
    I hope there is some command line tool to flash bin or apj using the bootloader.

(night ghost) #70

Did you try Tools/ardupilotwaf/px_uploader.py ?

PS. My comment was about the fact that (some) people in team allows this HAL to come in broken state, that leads me to some thoughts.


(Andrea Belloni) #71

Thanks @night_ghost I think that once again you have solved my problem


(Andrea Belloni) #72

I retried to build f4light from ardupilot master commit 1fd52c4 but obtain the same error in DataFlash:

%% libraries/DataFlash/DataFlash.o
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp: In member function 'void DataFlash_Class::Init(const LogStructure*, uint8_t)':
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:113:79: error: invalid new-expression of abstract class type 'DataFlash_Revo'
             backends[_next_backend] = new DataFlash_Revo(*this, message_writer); // restore dataflash logs
                                                                               ^
In file included from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:10:0:
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash_Revo.h:46:7: note:   because the following virtual functions are pure within 'DataFlash_Revo':
 class DataFlash_Revo : public DataFlash_Backend
       ^
In file included from /home/andrea/src/ardupilot/libraries/DataFlash/DFMessageWriter.h:3:0,
                 from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.h:33,
                 from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:1:
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash_Backend.h:42:18: note: 	virtual void DataFlash_Backend::get_log_info(uint16_t, uint32_t&, uint32_t&)
     virtual void get_log_info(uint16_t log_num, uint32_t &size, uint32_t &time_utc) = 0;
                  ^
../mk/build_rules.mk:27: recipe for target '/tmp/ArduCopter.build/libraries/DataFlash/DataFlash.o' failed
make: *** [/tmp/ArduCopter.build/libraries/DataFlash/DataFlash.o] Error 1

(night ghost) #73

sorry but I don’t have so much time to single-handedly fight with the whole Ardupilot team, After those “correction” I stopped to try to fix such cases in upstream, and just do rebase and correct in my fork. I think if this HAL in master, the responsibility “not to spoil” should be on those who do changes. All my PRs are just “cherry-pick’s” from fork.
I think you should open an issue in upstream repo.


(James Pattison) #74

@peterbarker might be able to comment on the dataflash issue.


(Andrea Belloni) #75

Right I will open an issue on this


(night ghost) #76

did a PR to fix it now, but I’m very angry to someone who does breaking changes


(wkf94025) #77

Between make and waf, dfu-util and --upload, Chibios and F4Light, and all the various F4-based FC’s, this is not a simple ecosystem, eh? It took me some stumbling this weekend to figure out how to achieve consecutive flashing of Chibios versions, two-stepped: dfu-util to load a bootloader from Bootloader subdirectory, then MissionPlanner custom firmware approach. I think NG’s approach is currently better.

Kelly


(Jiro Hattori) #78

Little tricky process and some of file names has been changed, so I made summary for installation.
Make it for some one’s help.

Target flight controller is Omnibus F4 V2 Pro or equivalent.

  1. Prepare development environment on Ubuntu.
    http://ardupilot.org/dev/docs/building-setup-linux.html#building-setup-linux
    Need to install dfu-util, separatry.
    Git clone from night-ghost
    https://github.com/night-ghost/ardupilot
  2. Install bootloader
  • file location: ~/ardupilot/Tools/bootloaders/revo405_bl.bin
  • connect USB along with push button for DFU mode
  • check DFU mode by lsusb command
  • Upload bootloader by followings;
    sudo dfu-util -a 0 --dfuse-address 0x08000000 -D revo405_bl.bin
  1. Build with waf
    ./waf configure --board omnibusf4pro
    ./waf copter
    arducopter.bin (855764 byte) has been built
    ./waf --target bin/arducopter --upload

(Andrea Belloni) #79

In this way you are building for Omnibus F4 Pro with ChibiOS HAL, to build with F4Light Hal:
cd ArduCopter
make f4light-clean
make f4light BOARD=f4light_AirbotV2

at this point you have f4light_Revolution.apj in the same folder.

To flash using the bootloader you already have:
…/Tools/ardupilotwaf/px_uploader.py f4light_Revolution.apj

Now we have two options also for this cheap F4 boards.

You can do all this by cloning both from the ardupilot master branch and from the night_ghost fork, in this fork there is some additional works by night_ghost.


(Am) #80

Thanks anbello for posting this!! and also big thanks to the developers!!

Any chance ardupilot can work on new Matek F405-wing F4 board?