Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 14 03:51

    tridge on master

    Add override keyword to those m… (compare)

  • Aug 14 03:51
    tridge closed #16
  • Aug 14 01:37
    peterbarker opened #16
  • Aug 14 01:33

    peterbarker on override-keywords

    Add override keyword to those m… (compare)

  • Jun 06 00:11

    tridge on pr-header-conflict-ch

    (compare)

  • Jun 06 00:11

    tridge on master

    marshal: fixed header conflict … (compare)

  • Apr 19 12:42

    OXINARF on fix-python-37

    (compare)

  • Apr 19 12:41

    OXINARF on pr-STM32H7-support

    (compare)

  • Apr 19 12:38
    OXINARF closed #15
  • Apr 19 12:38

    OXINARF on master

    stm32: support ChibiOS kernel m… dsdl_compiler: add missing sheb… dsdl_compiler: remove trailing … and 1 more (compare)

  • Apr 18 18:30
    OXINARF opened #15
  • Apr 18 18:30
    OXINARF review_requested #15
  • Apr 18 18:22

    OXINARF on fix-python-37

    dsdl_compiler: add missing sheb… dsdl_compiler: remove trailing … dsdl_compiler: check for StopIt… (compare)

  • Feb 02 02:03

    tridge on pr-STM32H7-support

    stm32: support ChibiOS kernel m… (compare)

  • Aug 12 2018 14:12

    OXINARF on ardupilot-2018-06-09

    (compare)

  • Aug 12 2018 13:55

    OXINARF on pr-chibios-update

    (compare)

  • Aug 12 2018 13:55

    OXINARF on allow-can2-without-can1

    (compare)

  • Aug 12 2018 13:52

    OXINARF on master

    stm32: initiliaze CAN1 if neede… uavcan_stm32: add enable irq fl… (compare)

  • Aug 12 2018 12:39

    OXINARF on stm32-chibios-update

    (compare)

  • Aug 03 2018 14:22

    OXINARF on allow-can2-without-can1

    uavcan_stm32: add enable irq fl… (compare)

karu2003
@karu2003
Why compass on distance meter and more? CAN is external devices. Need a CAN compass - but not i2c compass over CAN. :)
patrickpoirier51
@patrickpoirier51
@karu2003 if I understand well, I2C over CAN allow to get acces to all existing drivers without having to duplicate and rewrite ?
Andrew Tridgell
@tridge
correct
and we can't fit all those drivers in a small (eg. STM32F103 64k) can node
so if you have a new i2c compass now, its a pretty significant engineering effort to create new fw for a can periphal
with i2c over can its just a matter of soldering it on
patrickpoirier51
@patrickpoirier51
Right and for most of users , it is like a ''magic bus extension' for I2c and Analog and Serial available NOW, without having to wait/overload the DEV Team
karu2003
@karu2003
It is not necessary. This greatly complicates the system. CAN is not designed for wires of 15 centimeters.
patrickpoirier51
@patrickpoirier51
@karu2003 We are talking about larger scale implementation like Plane and full scale vehicle like Boat , Rovers (lot of use case in the Mowers) and else
Andrew Tridgell
@tridge
@karu2003 what does it have to do with wire length??
and from users and developers pov, its a huge simplification
the system of custom can fw per sensor has been what we've tried for several years now. It has failed to gain significant traction, and drivers on the can peripherals have lagged behind badly
especially for things like GPS
but also for compass, airspeed, baro, lidar etc
the main downside is higher bus overhead
karu2003
@karu2003
It is for such applications that a systematic approach is needed, and not an I2C converter. Otherwise it will not be a system, but a set of many boards. We are doing it. It is expensive for a single chip to install a i2c converter.
Andrew Tridgell
@tridge
i2c is a service call, whereas MagneticField is a broadcast
@karu2003 why single chip? You can attach several i2c devices to one can node
I don't get what you mean by "not be a system" ....
anyway, you don't have to use it
I've done it as DSDL in the ardupilot vendor namespace
and we're not removing support for the existing method
but I expect sensors based on remote i2c over can will quickly become more common that existing can sensors
karu2003
@karu2003
And i2c is a single chip solution. He was coined for this.
patrickpoirier51
@patrickpoirier51
@tridge Having a CAN bus with daisy chained universal nodes (like those from jDrone) is the most appealing technology that most of us are waiting for years !!
I raise my hand as a beta tester and champion of this concept
Andrew Tridgell
@tridge
thanks Patrick, it will be a few days yet before ready for testing. I'm prototyping on the UC4H generic nodes, which I'm guessing you have some of, so should be easy for you to test. It's built on the hwdef.dat system, so easy to port to new boards
patrickpoirier51
@patrickpoirier51
Perfect and please note that the BeagleBone family is now CAN ready (Thanks to @karu2003 for helping on that one)
karu2003
@karu2003
No one is waiting for anything. Ardupilot already not half a year can not accept the PR to expand the CAN protocols. :) and so. :)
Andrew Tridgell
@tridge
which PR are you referring to?
karu2003
@karu2003
ArduPilot/ardupilot#9619 He is followed by others. But everything is worth it.
Andrew Tridgell
@tridge
@pavel-kirienko turns out there is still a TAO issue with libcanard generated headers. Decode of BeginFirmwareUpdate assumes the path buffer has a length prefix, whereas it looks like libuavcan doesn't add one (presumably because it is the last element)
The root_item parameter is used, but that is a bit of a misnomer I think
I don't think we should be caring if its at root of the msg tree, but instead caring if its last
Pavel Kirienko
@pavel-kirienko
yes, correct
the dsdl compiler for libcanard is flawed at best
I would recommend to avoid reliance on it until we've fixed it for UAVCAN v1.0
Andrew Tridgell
@tridge
it really needs a test suite similar to the one I did for mavlink where every msg is encoded and decoded and correct result checked. It uses random values for all fields.
Akshath-Singhal
@Akshath-Singhal
I dont know if this is the right place to ask this question, but can anyone help me send some information from an arduino to pixhawk?
Andrew Tridgell
@tridge
over what transport? If it isn't CAN, then this is indeed the wrong place to ask :-)
Akshath-Singhal
@Akshath-Singhal
The idea is to communicate the information received by arduino to pixhawk for use in a specific library. I am not sure where to begin and am looking for the easiest way to implement it.
Akshath-Singhal
@Akshath-Singhal
Can you guide me to any library which uses 2-way serial communication?
patrickpoirier51
@patrickpoirier51
@Akshath-Singhal you should start at the forum, take a look at this : https://discuss.ardupilot.org/t/mavlink-and-arduino-step-by-step/25566
Akshath-Singhal
@Akshath-Singhal
@patrickpoirier51 Thanks for the link.
Akshath-Singhal
@Akshath-Singhal
@patrickpoirier51 While the example provided by you provides detailed explanation of connecting arduino to pixhawk for requesting datastream, I was more interested in receiving data on pixhawk from arduino and storing it in a variable. Also, I would prefer to avoid using the mavlink protocol as I will have to add custom msgs for it. Can you share some info regarding handling the received serial msgs on pixhawk?
Francisco Ferreira
@OXINARF
@pavel-kirienko What path is expected for v0 to v1 transition? Will libuavcan support both?
patrickpoirier51
@patrickpoirier51
@Akshath-Singhal maybe you can ask on the general channel, someone might be interested to this type of project, generally we are encouraging using communications standards as you can receive support from others
Akshath-Singhal
@Akshath-Singhal
@patrickpoirier51 Sure. Thanks for the help though.
Pavel Kirienko
@pavel-kirienko

it really needs a test suite

@tridge this much is obvious, but it wouldn't really solve all of the problems of this implementation. It was quickly hacked together by a guy from Intel; it should be considered a proof-of-concept, not production-ready. We are probably going to rewrite it from scratch when the v1 update is out.

What path is expected for v0 to v1 transition? Will libuavcan support both?

@OXINARF v1 is not backward-compatible with v0, and implementations supporting both are not planned because of resource utilization considerations. At some point in the near future, ArduPilot will likely need to abandon support for v0 in favor of v1.