Bitcraze Forums

Posted: **Thu Aug 20, 2020 12:49 pm**

I'm experimenting with various methods.
I used DEBUG_PRINT to confirm that everything works well except the p2p callback function.
I'm using the example without modifying it at all, is there any part that I need to set up in the code?

Code: Select all

void p2pcallbackHandler(P2PPacket *p)
{
  uint8_t other_id = p->data[0];
  char msg[11];
  memcpy(&msg, &p->data[1], sizeof(msg));
  uint8_t rssi = p->rssi;
  DEBUG_PRINT("[RSSI: -%d dBm] Message from CF nr. %d, %s\n",rssi, other_id, msg);
}

void appMain()
{
  DEBUG_PRINT("Waiting for activation ...\n");

    // Initialize the p2p packet 
    static P2PPacket p_reply;
    p_reply.port=0x00;
    uint64_t address = configblockGetRadioAddress();
    uint8_t my_id =(uint8_t)((address) & 0x00000000ff);
    p_reply.data[0]=my_id;
    char str[11]="Hello World";
    memcpy(&p_reply.data[1], &str, sizeof(char)*6);
    p_reply.size=12;
    p2pRegisterCB(p2pcallbackHandler);

  while(1) {
    DEBUG_PRINT("working\n");
    vTaskDelay(M2T(2000));
    radiolinkSendP2PPacketBroadcast(&p_reply);
  }
}

I have a question here.
Is there no problem with my arbitrary port change in the p_reply.port=0x00; code within the appMain() function?
The radiolink.h file describes this port as "Header selecting channel and port."
Is this not related to the channel I specified in the cfclient?

Posted: **Thu Aug 20, 2020 2:56 pm**

I have another question.

Code: Select all

void appMain()
{
  DEBUG_PRINT("Waiting for activation ...\n");
    static P2PPacket p_reply;
    p_reply.port=0x00;
    uint64_t address = configblockGetRadioAddress();
    uint8_t my_id =(uint8_t)((address) & 0x00000000ff);
    p_reply.data[0]=my_id;
    char str[11]="Hello_world";
    memcpy(&p_reply.data[1], &str, sizeof(char)*6);
    p_reply.size=12;
    p2pRegisterCB(p2pcallbackHandler);

  while(1) {

    vTaskDelay(M2T(2000));
    radiolinkSendP2PPacketBroadcast(&p_reply);
  }
}

The string you want to send in this code is "Hello_world".
In this case, the size is char 6. <memcpy(&p_reply.data[1], &str, sizeof(char)*6);>
Only "hello" was printed in the results you showed me
Is this related to my failure?
If so, should the code below be modified as well?
< p_reply.size=12;>

I'm setting up various hypotheses compared to your result window.
If you know anything about this, please advise me.

Posted: **Thu Aug 20, 2020 6:39 pm**

alright, I will try my best to answer all these questiosn.

The port is not for selecting a channel. That is just to indicate what type of message it is, which is only necessary for between the crazyflie and the computer and not for p2p. 0x00 is just a value to initialize it.

it would be good to try things out for a little longer and see if there still questions at the end of the day, to ask them on this forum.

The size of the memcpy is indeed something that needs to be changed. It should be sizeof(char)*11. I will try to change it soon.

The callback will only work if the crazyflie actually receives an message.

I'm not sure what is actually happening, since it is working for us. Your crazyflie is sending but the other crazylfie is not receiving, eventhough they have exactly the same app layer program. Do you have by any chance a microbit in your possesion, or anything else with a NRF51 chip?

(btw. it would be good to try things out for a little longer and see if there still questions at the end of the day, to ask them on this forum, that keeps it a bit clearer what is solved and what remains.)

Posted: **Sun Aug 23, 2020 1:00 pm**

I'm sorry if my continued question interfered with you.
In fact, I've spent a lot of time doing this example, and I thought I couldn't solve it alone.
Nevertheless, thank you for your kind reply.
But even with your help, I couldn't solve the problem.
Here's the code I used.
I've revised a little bit about what I suspect, but I haven't succeeded.

Code: Select all


void p2pcallbackHandler(P2PPacket *p)
{
	//check crazyflie receive message
	DEBUG_PRINT("call_back_running\n");
  // Parse the data from the other crazyflie and print it
  uint8_t other_id = p->data[0];
  char msg[11];
  memcpy(&msg, &p->data[1], sizeof(msg));
  uint8_t rssi = p->rssi;
  DEBUG_PRINT("[RSSI: -%d dBm] Message from CF nr. %d, %s\n",rssi, other_id, msg);
}

void appMain()
{
  DEBUG_PRINT("Waiting for activation ...\n");
    static P2PPacket p_reply;
    p_reply.port=0x00;
    uint64_t address = configblockGetRadioAddress();
    uint8_t my_id =(uint8_t)((address) & 0x00000000ff);
    p_reply.data[0]=my_id;
    char str[11]="Hello_world";
    memcpy(&p_reply.data[1], &str, sizeof(char)*11);
    p_reply.size = sizeof(p_reply.data);
    p2pRegisterCB(p2pcallbackHandler);

  while(1) {

    vTaskDelay(M2T(2000));
    radiolinkSendP2PPacketBroadcast(&p_reply);
  }
}

If you don't mind, could you share the code that you succeeded in?
I can roughly understand the code in the example, but I didn't fully understand the entire radiolink.h/c files.
If I see a code that you've successfully executed, I think I'll be able to understand it more deeply by comparing it to a code that failed.

Posted: **Mon Aug 24, 2020 12:50 pm**

Hi,

You should not have to modify anything to get the P2P example to work. I tried to get it to work with 2 Crazyflies 2.1 and I got it working following this procedure:

I flashed both Crazyflies using the client bootloader screen to version 2020.06. This is to make sure that everything is updated and clean.
I set one Crazyflie to channel 80, address 0xE7E7E7E701 and the other one channel 80 address 0xE7E7E7E702

Then, in a terminal in an empty directory I did the following: (type/copy the commands starting with $, I also put the result where relevant so that you can see if your commands succeds)

Code: Select all

$ git clone https://github.com/bitcraze/crazyflie-firmware --recursive
(...)
Receiving objects: 100% (5702/5702), 6.52 MiB | 1.01 MiB/s, done.
Resolving deltas: 100% (3528/3528), done.
Submodule path 'vendor/libdw1000/vendor/cmock/vendor/c_exception/vendor/unity': checked out '47a778d606fbfabde459b0f725a67b18c1bce6ee'
Submodule path 'vendor/libdw1000/vendor/cmock/vendor/unity': checked out '33325f4a0bc0931823867b11241dff3c2a0b60b7'
Submodule path 'vendor/libdw1000/vendor/unity': checked out '7943c766b993c9a84e1f6661d2d2427f6f2df9d0'
Submodule path 'vendor/unity': checked out '287e076962ec711cd2bdf08364a8df9ce51e106b'

$ cd crazyflie-firmware/examples/app_peer_to_peer/

$ make -j$(nproc)
(...)
Build for the CF2 platform!
Build 59:f7b0222a3a17 (2020.06 +59) CLEAN
Version extracted from git
Crazyloader build!
Flash |  230320/1032192 (22%),  801872 free | text: 225188, data: 5132, ccmdata: 0
RAM   |   54780/131072  (42%),   76292 free | bss: 49648, data: 5132
CCM   |   62176/65536   (95%),    3360 free | ccmbss: 62176, ccmdata: 0

$ make cload CLOAD_ARGS="-w radio://0/80/E7E7E7E701"
(...)
Reset in firmware mode ...

$ make cload CLOAD_ARGS="-w radio://0/80/E7E7E7E702"
(...)
Reset in firmware mode ...

After that both Crazyflies are restarted and they both have M4 blinking red and green at regular interval. if only one Crazyflie is ON, M4 only blinks red to indicate a sent packet, when the other one is started there is also a green blinking to indicate a recevied packet.

Can you run this procedure unmodified and tell us if and where you encounter a discrepancy?

Posted: **Mon Aug 24, 2020 2:06 pm**

Thank you for your advice.
But other problems are still unresolved.

1. If there's nothing wrong with the code, I think other settings are the problem.
I connected to client, set the desired address value in configure 2.x, press the write button, then turn crazyflie-bolt off and on, then connected.
(Flash-Change Address-Check after connecting client)
Given that the red lead still shines briefly every two seconds, the code seems to be working normally, but it seems that they are not receiving each other's messages.

2. I think the crazyflie-bolt has the same firmware as crazyfly 2.1.
I don't doubt this part, but when I don't think exactly what's wrong, I start to doubt this part.
If you're sure that these two aren't different, I think I can stop thinking about these crazy things.
(This is the weird story that I thought we couldn't find an error.)

Posted: **Mon Aug 24, 2020 2:57 pm**

I do not understand your problems. In order to understand I would need you to follow exactly my procedure and to tell me where things starts going wrong.

My idea is to start from a completely clean state and run the same steps so that we can understand what is happening.

There should be no problem with the bolt, it will run the same firmware as the Crazyflie, and please note that after the first flashing of a stock firmware (using the client bootloader client) and setting the channel and address, you should restart the bolt once to set the address but that it all. The arguments I added to "make cload" in my procedure will automatically restart and flash each of your bolts if they are setup with the right address and channel.

To answer your points:
1. This does not look like the procedure I sent. Can you please flash the stock firmware with the client and then work on the console like I did. This way if something goes wrong you can copy-paste the error here.

2. The bolt will run the same firmware as Crazyflie 2.1. I just tested replacing one of my Crazyflie by a Bolt and it works fine. M4 does blink RED and GREEN at 1Hz indicating P2P communication.

Posted: **Mon Aug 24, 2020 3:51 pm**

After I saw your post, I went through the same process as the first one.
And finally, I got the following results.

Code: Select all

---
SYS: Crazyflie Bolt is up and running!
SYS: Build 59:f7b0222a3a17 (2020.06 +59) CLEAN
SYS: I am 0x20373347344D500E001D0027 and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
DECK_CORE: 0 deck(s) found
IMU: BMI088 Gyro SPI connection [OK].
IMU: BMI088 Accel SPI connection [OK]
IMU: BMP388 I2C connection [OK]
ESTIMATOR: Using Complementary (1) estimator
CONTROLLER: Using PID (1) controller
MTR-DRV: Using brushless motor driver
EEPROM: I2C connection [OK].
IMU: BMI088 gyro self-test [OK]
STAB: Wait for sensor calibration...
SYS: Free heap: 13216 bytes
Waiting for activation ...
STAB: Ready to fly.
[RSSI: -82 dBm] Message from C[RSSI: -81 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -81 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -81 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C[RSSI: -82 dBm] Message from C

I think this is why I haven't gotten the results I want.
I think the error occurred due to the continuous occurrence of the new callback.
Will these results be printed when you execute them?
I think it's too short a cycle for the callback function to be printed.
Does this also indicate the possibility of loss when sending a message?
Is there anything you would like to recommend as a way to solve this problem?

Posted: **Mon Aug 24, 2020 4:11 pm**

Hi,

I never looked at the console so far since I wanted to reach a working state, I just looked at the LEDs verifying the communication. It would have been useful if you could have at least verified that the M4 LED was indeed behaving the same as on my side. Anyway we seem to have reached the same point which is great!

As for the console, I have seen some sluggishness when connected with the Crazyflie client. I am assuming the client is making the radio a bit too busy. If so, the solution could be to slow-down a little bit the client communication loop.

When connecting with USB I see a message repeated at 1Hz (it is a bit ugly though, I think there is a bug in the console subsystem, we will look at that tomorrow):

Code: Select all

---
SYS: Crazyflie 2.1 is up and running!
SYS: Build 59:f7b0222a3a17 (2020.06 +59) CLEAN
SYS: I am 0x20393743484850170035003F and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
DECK_CORE: 0 deck(s) found
IMU: BMI088 Gyro I2C connection [OK].
IMU: BMI088 Accel I2C connection [OK]
IMU: BMP388 I2C connection [OK]
ESTIMATOR: Using Complementary (1) estimator
CONTROLLER: Using PID (1) controller
MTR-DRV: Using brushed motor driver
EEPROM: I2C connection [OK].
IMU: BMI088 gyro self-test [OK]
STAB: Wait for sensor calibration...
SYS: Free heap: 13224 bytes
Waiting for activation ...
[RSSI: -35 dBm] Message from CSTAB: Ready to fly.
[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C[RSSI: -35 dBm] Message from C
...

For the message printed in the middle. It is just that the log from the example is not printed completely and so it is missing a new line before "STAB: Ready to fly."

I do think the problem is more on the radio occupation side, than the RTOS side since it seems to work much better when connected though USB.

Can you confirm that when connecting via USB it continues communicating.

Posted: **Mon Aug 24, 2020 5:16 pm**

It seems that you have replaced your message after I sent my last message so my answer does not make sense anymore. Can you please put back the original message and post your new question in a new message. This way this thread will continue to make sense and I will be able to answer your new questions.

Bitcraze Forums

p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response

Re: p2p -no response