[rotorcraft] add traffic_info to rotorcraft #1509
Conversation
|
Enabling generation of get_macros for telemetry again will break support for multiple variable length arrays again, see #1385 |
| struct EcefCoor_i ecef_pos; | ||
| struct LlaCoor_i lla = {.lat = lat, .lon = lon, .alt = alt}; | ||
| ecef_of_lla_i(&ecef_pos, &lla); | ||
| the_acs[the_acs_id[id]].east = (float)ecef_pos.x * 100; |
There was a problem hiding this comment.
ecef.x is clearly not an east value, same for other parameters. This could be confusing in a future use. The structure should be probably extended to use proper position and speed formats.
|
How about this @flixr, only for printing macros, we just skip the fields after the variable length array. In the (far) future when it becomes necessary to read multiple arrays from a telemetry message onboard we can revisit this. How does that sound :) |
|
Another option: if the message is aligned without variable length array, use old macro style (maybe they even can be improved), if not, use a new type of macro to fill the data byte by byte. |
|
@gautierhattenberger would be great if you can resolve this together with @kirkscheper, I don't really have much time right now... |
|
@gautierhattenberger let me know what you would like me to do with this in the interim till the pprzlink is complete. I would like to get this included in master soon so we can get the drone2drone in there. I need to solve the merge conflict with datalink.c first btw... I would also like to start merging the rotorcraft and fixed wing datalink files btw. I was thinking of adding a subsystems/datalink/datalink.c file where all common datalink handling goes which then calls the firmware specific handling then the module datalink handling. This will reduce the maintenance and help get us to integrated firmware. I will do this in a different pull request though. |
|
@kirkscheper this is a tough question. PPRZLINK is almost ready, but since it is a big change, it would be nice to have a bit more feedback before merging. I still would like to do this soon to avoid blocking of developments like yours. There is no point in doing the job twice... |
|
So if you use the byte by byte approach as currently in the gen_messages then you don't need to align the telemetry messages but then you can't use multiple variable length arrays in the message. In the original traffic_info, the position was saved as the utm_pos - nav_pos0. The the modules that use this position just compare that difference with the ecef position from the state. Of course this isn't very accurate as you move far away from the initial reference frame and as the initial position of the utm frame isn't loaded into the rotorcraft firmware I can't do that. The benefit is that those modules can actually be used in rotorcraft if the utm frame position is loaded in (as far as I can see). ATM I am just using the full utm position of the intruder and computing the rotorcraft utm position using one of the api help functions. Alternatively, I can do the same hack as previously used by including the utm frame position or implement what you mentioned above. For now I am just trying to get it all working and along the way will try to find out what the most useful method is to receive and store all the required data. |
|
Hey guys, just pulled the pprzlink changes but the dl macros are not generated for the telemetry messages for decoding messages onboard. Is there any plan to change this? |
|
Yes, I want to improve the reading macros to work all the time with aligned data or not |
kirkscheper
force-pushed
the
d2d_messages
branch
from
5f02875 to
c891155
Compare
|
Alrighty, well I will change this pull request to only update the tracffic code to include the lla messages and to add it to rotorcraft. |
kirkscheper
changed the title
|
We need to improve this in the future, but for now I guess it is fine like this. @flixr do you agree ? |
- support aligned or non aligned data depending of the arch - will help air-to-air communications (#1509)
- support aligned or non aligned data depending of the arch - Define PPRZLINK_UNALIGNED_ACCESS to TRUE if the target CPU/MMU allows unaligned access. This is true for x86/64 and most recent ARM platforms (ARMv7, Cortex-A, Cortex-M3/4). Examples for targets WITHOUT unaligned access support: LPC21xx, Cortex-M0 - will help air-to-air communications (#1509)
- support aligned or non aligned data depending of the arch - Define PPRZLINK_UNALIGNED_ACCESS to TRUE if the target CPU/MMU allows unaligned access. This is true for x86/64 and most recent ARM platforms (ARMv7, Cortex-A, Cortex-M3/4). Examples for targets WITHOUT unaligned access support: LPC21xx, Cortex-M0 - will help air-to-air communications (#1509)
- support aligned or non aligned data depending of the arch - Define PPRZLINK_UNALIGNED_ACCESS to TRUE if the target CPU/MMU allows unaligned access. This is true for x86/64 and most recent ARM platforms (ARMv7, Cortex-A, Cortex-M3/4). Examples for targets WITHOUT unaligned access support: LPC21xx, Cortex-M0 - will help air-to-air communications (#1509)
Added drone to drone messaging to datalink.
Added ac traffic logging capability (TRAFFIC_INFO should be defined in airframe file).
Works with bluegiga (although I use a smaller message which isn't here yet)