Propeller 2 Drone Discussion and MAVLink Parser
RbtsEvrywhr_Riley
Posts: 44
Robots Everywhere and MK Borri are back to putting propellers on propellers. It's been a while since NAVCOM 1.0, but we're moving along in the design phase of NAVCOM 2.0. As usual, this will be a multi-platform navigation and communication controller, similar to PixHawk and Ardupilot that will hopefully have some unique advantages.
For now, there's a MAVLink parser for y'all to play with.
https://obex.parallax.com/obex/mavlink-message-parser/
The idea is to use the P2's multiprocessing to our advantage and have a significant base of onboard sensors in lockstep, while still having cogs for companion processing. We're going to support standard companion architectures (canbus, i2c, spi, mavlink over serial) and are open to the community for more ideas.
Expect more development on NAVCOM and other P2 projects from us going forward. I'd say we're very much back.
Comments
Neat! Looking at the code the first thing that popped out was the CRC calculation in Spin2. One of my favorite features of the the P2 is inline assembly. You could, for example, use something like this to dramatically reduce the time required to calculate the CRC of a message.
pub calc_crc(p_src, len) : crc | b '' Calculate 16-bit CRC-16/MCRF4XX '' -- p_src is pointer to packet of bytes '' -- len is the length of the packet org bmask crc, #15 ' set to $FFFF loc pa, #\$8408 ' set pa to $8408 rdfast #0, p_src rep #5, len rfbyte b rev b setq b crcnib crc, pa crcnib crc, pa endThe output from this method matches the CRC-16/MCRF4XX selection from https://crccalc.com/ using the same data set.
This is includes a couple tricks from on of the forum PASM experts that made my assembly routine even faster. I'm sensitive to this because I ran into a problem several years ago using Spin1 to calculate the CRC of a control packet for a camera platform. Once we figured out that the CRC calculation time was creating an issue for our control loop, I converted the code to assembly -- luckily we had a spare cog to use in that project. What I love about the P2 is that we can run bits of assembly without having to invoke a whole cog. Not only does this give us speed, but opens up the world to the amazing new instructions in the P2 (like crcnib).
I haven't flown either of my drones (one is an Elev-8) in a long time -- will be fun to see if your project results in a new controller that could bring new life to the Elev-8 platform. Good luck -- this seems like a really great project.
Yeah, inline assembly to optimize the CRC calculation is a good idea. That was on the to-do list so thanks for that.
I don't remember what the weight of the hoverfly stack was. I'd have to dig one out and weigh it. Data sheet says 100g with the gps module, so probably around 80. So I think we can do that without any significant performance changes to an Elev-8
I still need to test and push the ASM version of the CRC check, but in the meantime I found a bug related to doubles being passed the wrong way which opened a huge can of worms finding several bugs in the generator and even one in mavgen-python. Fix coming to Obex shortly.