Dev Call May 22, 2017 2300 UTC

Intel Maker Faire Update

Copter

  • 3.5 Progress
  • Mastering Solo

General

  • Cube Hotfix

Issues


Attendee count (max): 29

09:03am - Copter with Randy
Still testing 3.5rc6
A number of issues but making progress
DSMx
Corruption on channels >10

Tx appears to only support 8 channels - so how is he getting >8?
Could be a decoding bug
Need to get a capture of the serial stream to debug
Smart batteries are returning zeroes instead of healthy
Probably a fix for 3.6
RPi crashing
Lucas looked and fixed it
LidarLite PWM interface not working

Copters flipping in Sports mode when on ground
Preliminary fix was to not update attitude targets when on ground
In acro the targets are reset if throttle is zero
Not in Sports
Leonard wants the targets to be able to move around
Sport mode shouldn’t allow a flip
Angle-limited
Soft lean angle
Doesn’t stop targets going beyond lean-angle-max
Tries to rotate the vehicle back to the lean angle instead
Leonard thinks this is what we should do

Autotune not holding position
Should probably only move the hold position when roll/pitch are modified rather than all of r/p/y/t
One-line patch coming from tridge
Going to look at increasing the waiting-for-level value
http://discuss.ardupilot.org/t/strange-auto-yaw-behavior-rc5-6
Fix gone wrong
Attempting to fix too-early-yawing behaviour
Change was to point along leash
Problems with waypoints-with-delay
ATM we will accelerate sideways towards the next waypoint….
Current-jumping issue
MP was showing current spikes
Probably an MP issue which has been fixed
Calibrating 1-shot ESCs

Should be fixed
There will probably be an -rc7 later this week
May release even with the DSMx issue
Need to get the user to verify the user doesn’t have the problem on 3.4.6
Hopefully have a release within 3 weeks

09:30am Tom and Maker Faire
Intel invited a bunch of Open Source people to share their booth at Maker Faire
IRLock
Rover with beacon on it
Copter using loiter above it
SLAM and visual tracking stuff with video back from Copter
2.4GHz was very, very busy
Nick (rover!), Carl, Jonathon, Mr Wurzbach, Jaime
Dan and Philip in absence
Friday, Saturday, Sunday
Probably 50,000 people at the Faire
Jaime did a road-to-MakerFaire
Flew to Dallas to do a conference
Drove over to Dan in Austin
Did some slam stuff
Met with Craig in Colorado
He’s been everywhere, man
Olivier did some blog entries with videos and pictures

A few small technical issues
A problem cropped up with the CAN ESCs which Philip is looking at
WiFi was a disaster
No live video streaming to level that was hoped for
5.8 might have been an option
But would probably been have clogged too
Tridge worked on Skid-steering
Demos like this show bugs nicely!
Brushed support on Rover
Unusual throttle control
Assumption that commanded output is proportional to RPM
This one was proportional to torque
Really high throttle output required to get it moving
Really high p and i gains on throttle
Aon’s robotics
Industrial drive motors
A lot of stuff to clean up and commit to master
LiteWare Lidar on copter worked really well
Tracked Rover really well
enRoute copter was quieter than normal!
Bigger props after the oops on the first day
Custom tether done by JC and Jeff on night before
24V tether
Worked really well
Voltage sense on power supply
2 beefy wires for current
2 signal lines which fed back the voltage from other end
~20A carried
Bit of fiddling initially due to trip-outs
Battery acting as a capacitor
Solo is 18A at 4S
Was great to see cooperation with intel on this
Intel products weren’t present except as ingredients in Maker projects!
Big thanks to Jaime
Jaime stepped up when Philip couldn’t and did a great job

  • small diversion into funding contribution of the month
    This would be a great contribution-of-the-month thing
    Intel gve us $12,000US
    Lots of personal funds went into this
    Jaime has a new company, “Element”
    Has a channel on YouTube
    Gene from Hex turned up at Maker Faire
    10,000 Cubes in wild
    About half in Chinese market!

09:46am - mastering Solo
Yaw response not correct in smartshots
Msg_mount_control copter yaw not responding to
Mav_cmd_do_mnt_control also not working
Pitch responds appropriately
Condition_yaw copter responds to perfectly
Issue is probably in the way ArduPilot is handling the mount control measure

Tones PR is in
Jaime has some fixes in the works for some LEDs
Reports are very positive on the master port for Solo!
No “incidents” recently!
Running quite smoothly
Hugh has some slew-rate code coming in
Work-around for the ground-lift HW bug
1-second restart delay on ESC when bug happens (if you are lucky)
Better to use a HW fix!
There are some other uses for this code in master apart from Solo
Really want Solo code in master!
Already seen how messy not staying with mainline is!

10:04am - bad Plane crash

Plane 3.7.1
Voltage drop
Power flags change
Overcurrent event
Probably a momentary short
NCR1860 batteries
RFD900 in use?
They can change their power consumption based on environment
Very high RSSI, so probably an RFD900
Noisier ADCs if you have RFD900s in use
Determination: hardware fault
Telem1 can’t supply the current required to run an RFD900
See Wiki for details

10:25am - cooking Cubes
Patch made to fix overheating issue in Cube
Duty cycle on IO board now time out
FMU-side we will hard-set the BRD_TYPE to cube
We can detect whether it is a Cube based on some pins on the IO chip
Other V3 builds will still run the blue LED OK since they aren’t detected as Cube
Cube will never run the blue LED as an LED (only as a heater)
Philip is very keen to know that people are running the correct code on the Cube
Having parameters copied from PH1 is not helpful!
Heater set to -1 allows board to infinitely heat
SB0000002 is coming for this one
FMUv3 detection is an important thing for a GCS to have
List created to help people know how to do that

10:34am - Luis

Get RSSI values from S.BUS
Another on tridge’s long list

10:38am - Rover issue for Grant

Armed state and safety state should be orthogonal
E.g. Arm when safety on
HEARTBEAT and MAV_SYS_STATUS does reflect this
Probably QGC display issue

10:49am - reboot-required parameters
NFC: Reboot required by amilcarlucas · Pull Request #6231 · ArduPilot/ardupilot · GitHub
Some are complicated in terms of needing reboots
Should document those that require reboots at any time

10:53am - Marvelmind x/y swapped?
Amilcar is sticking with GPS mode ATM rather than beacon mode
Update rate is too slow
Bit of a hack in place to move from an absolute position to a distance-from-beacon on place
Active work done for support on this hardware!

10:59am - AP_Baro long-term drift avoidance

Request for review
Is this appropriate given the EKF can already do long-term correction?
Discovered a few weeks ago that the EKF drifts the origin according to the GPS
Has the advantage that it can use the innovations it is getting rather than trusting the GPS height
Need Paul’s comments on this
There’s a PR in place to avoid drifting the EKF origin!
It surprised tridge and Randy
It also seemed to adjust location when it drifted the origin
Which is really surprising given that we drift the EKF origin for a reason!
Paul is happy enough for this to happen outside the EKF
From people’s recollection

11:06am - esp8266 boards from Jani
Jani is assembling boards
Tridge wants mavlink2 support

11:11am - Amilcar - validator on pymavlink?
E.g. units added
Only set of 40 units are possible, make sure user doesn’t mistype
Should be added to the pymavlink generator
Flag to generator for checking units