Blogs

Developer

What's up with original Ardupilot? (not APM)

Posted by Jason Short on November 20, 2010 at 11:00am
Hey everyone, I just wanted to catch everyone up with the state of the original Ardupilot (not APM!). I'm the only developer currently working on it and could use some help. I recently had a baby boy and between him, work and a small copter side project I've not been able to keep up with the code.

What needs to get done:
  • Maintain compatibility with the config tool. - don't mess too much with the EEPROM.
  • Move from our old GPS parsers to the newer and well maintained Libraries.
  • Add printf and <avr/pgmspace.h> to move Serial.print strings to ROM from RAM.
  • If possible add in CLI from Mega. (We're running low on ROM!)
  • Do anything to reduce, clean up code to free up ROM.
  • Anything else we can do to align, where possible, with Mega.
In the end these should be minor updates. I just can't get to them and flight test them.
Jason





E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer
    Jason Short November 25, 2010 at 10:32pm
    It's possible, but tricky. I did it with the iR sensors and GPS only. Maybe you could alter the IMU code to get the XBee into that? It's too much trouble in my mind though.
  • 3D Robotics
    Chris Anderson November 25, 2010 at 7:53am
    I don't see a good path to full duplex serial on ArduIMU. That what ArduPilotMega was designed for.
  • robert bouwens November 24, 2010 at 10:45pm
    hi jason,
    http://code.google.com/p/ardupilot/wiki/ArduIMU
    do you see a path to use the imu plus full duplex xbee support?
    robert
  • Chester November 24, 2010 at 4:03am
    // This hack is to control the V2 shield so we can read the serial from
    // the XBEE radios - which is not implemented yet
    void setGPSMux(void)
    {
    #if SHIELD_VERSION < 1 || GPS_PROTOCOL == 3 // GPS_PROTOCOL == 3 -> With IMU always go low.
    digitalWrite(7, LOW); //Remove Before Fly Pull Up resistor
    #else
    digitalWrite(7, HIGH); //Remove Before Fly Pull Up resistor
    #endif
    }


    void setCommandMux(void)
    {
    #if SHIELD_VERSION < 1
    digitalWrite(7, HIGH); //Remove Before Fly Pull Up resistor
    #else
    digitalWrite(7, LOW); //Remove Before Fly Pull Up resistor
    #endif
    }
    Hi, jason how about your boy?
    maybe you can update this part of the code, i think a lot of people need to use the xbee to transmit data during flight, so i think implemented this part is quite necessary.
  • robert bouwens November 22, 2010 at 10:25am
    thanks,
    it starts looking better - but when i see:
    /// GCS' are currently implemented inside the sketch and as such have
    /// access to all global state. The sketch should not, however, call GCS
    /// internal functions - all calls to the GCS should be routed through
    /// this interface (or functions explicitly exposed by a subclass).
    ///
    try to use the keywords abstract, protected and public.
    that makes clear what is callable form the outside world.
    only what is really need is 'public'.
    helps reading the source.

    robert
  • 3D Robotics
    Chris Anderson November 22, 2010 at 9:33am
    Robert: See the GPS class for example. All the different GPS modules are now sub-classes. (the stand-alone GPS libraries in that repository are legacy from older versions and will soon be removed)
  • robert bouwens November 22, 2010 at 9:29am
    @chris
    the world is unfair - to integrate hw you seperate them.

    i tried to find an absract class - i did not succeed.
    can you explain me where to find the class hierarchie?
    robert
  • KnutL November 22, 2010 at 4:49am
    Hi jason, I would like to help too.
    I can offer coding and/or testing. Its getting cold outside, so flight testing will be hard
    knut
  • 3D Robotics
    Chris Anderson November 21, 2010 at 12:03pm
    Robert: the whole point of the new library structure was to integrate all the code sets. Now each board/project (APM, ArduCopter, ArduIMU, others to come), has its own repository and project-specific main files, but they all share the same libraries for all the shared functions, such as GPS, DCM, GCS, RC, ADC, etc..

    Given how many Ardu* projects there are now, this is a minor miracle of organization. It's a great platform to add new boards and varieties without adding more code/organizational complexity.

    The original ArduPilot is the only code base we haven't ported to this new structure, which is why it's lagging in terms of development. Jason's request is that we get some help in bringing that up to the same standards as the others, and then it will be also be able to benefit from the core APM development like all the others.
  • dacian herbei November 21, 2010 at 11:32am
    if it is a mess there is no point bragging about it.
    Lets set the goals we want to achieve than the milestones and get to work.
This reply was deleted.