Building with GCC - success!

[wangyeee]

The instructions (https://docs.docker.com/engine/installation/windows/) to install Docker on Windows is more complex than install gcc tool chain and make utils. It even requires to check VT support of your CPU!! Also, if you want to invoke Docker from command-line, you need to edit PATH variable-- why not add gcc and make to PATH instead? And then you are ready to go.
I also noticed that Docker creates VirtualBox VM on Windows to "implement" LXC on Windows. Please correct me if I were wrong. If it is the case, why not create a well setup Linux development VM image and distribute it to everyone who is interested in compiling AQ himself? The TauLabs project is doing so: https://github.com/TauLabs/TauLabs/wiki ... al-machine

IMO the use of virtualization brings more problems than benefits to embedded debugging. Have you tried to debug in a Docker environment? How does the ST-Link or J Link debugger works with it? Is the driver working or not?

The last thing a newcomer wants is following steps seems very simple, but at last turned out to have lots of problems. It is far more frustrating than spend one day configuring dev env.

I've consulted with one friend who actually has Docker deployed in production. It is used to deploy some web-based applications, and I believe that is what Docker is designed for. In that scenario, Docker can solve dependencies issues like OS/AppServer or DB. So probably you could look into building AQ GCS with Docker. As we know, QGC requires several trouble making libs, e.g. the tts. It would be nice if these issues can be resolved.

[wangyeee]

[Max]

[Max]

[wangyeee]

[rput]

[JussiH]

I am not a developer, but setting up Crossworks was never a problem. I can only recommend that if you want a "easy" experience with building your own firmwares that you get the personal Crossworks license. Im sure it saved me a ton of hours and money to go with that - The 150 dollars was worth every cent for me, even if I dont "develop" as such

As Max says, there really is no "team"... ATM 1-2 people is doing all the work maintaining the code and building new features.

Autoquad is a project that requires some experience and patience and we do try our best to help everyone. But our ressources are very limited.

As for the waypoint limitation - its a question of RAM available - we are down to counting bytes there, so adding more waypoints is not a question of "just do it", since it could put us in a place where a memory overflow could happen.

Having said that, I am confident that a more permanent solution will emerge soon - most likely reading waypoints off the SD-card - which effectively will make the number of waypoints "unlimited".

[rput]

Good points Jussi. The firmware stops compiling at around 300 waypoints with a ccm error. Anyone has an idea about how much RAM is needed left unused?

We have done a considerable amount of tests and saw no negative side-effects from our waypoint change.

We are considered a commercial entity and as such would have to fork out a lot more than $150 for the Crossworks license

[JussiH]

Richard,

I hardly think you would get into trouble for using the personal license, but you do have a point there. If its just a question of compiling in an increased number of WP´s, I think that could be done with the makefile? (I never tried the makefile, since I have Crossworks ).

Max can answer in details about the RAM use. It probably also depends on which release version and if its Quatos or PID you are basing your build on. I have heard before about people compiling for up to 100 WP´s, but its not something I have tried personally.

Basically, If it works for you with the version you based from, then you are probably safe.

Jussi

[wangyeee]

The WP are placed in CCM of STM32 processor. For both M4 and AQ6, there is 64KB available. 40KB (defined in util.h) is reserved for fast heap which will be used by pid controller and kalman filter. The other 24KB is shared by various of components like imu, radio, telemetry, nav, etc. So to find out how much memory left, you should look into util.c with something like a debugger to check CCM usage. But IMO 300 WPs are too much, what kinds of complex mission requires so many WPs? 100 is probably enough in most cases, if you want more, you may consider adding another onboard computer which talks AQ via mavlink and upload WPs during mission. And telemetry like satcomm may be needed for that onboard computer.

Please correct me if my understanding regarding CCM usage is wrong.

Regards,
Ye