Preload a trajectory in CF2 in firmware

[estrategico]

We are trying to load a trajectory in the CF via a firmware using the app.c functionality you used in IROS demo but get some errors in the compilation of the firmware.

Can you please explain us how to expose the functions globally. The error refers most to all the highlevel comander functions.

[arnaud]

Are you running the branch from iros or did you copy-paste only app.c in a more recent firmware?

Could you details a bit more what error you are getting and what is your environment (ie. OS, version of the compiler).

[estrategico]

OS is Ubuntu 18.04, we have a local version of the firmware but is the last version with a few changes in the size of the trajectories memory in the high level commander module.
this is a transcription of the message in terminal:

CLEAN_VERSION
VTMPL version.c
CC version.o
CC app.o
src/modules/src/app.c: In function 'appInit':
src/modules/src/app.c:127:3: error: implicit declaration of function 'commanderEnableHighLevel' [-Werror=implicit-function-declaration]
commanderEnableHighLevel(true);
^~~~~~~~~~~~~~~~~~~~~~~~
src/modules/src/app.c:128:3: error: implicit declaration of function 'crtpCommanderHighLevelDefineTrajectory'; did you mean 'crtpCommanderHighLevelGetSetpoint'? [-Werror=implicit-function-declaration]
crtpCommanderHighLevelDefineTrajectory(1, 0, sequence, sizeof(sequence));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
crtpCommanderHighLevelGetSetpoint
src/modules/src/app.c:130:3: error: implicit declaration of function 'resetLockData' [-Werror=implicit-function-declaration]
resetLockData();
^~~~~~~~~~~~~
src/modules/src/app.c: At top level:
src/modules/src/app.c:24:13: error: 'appTimer' used but never defined [-Werror]
static void appTimer(xTimerHandle timer);
^~~~~~~~
cc1: all warnings being treated as errors
tools/make/targets.mk:26: recipe for target 'app.o' failed
make[1]: *** [app.o] Error 1
Makefile:329: recipe for target 'build' failed
make: *** [build] Error 2

[tobias]

Just a quick question, where does app.c come from? Is there an app.h as well?

[estrategico]

Yes, i will atach it to the post, i am following this commit
https://github.com/bitcraze/crazyflie-f ... dd716c74c8

I make another changes following it, but i am still getting error messages

[estrategico]

Im now trying to preload the trajectory in memory following this branch
https://github.com/bitcraze/crazyflie-f ... e/lth-2019
but the LPS deck hangs on boot
Is the firmware hardcoded to CF2.1?
How can i modify this?

[kristoffer]

Hi!

The lth-2019 branch is hardcoded for the lighthouse deck. You can turn it off by uncommenting
https://github.com/bitcraze/crazyflie-f ... .c#L55-L57

Since you are flying with the LPS system you might want to use the PID controller instead of the Mellinger as well. If the CF flips this is probably the problem and you can change it by commenting out this line https://github.com/bitcraze/crazyflie-f ... /app.c#L37

Apart from that I think it should work with the LPS.

Note that in the lth-2019 version the CF takes off automatically as soon as it has a stable position estimate. It may be surprising from time to time

[estrategico]

Thank you Kristoffer for all your valuable help, I finally have success preloading the trajectory.
I have a new problem because the trajectory is to big, so if i assign a lot memory to the trajectory the firmware halts reporting that lack of memory for the app.c, but if i assign less the firmware builds successfully but the CF hangs on boot.

I Assign less memory to the FreeRTOS heap following this post
viewtopic.php?f=6&t=818&p=4728&hilit=memory+388#p4728

And disable some of the drivers of the decks that I'm not going to use and also reduce the steps of the trajectory and finally have the CF preloading the trajectory and responding to a python script playing the trajectory sequence.
But not the whole sequence we designed.

So Here are my questions:
Is there another strategy to increase the usable memory?
Is the trajectory using the memory 2 times one in the script and one in the trajectory memory?
Can i include in the firmware a file with the trajectory and have access to it afterwards by python script?
Is trajectory loaded in flash or in RAM memory?

[kristoffer]

Hi!

Is there another strategy to increase the usable memory?

Right now it looks like the trajectory is stored in RAM, in this array https://github.com/bitcraze/crazyflie-f ... evel.c#L84.
The High Level commander was added as a part of Crazy swarm and in their use case they up load trajectories via radio, so it makes sense.

I don't see any reason though why the trajectory data could not be used directly from flash. It should be possible to make a modification at https://github.com/bitcraze/crazyflie-f ... vel.c#L367 to use a pointer to an array with a trajectory instead if the pointer to RAM.

Is the trajectory using the memory 2 times one in the script and one in the trajectory memory?

If you do it the way it is implemented in the lth-2019 branch, the trajectory is stored in flash but copied to RAM in runtime. The copy in RAM is then used when flying.

Can i include in the firmware a file with the trajectory and have access to it afterwards by python script?

If you add an array with a trajectory, something like this:

Code: Select all

const float sequence[] = {
0.55,3.850187562676742e-11,-6.126680001583386e-07,0.034011535082562466,-0.0003930116221214229,-0.13617012073728407,-0.013475566231476182,0.13052917793131502,-0.04578980321072286,5.13033102278894e-11,-6.894694832263486e-07,2.7736466486255528e-05,0.09665022145136354,0.003058298046984803,-0.14597702960520773,0.025898651835890598,0.031816204956814045,0.6948075950058442,0.2683789944542717,0.023245728473115564,-0.010134659315685406,-0.00043890670824819824,0.00011480619184472054,3.331435279368211e-06,-6.413660347948354e-07,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,
...
};

it will be stored in flash. It is possible to add functionality to read it back with python, but it can not be modified "live" in the Crayzlife (since it is in flash).