DEV call 31-Mar-2014 9pm PDT = 01-Apr-2014 0400 UTC
Craig Elder
Craig Elder
Allison, and Nick Joined this call, welcome : )
Discussion as to whether the Nick that joined may have been Saint Nicholas, wanting to use Piksi and OpenCV to assist with Deliveries : )
Droneapi
Most core behaviour is provided by MavProxy. Most high order stuff is done. Looking for feedback on the documentation in the Dev Wiki.
Talking about how to deliver the API… and MavProxy, for windows, to make it a simple install.
https://groups.google.com/forum/#!topic/drones-discuss/4Pb-LT-F-3Y
1.9 is out, need to get some testing of the low latency.
Mav tester is updated… a serial buffer was being overflowed in Linux which caused an error in how the packets were perceived to be faulting. This has been fixed. This has allowed for more efficient testing.
There are now more patches to be put in as we now have a good test suite.
Tridge also looked at the encryption Algorithm, but it will be too slow for our radios…..
We need hardware encryption…
Pulsed Light LIDAR update
Allison is giving an update on the LIDAR….. mic issues….
Has been working with Randy to get the pulsed light working on APM, and has been working on connecting over I2C on Pixhawk.
Asked if we need to add configuration options… answer was to say not until we find people need to configure these options… but it may be needed to do this for testing…..
It is communicating. She noted that PX4 and Pixhawk are different.
Tridge was saying that the I2C driver is not in HAL, but Allison wrote one.
Normally we write it in PX4 stack, then we share… it allows multiple busses… as we have multiple i2c busses.
So we need to make i2c API at the HAL to enumerate the correct bus numbers.
Allison, will look at how this is done on the MS Airspeed driver. Or the SF0X laser ranger…
Tridge was discussing the option of using an instance driver, so a quad could use 5 or 6 units for indoor navigation…
Allison will look at this….
Critical things here are that the timing of the I2C does not affect any Nav critical timings…
Spline Navigation
Has been test flown, there were some bugs, which have been fixed; it is flying smooth corners… Spline waypoints are in Beta mission planner. It even shows where the path will be. It gets quite interesting when mixing straight and spline points.
Spline always points in the direction it is flying.
Not sure if it will run in APM2…….. NEED TESTERS…………………………………
AP_Math may be a good place for these calculations
A102 (yaw correction?) is still being worked on but is temporarily resolved. As it is limited to 10 degree chunks. If a yaw error is passed when the copter is leaned right over… it causes major pitch errors, it pulls the nose up.
Throttle Assist
From Jason…. This combines an adjustment to the pilots throttle. When the throttle is in the middle, it will increase or decrease to assist in alt hold, but as the throttle moves away from the centre, it will just give actual throttle. So it’s not alt hold, it is assisted hold. More like a vertical velocity speed….
On by default in drift mode. Discussion will continue as to add this to other modes… so maybe in Alt, or hybrid.
Only 5 lines of code J very nice.
Parachute
Henry on DIY drones has been working on the release mechanism…. So now it needs to be supported. Either servo or relay. It comes with a tube with a big spring in place and this wire holds it down. A little steel wire holds it all together. A large current burns the wire… the unit is self-contained, has its own battery…
He needs a signal to go high to fire the parachute. Fires in 100ms, shoots the chute out like a gun.
https://groups.google.com/forum/#!topic/drones-discuss/4BuwCDWk1SI
This will support servos or relays. Will have a servo on/off position.
Discussion on pass-through of servo on copter….. Tridge is looking into this.
Tridge was wondering if AP_trigger could do this, rather than AP_parachute.
Discussion as to adding this to the failsafe’s…
Motors must be shut down. So this will change according to which motors shut down.
Must still work with Disarm? And logging must continue…
Maybe a generic lib…. With feeding of “parachute” or “water bottle” and act accordingly…
Looking at methods as to stop the chute going off in people’s faces. Maybe a physical pin?
Inflight reboot? May be a great time to pop the chute… need to get the RTC running with FRAM to check our previous state. Needs someone to fix the RTC….
Brownout?
We need someone who knows the STM level stuff to get this RTC stuff going….
Discussion as to when it could be enabled…
Discussion as to detecting a fall, if falling at x m/s… below x height, it should fire….
Discussion as to what is in the correct method is of release… on plane, drogue shuts etc…
Hybrid Mode
Next to be worked on…. This is from VR Brain, similar to DJI position hold. So when it is stationary, it’s like loiter, but when it is moving, it is like alt hold, or stabilise.
It will be its own mode, separate from Loiter.
There is a new tool in MP for visualising getting the calibration data….
The values that have come from Jonathans Compass work should help, as it is getting really good offset data.
When the new calibration comes into Mission planner, it will be a similar procedure, but the new graphic should help this to ensure all quadrants are covered.
Discussion as to the need to allow the calibration to go longer than 60 seconds… then space to complete etc…
Discussions as to whether the shape will be a complex shape or a simple ellipsoid based on what iron is nearby.
AP2 release Update
Bill and Mike did a release, new logging capability….
https://groups.google.com/forum/#!topic/drones-discuss/jUpDgmaehC8
The main
changes in this framework are:
- separation of GPS backend drivers (for
specific GPS sensors) and the
frontend driver that interfaces
with the rest of ArduPilot.
- much less memory wastage. It saves over
250 bytes of ram on APM2 for
example.
- the GPS object can now have MAVLink
parameters. For now it only has
the GPS type and the nav engine
setting, but we now have a framework
to support setting of elevation
masks, rates, SBAS enable/disable etc
etc.
- multiple GPS sensors are supported by
the one driver, using the same
"instance" model we use
for other sensors (compass, gyro, accel
etc). So we can now start adding
code to EKF and DCM to use two GPS
on the same vehicle, auto-switching
between them or using both sets
of data. So you can do
gps.velocity() to get the velocity from the
default GPS, or do gps.velocity(N)
to get the velocity from the Nth
GPS.
- it gets rid of the "pointer to
reference" stuff that made using the
GPS in other places in the code
harder
- the code is smaller, it is about 2.5k
less flash on APM2 for example
- better auto-detection code. It now
re-runs the detection code if the
GPS goes silent (which as a side
effect means you can unplug a uBlox
and plug in a MTK mid-flight and it
will detect the change
- much better non-blocking handling of
UART buffers
- removal of a lot of the redundant
attributes in the driver (eg. "fix"
and "status", which were
almost, but not quite, the same thing)
This will allow things like adding “accuracy fields” to each gps.
If both GPS’s are alive, it will use the most consistent GPS… similar to the Accel.
Suitable interface and units are a standard deviation error on Horizontal and vertical position errors.
It is possible to determine accuracy in the east vs north etc.
It will be up to the lib to determine which GPS to use.
Other features here could be that we could turn SBAS off in SD to test what will happen when flying in Australia for example.
Could be set to not give a 3D fix unless the GPS has a really good one with low HDOP etc….
Could set to not arm unless RTK is ready etc….
A future issue is to work out how to choose between good local positions vs good global positions.
The neo7 driver is now done and will work as a primary or backup gps.
EKF update
Refining Glitch protection… a hybrid between INav, and filters. A ring around the current position, if it goes outside of that, the data will not be fused…. The ring will then grow at a defined acceleration it will catch up with that and start fusing the data (or a timeout), this can cause a snapback..
Now Paul fuses an offset of estimated position to GPS reported, and it realigns to the offset, the offset then decays to zero. So this should stop the massive snap that is often caused when we reintegrate the gps data. (1m/s rate of decay...) max 100m offset…
Tridge suggested trying this in SITL, as Randy has a Glitch system in SITL that adds glitches.
Updated Logging… changed definitions …It now gives a number where 0=perfect, 1= fault threshold so users can check… there is position, velocity, height, magnetometer. 1 quick view will show how far away from tripping fault limits.
GPS changes have affected new EKF changes….
We discussed Jonathan’s flight which was quite scary… but unfortunately, logging was not enabled, so there is no real way of knowing what it was really doing.
Paul still needs to update the Wiki for the new message structure.
VRBrain
The Git tree is ready to merge into Master. It is a port on top of Nuttx, but does not use PX4 flight stack.
It now uses licences that are compatible with GPL.
VRBrain uses the Nuttx from Greg Nutt.
Gives support to Wi-Fi, mass storage
We will not be doing maintenance on the Nuttx for them; everything is isolated in the VRBrain Folder.
Once the review is completed, it will merge.
They use Nuttx directly, but we use a PX4 layer on Nuttx.
Randy wants to make sure that they submit small patches, not massive patches.
Emile Castelnuovo
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Randy Mackay
Emile,
It’s probably best that Tridge does the merge instead of me but I wanted to mention that it came up on the dev call last week how, in general, your latest batch of commits were very clean and organised. Thanks very much for that.
-Randy
Andrew Tridgell
I've just pushed your VRBrain AP_HAL/NuttX port into master. Thanks for
the great job you did of making the port clean, much appreciated!
I only found one issue in my review, which was in this patch:
https://github.com/VirtualRobotixItalia/ardupilot/commit/eed5faa32133525d03a55d28c3a4920c60e393c4
which changed AP_BoardConfig for all ports in a way that broke other
ports. I replaced it with this patch instead:
https://github.com/diydrones/ardupilot/commit/7fe4847b6c78fe094d4f0f3ff23e03d2513a2540
(you'll need to rebase to fix your repo)
Congratulations on the port!
Cheers, Tridge
Randy Mackay
Congrats to the VRBrain team! Welcome!
-Randy
Emile Castelnuovo
Thank you, it is a real honor to be officially part of the group.
I can't take all the glory for this, Roberto and his team especially Luca Micheletti were the main makers behind the Nuttix port. I still lack a lot in the RTOS area... but I was able to make the merge easy thanks to all the hours spent keeping us up to date. ;)
Tridge I can finally appreciate all the huge work you and others have done on the NuttX implementation.
The port still needs a bit of work, but the big part is done.
Randy and all, I truly admire all the progress you are doing in the code, that's getting better every day and hopefully I will have a little more time to help out.
Cheers,
Emile
Andrew Tridgell
We are really delighted to have the VRBrain in master now. I hope it
will save you a lot of time!
One thing I'd like to do is to be able to add the vrbrain port to the
Tools/scripts/build_all.sh test script so when we make major code
changes I can ensure the VRBrain port keeps working.
..... ok, after chatting with Emile on skype, that is done now
I'd also like to work out the procedure for pulling in changes. I
suggest that you create a for-merge branch in your ardupilot tree and
that you put changes you want into upstream into that branch. I'd prefer
that you only push VRBrain specific changes into that branch, changes
that add new general APM functionality should go as separate patches via
pull requests.
Then I will check your for-merge branch periodically, or you can ping me
via email or skype to go look for new patches to merge. You are the
maintainer of the VRBrain port, so I will accept changes from you that
only impact on the VRBrain port as long as they build, and don't have a
negative impact on the other ports. I won't test them myself, that will
be your job :-) So I'll assume that anything in for-merge has been
tested by you for VRBrain, and is ready for going into ardupilot master.
Please keep your for-merge branch rebased on ardupilot master as you add
things to it.
Thanks again for the port, and I look forward to working with you!
Cheers, Tridge
Roberto Navoni
thank you very much for your work , we are working to a lot of
improvment on nuttx as wifi support , virtual serial port for
comunication with module , advanced follow me device ,mass storage ,
ecc ecc i hope that this advanced feature will be welcome in the
community.
Best
Roberto Navoni
Craig Elder
Craig Elder
Mark Colwell
Andrew Tridgell
>
> https://github.com/VirtualRobotixItalia/ardupilot/commit/eed5faa32133525d03a55d28c3a4920c60e393c4
the change specific to VRBrain.
It is fixed in master now.
Cheers, Tridge