Beta v3 image with ROS and Wi-Fi Broadcast support for Navio boards


We’re excited to share with you the third iteration (and hopefully, the last) of Navio Beta image with new exciting features:

  • ROS
  • Wi-Fi broadcast
  • Minor ArduPilot stable update (3.4.4)

You can look into threads dedicated to previous betas (v1 and v2) and changeslogs in order to clear up some misunderstandings.

The documentation for this beta release is available over here

They contain entries on ROS and Wi-Fi broadcast which will help get you started with your new exciting projects.

Happy New Year!


Hello this is great.

Does wifibroadcast work only with raspberry camera or can use other usb or ip cameras?

Is it possible to use wifibroadcast to route data to ground station?

Just another info, is ir-lock included in this release?


No. As I previously answered this question in other thread - it will be supported in AC-3.5.

Default scripts included in this release are tailored to work with Raspicam but you can modify them to suit your own needs. Wi-Fi broadcast feature doesn’t depend on any specific video camera. In fact it’s orthogonal. It just broadcasts data. We set up image with a kernel that is capable to do this. In theory, you can stream whatever you like.

I am running Beta v2 and after running ‘apt-get dist-upgrade’ the following packages were updated

ros-indigo-dynamic-reconfigure ros-indigo-nodelet ros-indigo-nodelet-core ros-indigo-nodelet-topic-tools ros-indigo-ros-base

Is this the upgrade to Beta v3? Or do I need to actually reflash the sd card to upgrade from Beta v2?

You need to reflash your card. Some major changes were needed in order to make some new features work. Hence, a reflash is essential.

1 Like

I just download above link and get “emlid-raspbian-20161229.img.xz”.
Mission planner said “APM:Copter V3.4.3-rc1 (91603193)”.
Any idea on this?

Let me pose some questions

wifibroadcast is included, does that mean that when I plug in my atheros card that I use with hostapd the bitrate will be modified on it, such as it is on Wifibroadcast? This would be undesirable in my case.

I may be wrong but I believe there were talks about having a built in access point, such as hostapd, so when you plug it in to a RPi 3 you can ssh into it without a monitor, keyboard, wireless router, etc. All you need is a laptop or other device, is this still going to be implemented?

Shouldn’t this feature such as the access point that allows easier configuration/implementation of the product be prioritized over adding wifibroadcast, which don’t get me wrong is a great feature to help expand the vision and capability of the Navio (hence the whole idea of having it piggy back on the RPi) but that doesn’t really help the product itself?


The more I dig, the more I think there was a mismatch somewhere when doing the img.

Interface file is not ready for wifi broadcast (acces point is not configured),

wbctxd.service fail to load or start…

I had to manually install Copter 3.4.4-rc1 from the arducopter repository…


1 Like

Same remark on my side : the “/etc/default/wbc” conf file does not exist (created from the doc information)
I get the following info on wbc service start
"Failed to start wbctxd.service: Unit wbctxd.service failed to load: No such file or directory."

1 Like

Hi @george.staroselskiy, all,

I’m wondering if Wifibroadcast can work together with normal wifi (for ssh access)? For instance, if there are two wifi cards, or in the case of RPi3 with built in wifi.

Thanks, and happy new year.

Hello Yannis
Wifibroadcast changes your wifi device mode to “monitor” mode which sets a unidirectional link between your Rpi and GCS. To what I understood this is not possible to use both conventional wifi and wifibroadcast on the same device (indeed, basically the same “wlan” which would correponds to a single physical device)
If you want to use “conventional” wifi for telemetry or SSH you need another wifi device : the built-in RPi 3 chipset should work provided you have another wifi device dedicated to wifibroadcast
Be aware that range for the built-in RPi 3 wifi should in theory be quite poor as there is no external antenna --> I would not advice to use it for telemetry (but maybe this is something to be further tested…)

Hi @Guiboy,

Thanks for your reply.

For sure monitor mode is not compatible with “normal” wifi mode, thus as you pointed out both cannot be active on the same device. My question was to whether using two devices a combination of WBC (monitor mode) and wifi would be possible. Perhaps by specifying the adapter to use to the wbctx script.

Re. telemetry, it is in fact possible to transmit telemetry (or, any other data for that matter) using a single WBC transmitter. AFAIK EZ-Wifibroadcast supports forwarding telemetry that is input in Pi’s serial port, for instance. I’m not sure if it is supported currently in the Emlid image, but eventually it would be great to see this as well, as it is a perfect fit since NAVIO telemetry is practically built-in.

Yes, I am waiting version 4 image that is fixing minor issues.

Thanks for trying the Beta 3 out, guys!
Team is on holidays till 8th January, the work will continue right after that.

We’ll think about some workaround. Maybe include two versions of the modules or something like that.

There are a couple of caveats regarding the implementation of the access point. We are thinking about it.
No doubt it would be handy, but access point is not the only way to set up ssh connection without the monitor\keyboard - you can simply add your WiFi network to a file on SD card or use an Ethernet cable.

Things are a little bit more complicated from our perspective. It would take an enormous amount of time to explain why are we doing X and not doing Y in particular, but in short and general we have a lot of stuff to consider that is only seen by the developers like: amount of effort required for implementation, how much maintenance we will have to carry afterwards, compatibility with other features, does anyone else already work on that feature etc.

We are always open for feature requests (but cannot promise their fulfillment). Yours is noted, thanks!

Sure, using two adapters you can have both normal WiFi and WBC at the same time.

@mikhail.avkhimenia great! I’m going to give it a spin this evening and report back. Thanks for your hard work :slight_smile:

By the way, I also noticed my external compass is not accessible from Mission Planner anymore (connected through i2c on navio2 board).

Here is what I get when I type sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- 1e –
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – 77

My compass is embedded in my external GPS antenna connected through uart using the option -B /dev/ttyAMA0
GPS works great…


Sorry for the inconvenience as in the meantime I could solve my external I2C compass issue… which was coming from my RPi!!
I replaced my Navio 2 board --> still not working
I replaced my RPi3 with RPi2 --> working
I replaced my RPi3 with another RPi 3 --> working

After full cleaning of connections my “faulty” RPi3 worked again…

This is really strange behaviour as my “faulty” RPi 3 was perfectly answering mission planner. I am also surprised quality of connections can apparently variate from 1 RPi to the other (this might come from corrosion on the connectors due to exposition to humidity)
Wouldn’t we miss a safety check in the pre-arm code to test I2C connections are ok?