Planet LA

Syndicate content
Planet Linux Australia -
Updated: 1 week 3 days ago

Michael Still: Garran green strip

October 2, 2015 - 09:28
When I was a teenager my best mate lived in a house which backs onto this smallish reserve and we used to walk his dog here heaps. I had a few spare moments yesterday, so I was keen to do a quick explore and see what its like now. The short answer is that its still nice -- good terrain, nice mature trees, and a few geocaches. I think this one would be a good walk for cubs.


Interactive map for this route.

Tags for this post: blog pictures 20151001 photo canberra bushwalk

Categories: Aligned Planets

Stewart Smith: PAPR spec publicly available to download

October 1, 2015 - 15:26

PAPR is the Power Architecture Platform Reference document. It’s a short read at only 890 pages and defines the virtualised environment that guests run in on PowerKVM and PowerVM (i.e. what is referred to as ‘pseries’ platform in the Linux kernel).

As part of the OpenPower Foundation, we’re looking at ensuring this is up to date, documents KVM specific things as well as splitting out the bits that are common to OPAL and PAPR into their own documents.

Categories: Aligned Planets

Michael Still: Wandering around Curtin

September 30, 2015 - 17:28
I decided to go on a little walk on the way home from a work lunch and I don't regret it. This is a nice area, which I was exploring for geocaches. I probably wouldn't have come here at all, but it was the second part of the "Trees of Curtin" walk from Best Bush, Town and Village Walks in and around the ACT that I had done the first half of ages ago.

I am glad I came back for the second half -- to be honest I was pretty bored with the first half (a bike path beside a major road mostly), whereas this is much more like walking around in nature. The terrain is nice, no thistles, and plenty of horses. A nice afternoon walk overall.

Now back to reviewing Mitaka specs.


Interactive map for this route.

Tags for this post: blog pictures 20150930 photo canberra bushwalk

Categories: Aligned Planets

Michael Still: Second trail run

September 30, 2015 - 09:29
I went for my second trail run last night. This one was on much rockier terrain, and I ended up tweaking my right knee. I think that was related to the knee having to stabilize as I ran over uneven rocks. I'll experiment by finding a different less awkward trail to run and seeing what happens I suppose.

Interactive map for this route.

Tags for this post: blog canberra trail run

Related posts: First trail run; Chicken run; Update on the chickens; Boston; Random learning for the day

Categories: Aligned Planets

Arjen Lentz: Julian Burnside: What sort of country are we? | The Conversation

September 29, 2015 - 20:25
By our response to boat people since August 2001, we may have redefined our national character. This article is based on the 2015 Hamer Oration, delivered by Julian Burnside on September 28, 2015.
Categories: Aligned Planets

OpenSTEM: On Teaching Programming

September 29, 2015 - 11:30

Being involved with teaching young students to code, I have come to the tentative conclusion that many coding kids have not actually been taught programming. This has been going on for a while, so some of this cohort are now themselves teaching others.

I have noticed that many people doing programming actually lack many of the fundamental skills that would make their programs efficient, less buggy and even just functional.

A few years back, Esther Schindler wrote an article Old-school programming techniques you probably don’t miss (ComputerWorld, April 2009).

Naturally, many (most!) of the things described there are familiar to me, and it’s interesting to review them. But contrary to Esther, I still do apply some of those techniques – I don’t want to miss them, as they serve a very important purpose, in understanding as well as for producing better code. And I teach them to students.

Programming is about smartly applied laziness. Students are typically aghast when I use that word, which is exactly why I use it, but the point is that smartly applied laziness is not the same as slackness. It’s simply a juicy way of describing “efficient”.

Suppose you need to shift some buckets of water.  You could carry one bucket at a time, but you’ll quickly find that it’s hard on your arm and shoulders, as well as wasting the other arm you have. So we learn that if you have more than one bucket to shift, carrying only one bucket at a time is not the best way of going about it. Similarly, trying to carry three or more buckets is probably going to cost more time than it saves, as well as likely spilling water all over the place.

Thus, and this was of course worked out many centuries ago, carrying two buckets works best and is the most efficient as well as being quite comfortable – particularly when using a neat yet simple tool called a yoke (as pictured).

Inevitably, most kids will have at some time explored this issue themselves (perhaps while camping), and generally come to the same conclusion and insight. This is possible because the issue is fairly straightforward, and not obscured by other factors. In programming, things are not always so transparent.

Our modern programming tools (high-level languages, loose typing, visual programming, extensive APIs and libraries) enable us to have more convenience. But that convenience can only be applied judiciously when the programmer has the knowledge and skills required to make appropriate judgements. Without that, code can still be produced rapidly, but the results are not so good.

Some would say “good enough”, and that is somewhat true – when you have an abundance of computing power, memory and storage, what do a few bytes or cycles matter? But add together many of those inefficiencies, and it does become a rather dreadful mess. These days the luxury of abundance has become seriously abused. In our everyday life using laptops, smart-phones, tablets and other devices, we frequently encounter the consequences, and somehow regard it as “normal”. However, crashing apps (extreme case but very common) are not normal, and we should not regard any of this as good enough.

I see kids being taught to code using tools such as MIT’s Scratch. I reckon that’s fine as a tool, but in my observations so far the kids are only being shown how the system works. Some kids will have a natural knack for it and figure out how to do things properly, others will plod along and indeed get through by sheer determination, and some will give up – they might conclude that programming is not for them. I think that’s more than a pity. It’s wrong.

When you think about it, what’s actually happening… in natural language, do we just give a person a dictionary and some reference to grammar, and expect them to effectively use that language? We wouldn’t (well actually, it is what my French teachers did, which is why I didn’t pick up that language in school). And why would computer programming languages be different?

Given even a few fundamental programming techniques, the students become vastly more competent and effective and produce better code that actually works reliably. Is such understanding an optional extra that we don’t really care about, or should it be regarded as essential to the teaching?

I think we should set the bar higher. I believe that anyone learning programming should learn fundamentals of how and why a computer works the way it does, and the various techniques that make a computer program efficient and maintainable (among other attributes). Because programming is so much more than syntax.

Categories: Aligned Planets

OpenSTEM: NASA Confirms Signs of Water Flowing on Mars, Possible Niches for Life | NY Times

September 29, 2015 - 11:30

Dark narrow streaks, up to a few hundred yards long, are seen along many slopes on Mars including Garni Crater. The identification of waterlogged salts in these streaks fits with the idea that they are formed by the underground flow of briny water that wets the surface.

Categories: Aligned Planets

Michael Still: Old Joe and Goorooyarroo

September 29, 2015 - 10:29
Steve, Mel, Michael and I went for a walk to Old Joe trig yesterday. I hadn't been to Goorooyarroo at all before, and was quite impressed. The terrain is nice, with some steep bits as you get close to the border (its clear that the border follows the water catchment from a walk around here). Plenty of nice trees, not too many thistles, and good company. A nice morning walk.

We bush bashed to the trig straight up the side of the hill, and I think there were gentler (but longer) approaches available -- like for instance how we walked down off the hill following the fence line. That said, the bush bash route wasn't terrible and its probably what I'd do again.

I need to come back here and walk this border segment, that looks like fun. There are also heaps of geocaches in this area to collect.


Interactive map for this route.

Tags for this post: blog pictures 20150928 photo canberra bushwalk

Categories: Aligned Planets

OpenSTEM: UCI brain-computer interface enables paralyzed man to walk

September 28, 2015 - 13:30

Proof-of-concept study shows possibilities for mind-controlled technology.


In the preliminary proof-of-concept study, led by UCI biomedical engineer Zoran Nenadic and neurologist An Do, a person with complete paralysis in both legs due to spinal cord injury was able – for the first time – to take steps without relying on manually controlled robotic limbs.

So this is using brainwave-detecting technology to reconnect a person’s brain with part of their body. A very practical example of how science can (re)enable people, in this case give them back their freedom of mobility. That’s fantastic.

Complementary, Honda’s ASIMO robot research can enable people to walk with artificial legs.

Don’t think this is just something that happens in labs! The basic tech is accessible. I have a single sensor EEG headset here, and some years ago I did a demo at a conference entitled “look ma, no hands” where I controlled the slide advance of the presentation on my laptop by doing a “long blink”.

Categories: Aligned Planets

Sridhar Dhanapalan: Twitter posts: 2015-09-21 to 2015-09-27

September 28, 2015 - 01:27
Categories: Aligned Planets

BlueHackers: Interactive Self-Care Guide

September 27, 2015 - 13:20

Interesting find:

[…] interactive flow chart for people who struggle with self care, executive dysfunction, and/or who have trouble reading internal signals. It’s designed to take as much of the weight off of you as possible, so each decision is very easy and doesn’t require much judgement.

Some readers may find it of use. I think it’d be useful to have the source code for this available so that a broad group of people can tweak and improve it, or make personalised versions.

Categories: Aligned Planets

James Purser: New episode out this weekend

September 25, 2015 - 00:29

So I finally managed to catch up with Chris Arnade and have a chat about his Faces of Addiction project last friday night. I don't think I was at my best (but, after a year off and the interview being at 11pm I'm going to cut myself a little slack).

I'll be putting the episode out this weekend and will let everyone know when it's up.


Categories: Aligned Planets

OpenSTEM: Trolling Self-Driving Cars

September 24, 2015 - 19:29

XKCD’s Randall nails it beautifully, as usual…

sure you can code around this particular “attack vector”, but there are infinite possibilities… these are things we do have to consider along the way.

Categories: Aligned Planets

Michael Still: How we got to test_init_instance_retries_reboot_pending_soft_became_hard

September 24, 2015 - 17:28
I've been asked some questions about a recent change to nova that I am responsible for, and I thought it would be easier to address those in this format than trying to explain what's happening in IRC. That way whenever someone compliments me on possibly the longest unit test name ever written, I can point them here.

Let's start with some definitions. What is the difference between a soft reboot and a hard reboot in Nova? The short answer is that a soft reboot gives the operating system running in the instance an opportunity to respond to an ACPI power event gracefully before the rug is pulled out from under the instance, whereas a hard reboot just punches the instance in the face immediately.

There is a bit more complexity than that of course, because this is OpenStack. A hard reboot also re-fetches image meta-data, and rebuilds the XML description of the instance that we hand to libvirt. It also re-populates any missing backing files. Finally it ensures that the networking is configured correctly and boots the instance again. In other words, a hard reboot is kind of like an initial instance boot, in that it makes fewer assumptions about how much you can trust the current state of the instance on the hypervisor node. Finally, a soft reboot which fails (probably because the instance operation system didn't respond to the ACPI event in a timely manner) is turned into a hard reboot after libvirt.wait_soft_reboot_seconds. So, we already perform hard reboots when a user asked for a soft reboot in certain error cases.

Its important to note that the actual reboot mechanism is similar though -- its just how patient we are and what side effects we create that change -- in libvirt they both end up as a shutdown of the virtual machine and then a startup.

Bug 1072751 reported an interesting edge case with a soft reboot though. If nova-compute crashes after shutting down the virtual machine, but before the virtual machine is started again, then the instance is left in an inconsistent state. We can demonstrate this with a devstack installation:

    Setup the right version of nova cd /opt/stack/nova git checkout dc6942c1218279097cda98bb5ebe4f273720115d Patch nova so it crashes on a soft reboot cat - > /tmp/patch <<EOF > diff --git a/nova/virt/libvirt/ b/nova/virt/libvirt/ > index ce19f22..6c565be 100644 > --- a/nova/virt/libvirt/ > +++ b/nova/virt/libvirt/ > @@ -34,6 +34,7 @@ import itertools > import mmap > import operator > import os > +import sys > import shutil > import tempfile > import time > @@ -2082,6 +2083,10 @@ class LibvirtDriver(driver.ComputeDriver): > # is already shutdown. > if state == power_state.RUNNING: > dom.shutdown() > + > + # NOTE(mikal): temporarily crash > + sys.exit(1) > + > # NOTE(vish): This actually could take slightly longer than the > # FLAG defines depending on how long the get_info > # call takes to return. > EOF patch -p1 < /tmp/patch restart nova-compute inside devstack to make sure you're running the patched version... Boot a victim instance cd ~/devstack source openrc admin glance image-list nova boot --image=cirros-0.3.4-x86_64-uec --flavor=1 foo Soft reboot, and verify its gone nova list nova reboot cacf99de-117d-4ab7-bd12-32cc2265e906 sudo virsh list ...virsh list should now show no virtual machines running as nova-compute crashed before it could start the instance again. However, nova-api knows that the instance should be rebooting... $ nova list +--------------------------------------+------+---------+----------------+-------------+------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+------+---------+----------------+-------------+------------------+ | cacf99de-117d-4ab7-bd12-32cc2265e906 | foo | REBOOT | reboot_started | Running | private= | +--------------------------------------+------+---------+----------------+-------------+------------------+ start nova-compute again, nova-compute detects the missing instance on boot, and tries to start it up again... sg libvirtd '/usr/local/bin/nova-compute --config-file /etc/nova/nova.conf' \ > & echo $! >/opt/stack/status/stack/; fg || \ > echo "n-cpu failed to start" | tee "/opt/stack/status/stack/n-cpu.failure" [...snip...] Traceback (most recent call last): File "/opt/stack/nova/nova/conductor/", line 444, in _object_dispatch return getattr(target, method)(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/", line 213, in wrapper return fn(self, *args, **kwargs) File "/opt/stack/nova/nova/objects/", line 728, in save columns_to_join=_expected_cols(expected_attrs)) File "/opt/stack/nova/nova/db/", line 764, in instance_update_and_get_original expected=expected) File "/opt/stack/nova/nova/db/sqlalchemy/", line 216, in wrapper return f(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/oslo_db/", line 146, in wrapper ectxt.value = e.inner_exc File "/usr/local/lib/python2.7/dist-packages/oslo_utils/", line 195, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/usr/local/lib/python2.7/dist-packages/oslo_db/", line 136, in wrapper return f(*args, **kwargs) File "/opt/stack/nova/nova/db/sqlalchemy/", line 2464, in instance_update_and_get_original expected, original=instance_ref)) File "/opt/stack/nova/nova/db/sqlalchemy/", line 2602, in _instance_update raise exc(**exc_props) UnexpectedTaskStateError: Conflict updating instance cacf99de-117d-4ab7-bd12-32cc2265e906. Expected: {'task_state': [u'rebooting_hard', u'reboot_pending_hard', u'reboot_started_hard']}. Actual: {'task_state': u'reboot_started'}

So what happened here? This is a bit confusing because we asked for a soft reboot of the instance, but the error we are seeing here is that a hard reboot was attempted -- specifically, we're trying to update an instance object but all the task states we expect the instance to be in are related to a hard reboot, but the task state we're actually in is for a soft reboot.

We need to take a tour of the compute manager code to understand what happened here. nova-compute is implemented at nova/compute/ in the nova code base. Specifically, ComputeVirtAPI.init_host() sets up the service to start handling compute requests for a specific hypervisor node. As part of startup, this method calls ComputeVirtAPI._init_instance() once per instance on the hypervisor node. This method tries to do some sanity checking for each instance that nova thinks should be on the hypervisor:

  • Detecting if the instance was part of a failed evacuation.
  • Detecting instances that are soft deleted, deleting, or in an error state and ignoring them apart from a log message.
  • Detecting instances which we think are fully deleted but aren't in fact gone.
  • Moving instances we thought were booting, but which never completed into an error state. This happens if nova-compute crashes during the instance startup process.
  • Similarly, instances which were rebuilding are moved to an error state as well.
  • Clearing the task state for uncompleted tasks like snapshots or preparing for resize.
  • Finishes deleting instances which were partially deleted last time we saw them.
  • And finally, if the instance should be running but isn't, tries to reboot the instance to get it running.

It is this final state which is relevant in this case -- we think the instance should be running and its not, so we're going to reboot it. We do that by calling ComputeVirtAPI.reboot_instance(). The code which does this work looks like this:

    try_reboot, reboot_type = self._retry_reboot(context, instance) current_power_state = self._get_power_state(context, instance) if try_reboot: LOG.debug("Instance in transitional state (%(task_state)s) at " "start-up and power state is (%(power_state)s), " "triggering reboot", {'task_state': instance.task_state, 'power_state': current_power_state}, instance=instance) self.reboot_instance(context, instance, block_device_info=None, reboot_type=reboot_type) return [...snip...] def _retry_reboot(self, context, instance): current_power_state = self._get_power_state(context, instance) current_task_state = instance.task_state retry_reboot = False reboot_type = compute_utils.get_reboot_type(current_task_state, current_power_state) pending_soft = (current_task_state == task_states.REBOOT_PENDING and instance.vm_state in vm_states.ALLOW_SOFT_REBOOT) pending_hard = (current_task_state == task_states.REBOOT_PENDING_HARD and instance.vm_state in vm_states.ALLOW_HARD_REBOOT) started_not_running = (current_task_state in [task_states.REBOOT_STARTED, task_states.REBOOT_STARTED_HARD] and current_power_state != power_state.RUNNING) if pending_soft or pending_hard or started_not_running: retry_reboot = True return retry_reboot, reboot_type

So, we ask ComputeVirtAPI._retry_reboot() if a reboot is required, and if so what type. ComputeVirtAPI._retry_reboot() just uses nova.compute.utils.get_reboot_type() (aliased as compute_utils.get_reboot_type) to determine what type of reboot to use. This is the crux of the matter. Read on for a surprising discovery!

nova.compute.utils.get_reboot_type() looks like this:

    def get_reboot_type(task_state, current_power_state): """Checks if the current instance state requires a HARD reboot.""" if current_power_state != power_state.RUNNING: return 'HARD' soft_types = [task_states.REBOOT_STARTED, task_states.REBOOT_PENDING, task_states.REBOOTING] reboot_type = 'SOFT' if task_state in soft_types else 'HARD' return reboot_type

So, after all that it comes down to this. If the instance isn't running, then its a hard reboot. In our case, we shutdown the instance but haven't started it yet, so its not running. This will therefore be a hard reboot. This is where our problem lies -- we chose a hard reboot. The code doesn't blow up until later though -- when we try to do the reboot itself.

    @wrap_exception() @reverts_task_state @wrap_instance_event @wrap_instance_fault def reboot_instance(self, context, instance, block_device_info, reboot_type): """Reboot an instance on this host.""" # acknowledge the request made it to the manager if reboot_type == "SOFT": instance.task_state = task_states.REBOOT_PENDING expected_states = (task_states.REBOOTING, task_states.REBOOT_PENDING, task_states.REBOOT_STARTED) else: instance.task_state = task_states.REBOOT_PENDING_HARD expected_states = (task_states.REBOOTING_HARD, task_states.REBOOT_PENDING_HARD, task_states.REBOOT_STARTED_HARD) context = context.elevated()"Rebooting instance"), context=context, instance=instance) block_device_info = self._get_instance_block_device_info(context, instance) network_info = self.network_api.get_instance_nw_info(context, instance) self._notify_about_instance_usage(context, instance, "reboot.start") instance.power_state = self._get_power_state(context, instance) [...snip...]

And there's our problem. We have a reboot_type of HARD, which means we set the expected_states to those matching a hard reboot. However, the state the instance is actually in will be one correlating to a soft reboot, because that's what the user requested. We therefore experience an exception when we try to save our changes to the instance. This is the exception we saw above.

The fix in my patch is simply to change the current task state for an instance in this situation to one matching a hard reboot. It all just works then.

So why do we decide to use a hard reboot if the current power state is not RUNNING? This code was introduced in this patch and there isn't much discussion in the review comments as to why a hard reboot is the right choice here. That said, we already fall back to a hard reboot in error cases of a soft reboot inside the libvirt driver, and a hard reboot requires less trust of the surrounding state for the instance (block device mappings, networks and all those side effects mentioned at the very beginning), so I think it is the right call.

In conclusion, we use a hard reboot for soft reboots that fail, and a nova-compute crash during a soft reboot counts as one of those failure cases. So, when nova-compute detects a failed soft reboot, it converts it to a hard reboot and trys again.

Tags for this post: openstack reboot nova nova-compute

Related posts: One week of Nova Kilo specifications; Specs for Kilo; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Juno Nova PTL Candidacy; Juno nova mid-cycle meetup summary: scheduler; Juno nova mid-cycle meetup summary: ironic

Categories: Aligned Planets

BlueHackers: Suicide doesn’t take away the pain, it gives it to someone else

September 24, 2015 - 15:21

This is something that I feel quite strongly about. Both of my parents have tried to commit suicide when I was young, at different times and stages of my life. The first one was when I was about 11 and I don’t remember too much about it, there was a lot of pain flying around the family at that time and I was probably shielded from the details. The second parent (by then long divorced from the other parent) tried when I was 21 and away at uni in a different city. That one I remember vividly, even though I wasn’t there.

My reactions to the second were still those of a child. Perhaps when it’s a parent, one’s reactions are always those of a child. For me the most devastating thought was a purely selfish one (as fits a child) “Do I mean that little to them? Am I not even worth staying alive for?” The pain of that thought was overwhelming.

At the time I was young, saw myself as an optimist and simply could not relate in any way to the amount of pain that would bring one to such an action. I was angry. I described suicide as “the most selfish act anyone could do”.

Now decades of time and a world of life experience later, I have stared into that dark abyss myself and I know the pain that leads one there. I know how all-encompassing the pain and darkness seems and how the needs of others fade. An end to the pain is all one wants and it seems inconceivable that one’s life has any relevance any more. In fact, one can even argue to oneself that others would be better off without one there.

In those dark times it was the certain knowledge of that pain I had experienced myself as one (almost) left behind that kept me from that road more firmly than anything else. By then I was a parent myself and there was just no way I was going to send my children the message that they meant so little to me they were not even worth living for.  Although living seemed to be the hardest thing I could do, there was no hesitation that they were worth it.

And beyond the children there are always others. Others who will be affected by a suicide, no matter of whom. None of us is truly alone. We all have parents, we may have siblings. Even if all our family is gone and we feel we have no friends, it is likely that there are people who care. The person at the corner shop from whom you buy milk on weekends and who may think “should I have known? Is there anything I could have done?” Even if you can argue that there is no-one that would notice or care, let’s be frank, someone is going to have to deal with the body and winding up of financial and other affairs. And I’m sure it’s really going to make their day!

Whenever I hear about trains being delayed because of incidents on the track I am immediately concerned for those on the train, not least of all the drivers. What have they ever done to that person to deserve the images that will now be impossible to erase from memory, which will haunt their nights and dark moments and which may lead them to require therapy.

There are many people, working for many organisations, some sitting at telephones in shifts 24 hrs a day, who want more than anything else to help people wrestling with these dark issues. They care. They really do. About everyone.

Help is always available. So let’s all acknowledge that suicide Always causes pain to others.

Need help?
Categories: Aligned Planets

Tridge on UAVs: APM:Plane 3.4.0 released

September 24, 2015 - 12:32

The ArduPilot development team is proud to announce the release of version 3.4.0 of APM:Plane. This is a major release with a lot of changes so please read the notes carefully!

First release with EKF by default

This is the also the first release that enables the EKF (Extended Kalman Filter) for attitude and position estimation by default. This has been in development for a long time, and significantly improves flight performance. You can still disable the EKF if you want to using the AHRS_EKF_USE parameter, but it is strongly recommended that you use the EKF. Note that if an issue is discovered with the EKF in flight it will automatically be disabled and the older DCM system will be used instead. That should be very rare.

In order to use the EKF we need to be a bit more careful about the setup of the aircraft. That is why in the last release we enabled arming and pre-arm checks by default. Please don't disable the arming checks, they are there for very good reasons.

Last release with APM1/APM2 support

This will be the last major release that supports the old APM1/APM2 AVR based boards. We have finally run out of flash space and memory. In the last few releases we spent quite a bit of time trying to squeeze more and more into the small flash space of the APM1/APM2, but it had to end someday if ArduPilot is to continue to develop. I am open to the idea of someone else volunteering to keep doing development of APM1/APM2 so if you have the skills and inclination do please get in touch. Otherwise I will only do small point release changes for major bugs.

Even to get this release onto the APM1/APM2 we had to make sacrifices in terms of functionality. The APM1/APM2 release is missing quite a few features that are on the Pixhawk and other boards. For example:

  • no rangefinder support for landing
  • no terrain following
  • no EKF support
  • no camera control
  • no CLI support
  • no advanced failsafe support
  • no HIL support (sorry!)
  • support for far fewer GPS types

that is just the most obvious major features that are missing on APM1/APM2. There are also numerous other smaller things where we need to take shortcuts on the APM1/APM2. Some of these features were

available on older APM1/APM2 releases but needed to be removed to allow us to squeeze the new release onto the board. So if you are happy with a previous release on your APM2 and want a feature that is in that older release and not in this one then perhaps you shouldn't upgrade.

PID Tuning

While most people are happy with autotune to tune the PIDs for their planes, it is nice also to be able to do fine tuning by hand. This release includes new dataflash and mavlink messages to help with that

tuning. You can now see the individual contributions of the P, I and D components of each PID in the logs, allowing you to get a much better picture of the performance.

A simple application of this new tuning is you can easily see if your trim is off. If the Pitch I term is constantly contributing a signifcant positive factor then you know that ArduPilot is having to

constantly apply up elevator, which means your plane is nose heavy. The same goes for roll, and can also be used to help tune your ground steering.

Vibration Logging

This release includes a lot more options for diagnosing vibration issues. You will notice new VIBRATION messages in MAVLink and VIBE messages in the dataflash logs. Those give you a good idea of your

(unfiltered) vibration levels. For really detailed analysis you can setup your LOG_BITMASK to include raw logging, which gives you every accel and gyro sample on your Pixhawk. You can then do a FFT on the

result and plot the distribution of vibration level with frequency. That is great for finding the cause of vibration issues. Note that you need a very fast microSD card for that to work!

Rudder Disarm

This is the first release that allows you to disarm using the rudder if you want to. It isn't enabled by default (due to the slight risk of accidentially disarming while doing aerobatics). You can enable it

with the ARMING_RUDDER parameter by setting it to 2. It will only allow you to disarm if the autopilot thinks you are not flying at the time (thanks to the "is_flying" heuristics from Tom Pittenger).

More Sensors

This release includes support for a bunch more sensors. It now supports 3 different interfaces for the LightWare range of Lidars (serial, I2C and analog), and also supports the very nice Septentrio RTK

dual-frequency GPS (the first dual-frequency GPS we have support for). It also supports the new "blue label" Lidar from Pulsed Light (both on I2C and PWM).

For the uBlox GPS, we now have a lot more configurability of the driver, with the ability to set the GNSS mode for different constellations. Also in the uBlox driver we support logging of the raw carrier phase and pseudo range data, which allows for post-flight RTK analysis with raw-capable receivers for really accurate photo missions.

Better Linux support

This release includes a lot of improvements to the Linux based autopilot boards, including the NavIO+, the PXF and ERLE boards and the BBBMini and the new RasPilot board. If you like the idea of flying

with Linux then please try it out!

On-board compass calibrator

We also have a new on-board compass calibrator, which also adds calibration for soft iron effects, allowing for much more accurate compass calibration. Support for starting the compass calibration in the

various ground stations is still under development, but it looks like this will be a big improvement to compass calibration.

Lots of other changes!

The above list is just a taste of the changes that have gone into this release. Thousands of small changes have gone into this release with dozens of people contributing. Many thanks to everyone who helped!

Other key changes include:

  • fixed return point on geofence breach
  • enable messages for MAVLink gimbal support
  • use 64 bit timestamps in dataflash logs
  • added realtime PID tuning messages and PID logging
  • fixed a failure case for the px4 failsafe mixer
  • added DSM binding support on Pixhawk
  • added ALTITUDE_WAIT mission command
  • added vibration level logging
  • ignore low voltage failsafe while disarmed
  • added delta velocity and delta angle logging
  • fix LOITER_TO_ALT to verify headings towards waypoints within the loiter radius
  • allow rudder disarm based on ARMING_RUDDER parameter
  • fix default behaviour of flaps
  • prevent mode switch changes changing WP tracking
  • make TRAINING mode obey stall prevention roll limits
  • disable TRIM_RC_AT_START by default
  • fixed parameter documentation spelling errors
  • send MISSION_ITEM_REACHED messages on waypoint completion
  • fixed airspeed handling in SITL simulators
  • enable EKF by default on plane
  • Improve gyro bias learning rate for plane and rover
  • Allow switching primary GPS instance with 1 sat difference
  • added NSH over MAVLink support
  • added support for mpu9250 on pixhawk and pixhawk2
  • Add support for logging ublox RXM-RAWX messages
  • lots of updates to improve support for Linux based boards
  • added ORGN message in dataflash
  • added support for new "blue label" Lidar
  • switched to real hdop in uBlox driver
  • improved auto-config of uBlox
  • raise accel discrepancy arming threshold to 0.75
  • improved support for tcp and udp connections on Linux
  • switched to delta-velocity and delta-angles in DCM
  • improved detection of which accel to use in EKF
  • improved auto-detections of flow control on pixhawk UARTs
  • Failsafe actions are not executed if already on final approach or land.
  • Option to trigger GCS failsafe only in AUTO mode.
  • added climb/descend parameter to CONTINUE_AND_CHANGE_ALT
  • added HDOP to uavcan GPS driver
  • improved sending of autopilot version
  • prevent motor startup with bad throttle trim on reboot
  • log zero rangefinder distance when unhealthy
  • added PRU firmware files for BeagleBoneBlack port
  • fix for recent STORM32 gimbal support
  • changed sending of STATUSTEXT severity to use correct values
  • added new RSSI library with PWM input support
  • fixed MAVLink heading report for UAVCAN GPS
  • support LightWare I2C rangefinder on Linux
  • improved staging of parameters and formats on startup to dataflash
  • added new on-board compass calibrator
  • improved RCOutput code for NavIO port
  • added support for Septentrio GPS receiver
  • support DO_MOUNT_CONTROl via command-long interface
  • added CAM_RELAY_ON parameter
  • moved SKIP_GYRO_CAL functionality to INS_GYR_CAL
  • added detection of bad lidar settings for landing

Note that the documentation hasn't yet caught up with all the changes in this release. We are still working on that, but meanwhile if you see a feature that interests you and it isn't documented yet then please ask.

Categories: Aligned Planets

David Rowe: SNR and Eb/No Worked Example

September 24, 2015 - 09:29

German Hams Helmut and Alfred have been doing some fine work with FreeDV 700B at power levels as low as 50mW and SNRs down to 0dB over a 300km path. I thought it might be useful to show how SNR relates to Eb/No and Bit Error Rate (BER). Also I keep having to work this out myself on scraps of paper so nice to get it written down somewhere I can Google.

This plot shows the Eb/No versus BER for of a bunch of modems and channels. The curves show how much (Eb/No) we need for a certain Bit Error Rate (BER). Click for a larger version.

The lower three curves show the performance of modems in an AWGN channel – a channel that just has additive noise (like a very slow fading HF channel or VHF). The Blue curve just above the Red (ideal QPSK) is the cohpsk modem in an AWGN channel. Time for some math:

The energy/bit Eb = power/bit rate = S/Rb. The total noise the demod sees is No (noise power in 1Hz) multiplied by the bandwidth B, so N=NoB. Re-arranging a bit we get:

    SNR = S/N = EbRb/NoB

or in dB:

    SNR(db) = Eb/No(dB) + 10log10(Rb/B)

So for FreeDV 700B, the bit rate Rb = 700, B = 3000 Hz (for SNR in a 3000Hz bandwidth) so we get:

    SNR = Eb/No – 6.3

Now, say we need a BER of 2% or 0.02 for speech, the lower Blue curve says we need an Eb/No = 4dB, so we get:

    SNR = 4 – 6.3 = -2.3dB

So if the modem is working down to “just” 0dB we are about 2dB worse than theoretical. This is due to the extra bandwidth taken by the pilot symbols (which translates to 1.5dB), some implementation “loss” in the sync algorithms, and non linearities in the system.

I thought it worth explaining this a little more. These skills will be just as important to people experimenting with the radios of the 21st century as Ohms law was in the 20th.

Categories: Aligned Planets

Sridhar Dhanapalan: Twitter posts: 2015-08-03 to 2015-08-09

August 10, 2015 - 01:27
Categories: Aligned Planets

David Rowe: Advanced VHF Digital Radio using Codec 2

August 9, 2015 - 13:30

Justin, VK7TW, has published a video of my recent presentation at Gippstech, which was held in July 2015. Good summary of FreeDV, the SM1000, and the exciting possibilities for VHF Digital Voice. Thanks Justin! Here are the Open Office slides of the presentation.

Categories: Aligned Planets

James Purser: An Open Letter to Prime, WIN and Southern Cross

August 8, 2015 - 01:31

So, you've decided to launch a campaign to "Save our voices" to try and "rescue" regional voices in news and current affairs.

That's nice and all, but what exactly are you proposing here?

I mean seriously, what do you think it will take to "rescue" an industry that has essentially been left to rot because the people in charge have completely missed the biggest shift in media consumption since the advent of the radio?

If you really want to "Save our voices" and ensure that regional Australia still has access to regional news, then may I suggest that the first thing you do is hire someone who knows something about the internet, someone who understands that the world has moved on and that if companies like WIN and Prime want to survive, then they're going to have to compete with not only the Netflixs and Youtubes, but their own content partners.

Demanding that the government relax media ownership laws or any other sort of government intervention isn't going to save the regional media industry. People have a whole wide internet to go for their entertainment and news needs, there is absolutely no reason for them to stick with their local media, we're so far beyond the age of the 6 o'clock bulletin being the core around which people organised their evenings it's not funny.

Oh and while I'm at it, dear WIN Television, it's a bit hard to take your call for support for local news services seriously when you don't have any news on your website.

So, as someone who has worked in the industry (albiet over 11 years ago), someone who relies on regional media to find out what's going on in his neck of the woods, and someone who is EXTREMELY frustrated that we're still having the "What even is the internet?" discussion in 2015, I am begging you to please hire someone with clue.

For all of the good hard working people within your organisations who are facing the very real possibility of job losses if you don't switch gears, I am begging you to please hire someone with clue.

Just do it. Really.


Blog Catagories: mediaregional media
Categories: Aligned Planets