peabody124

Since it seems like there is constantly a lot of demand for OpenPilot branded stuff, we have opened a cafepress store.  My g/f generously offered to manage it and is really looking for feedback on any products you'd like or alternative artwork.  Right now there is a lot of things and we'll be parsing it down based on what's popular.

http://www.cafepress.com/openpilot

All proceeds from the sales will go to support OpenPilot development.  We applied a 30% markup across the board, just to be transparent.

For suggestions or feedback PM kellums124

So I've been remiss taking so long to post about this, but I wanted to show off this test jig Jes made for testing the OP-ESC.  This goes so far above and beyond anything I hoped for and I think is a superb example how people can contribute in non-coding ways.






Basically now I can drop a populated board in, load code, run test routines and diagnostics, without having to solder up all the pins.

Anyone have any recommendations for longer range fixed wing planes?  I'm hoping for something that could hit 1 hour of airtime but doesn't cost an arm and leg.

I was thinking while we are undergoing heavy overhauls on the GCS we might want to take a minute to discuss coding practices on that side.  Whenever I go through it, it seems like there are 3 or 4 ways most things are done and that doesn't seem like good practice.

This currently exists: http://wiki.openpilo...CS Coding Guide but is quite spartan

Some things I would suggest adding:

1. Should we have some standard method of accessing the UAVObjectManager?  In the config gadget the superclass provides the getObjectManager() method which is good.  Perhaps this should be a method available to all plugins too or should we make it a utility function?

2. This is one I feel fairly strongly about - whenever possible one should use the getData/setData accessors instead of the getField etc dynamic accessors.  This makes what would be a runtime error into a compile time error which is always good.

3. When to check if an object exists.  For example if you call ObjectType::GetInstance(getObjectManager()) I recommend adding a Q_ASSERT(obj != NULL) afterwards so that we have a reliable crash in this case which points us to the offending code.  Transparently trying to return from errors creates quite unpredictable behavior.  However there is an argument for alternative strategies.

----

On a small aside, a cool project for someone to do would be a small python script that generates a stub for a new plugin.  This would be autogenerating all the files listed here http://wiki.openpilo...gin Development with the correct object name substituted in.  I always find making a new gadget is a solid hour of going through and carefully replacing lines etc

I was flying a 10 m box (also a 5th waypoint out at 40 m, but not shown in the video).  It's not perfect as you can see from the plots and also the oscillations on the downwind leg.  There was also 8 mph winds and this is far from being tuned all the way.  I have overo log too that I'm processing and will post later.