https://mikeisted.wordpress.com/feed

I really like the idea of two or more of these cars chasing each other around a track, so that’s now the first objective. And I think this also suggests a name for these vehicles – Serial Pursuit Vehicles, or SPV1 and SPV2. I’ll need to decide on the colour at some stage, too ;-).

I have not raced RC cars since I was 15, so I’m no expert on modern RC cars. In those days everything was simpler; we used to charge our NiMH cells from a car battery through a single, fat 1 Ohm resistor. And speed controllers got so hot they would do much more than fry an egg if you got near them (that’s linear regulators for you). But I am quite impressed with the Quanum Vandal kit from what I can see so far. It certainly looks sturdy enough for my planned use, which will be on smooth-ish concrete and has a decent amount of adjustment for the steering and suspension.

For the build, there are unused holes in the chassis tray that can be used to mount a platform for more components. It also looks as though the driveshaft could be used for an optical odometer when the time comes.

The battery area can also be used for other components as we will mount the batteries themselves elsewhere.

On that note, we will be adding a certain amount of weight, so it seems sensible to adjust the mounting points on the suspension to the stiffest position, front and back.

One potential issue is the orientation of the ESC, which has the signal wiring coming out immediately adjacent to the drive shaft. This might create a wear-risk over time, so all I have done is reverse the ESC. The motor wires now come out by the drive shaft, but they exit vertically and so there is no chance of them interfering.

Lastly I am removing the small, bash plate at the front. This takes up space that will be required for other components and is not needed anyway as the car will not be crashing ;-). It also gives two more screw holes at the front that might prove useful for mounting more stuff.

Apart from that, we are done with the basic chassis adjustments. In the next post we will add extra capacity for components with some flat plates.

This is something I have wanted to do for some while for fun. Note that it has nothing to do with my work at Manna, so don’t make any assumptions about the technologies being used! I also don’t get much spare time, so updates are likely to be irregular.

Objectives
This is experimenting for fun, so may go in a number of different directions. However, I do want to see how close I can get to a car that accurately stays over a line, steered using Ackerman steering rather than a differential drive. This sounds simple but most examples I see seem to be too ‘approximate’, too slow or not very smooth.

Software / Hardware Approach
I’ll predominantly be using Python and open source libraries such as OpenCV and ROS. Probably ROS2, in fact. Where we need speed, we’ll use C++.

The usual suspects will be present, such a Raspberry Pi and Jetson. I’m also interested in the OpenMV unit, stereo and depth vision, RFID, mesh networking and others as things progress. For example, maybe having two cars maintaining distancing on the same circuit.

Chassis Selection
There are a vast number of notable car projects based on different chassis. and with different levels of aspiration from simple line following through to full autonomy. Many examples of the great Donkey Car project are based on the Exceed 1/16 scale truck. At the other end of the spectrum is the MIT RaceCar project and derivations of that such as Racecar/j. This also has some great support material available from others, such as Jim at JetsonHacks.

I want something a little larger than 1/16th, so have picked a 1/110 scale car from Hobbyking. The Quanum Vandal 1/10 buggy is particularly affordable and comes as a kit or assembled with ESC and motor. I picked the latter for simplicity. With a 2S battery pack, it should hopefully not be too fast for my purposes.

From the images on the website, it looks as though it should be simple to build on a couple of platforms for components – there are some unused holes in the baseplate. I’ll probably also want to set up odometry of some sort, and there look to be some options for that, too, maybe from the driveshaft, wheels or electronically.

In the next post, I’ll go over prepping the kit before making the first modifications.

I think it’s important for anyone to be clear about what drives them, both for themselves and for others. I’ll sometimes ask about these if I am interviewing prospective employees. However, we spend too little time in education or beyond in helping individuals articulate their own values.

In my opinion, Core Values are crucial, especially to guide us when there are tough decisions to be made or in resolving difficult situations with others (I’m also thinking of the use of social media here). No one is perfect, and we cannot always live up to our values completely, but they should serve to guide our behaviours and aspirations.

They are also as important corporately as they are for individuals, but that’s a whole other topic.

Here are my Core Values – can you articulate yours?

World Class
If something is worth doing, do it at the level of the best. For me, this is also about harnessing technology for beneficial outcomes on a global scale.

Integrity
This is about honesty, reliability and doing what has been promised.

Innovation
I love taking problems and looking at new ways to solve them. This is also about self-renewal and continually challenging oneself to think differently and learn from others.

Pragmatism
I like to apply what I do to in the ‘real world’. This means I am focused on applying technique, hardware, software and theory for a practical, realisable outcome – and normally with a strong sense of urgency.

Care
There are lots of dimensions to this! I care for those I work with, for my clients and business partners. I care about the quality of the work that I do and the products I create. I care deeply about social and global issues.

This post shows how to wire up and configure RFDesign RFD868x or RFD900x telemetry units to a Pixhawk 2.

You will need:

• Two RFD868x or RFD900x units
• FTDI/USB cable (comes with the units)
• Pixhawk2 telemetry cable with 6 pin servo style plug.
• Spare 2 pin or 3 pin male servo style plug.
• Internet connected PC etc with a groundstation installed.

I am always suspicious when something for UAVs claims to work out of the box.  So it goes without saying that these don’t, at least in this context!  We will go through:

• Reloading the firmware for the telemetry units.
• Configuring the units (to conform to UK regulations)
• Re-wiring the telemetry cable.

I prefer to use the configuration software direct from RFDesign on a PC.

• Download and install the latest version of the modem tools.
  
• Download the latest version of the SiK (non-mesh) firmware.
  
• Run the modem tool (it’s called RFD900 Tools)
  
• Connect the first of the telemetry units to the PC using the FTDI cable. The LED on the unit should flash green.
• Check for the correct COM port and click Connect, then Load Settings
  After a few seconds, the data will populate in the left panel, as below.
• Click Upload Firmware and follow instructions using the .bin file saved earlier.
• Reconnect and load settings.
• I found the default (max) transmit TX Power set to maximum, corresponding to 30dBm. I reduced this to 10dBm – don’t forget to save the settings.
  
• Disconnect, unplug and repeat for the second unit.

There’s a useful video of this for the standard Pixhawk at: https://www.youtube.com/watch?v=mScWEMlZXL0. However, I still found it necessary to use the datasheets for the Pixhawk 2 and the RFD900 to be sure as the end of the video is a little fuzzy.

For information:

• Pixhawk 2 pinout
• RFD900 manual

To rewire:

1. Remove all the wires from the RFD connector.
2. Remove the jumper pin from the RFD unit.
3. Reconnect wires as in the video. The 5V supply and GND wires can go in the 3pin servo socket. The rest can re-use the 6-pin socket that you have just taken the pins out of.
4. Here’s a summary and my hand-written notes!

The RFD connectors are below, displayed left to right in the same order as the diagram above.

• At the RFD end, plug in as shown:

• Power…
  

• Then signals…
  
• For the Pixhawk 2, make sure the connection is made to the TELEM1 port as this has a dedicated power supply for telemetry units.

Once powered up, the LEDs on the units will flash green initially, then solid green once they connect to each other. I found that the connection was made almost immediately.

I am hoping these units give a noticeably more resilient telemetry connection with my ground station, so that at all times there are at least two reliable and independent means of control of The Groundhog. They can of course be used for more than telemetry, aspects which will be explored in the future.   I’ll report on the telemetry performance of the units in the coming weeks.

I’m rebuilding The Groundhog to a more professional level, with the level of accuracy required for the AI and computer vision work planned.  It’s also getting an upgrade to the avionics to make it more resilient.  This post details the rebuild and also has links to the 3D printed parts used.

The airframe and power train has proved capable and reliable over the last 18 months, so it is being retained.  It comprises:

• Tarot 680 Pro Hexacopter airframe
• 2 x 4S 8000mAH Lipos (connected in series)
• 6 x Afro 20A HV Multi-rotor ESC High Voltage 3~8s
• 6 x Multistar Elite 3508-268KV High Voltage Endurance Motor

This flies smoothly, stands up to windy conditions and gives about 30 minutes flight time.

The old Pixhawk is being replaced with a Pixhawk 2 for the overall improved build quality and resilience.  The Raspberry Pi companion computer is being replaced by an NVIDIA Jetson TX2.  I have flown the TX2 for a previous blog, mated to an Intel D435 depth camera.  But to do this, the entire TX2 development board was mounted to the hexacopter – somewhat clumsy, if effective!  This time, the TX2 will be mounted on an Auvidea J120 carrier board.

Part of the more professional build is about reducing the traditional reliance on double sided tape, Velcro/dual lock and cable ties.  Let’s see how we do…

Drilling the hexacopter top plate is a non-starter as it doubles-up as the power distribution board.  The solution is to mount the components on a separate frame, in this case 3D printed from a nylon based plastic, selected for it’s strength over ABS and PLA.

Before the TX2 can be mounted, it’s power lead and the serial lead to the Pixhawk must be connected.  A small change needs to be made to the serial lead, as follows:

• Use the TELEM2 lead supplied with the Pixhawk2.
• Pixhawk side, remove the 5V, CTS and RTS wires.

• Follow the disconnected wires through to the TX2 DF13 connector and remove them.
• The ground wire (rightmost, below) is already correctly positioned.
• Reverse the remaining TX and RX wires.

I have learned to be wary of all beige-colour DF13 connectors, as supplied in this case.  I have previously found them almost impossible to push into a socket.  Sure enough, this proved to be the case on attempted insertion into the J120 carrier board.  The solution is to trim off the tabs on the left and right sides (image above previous to this).

OK, so the leads are plugged into the J120 carrier board and we can bolt the TX2 down to the frame using the screws supplied with the carrier board itself.  This has to be done from underneath, similar to the Pixhawk2.

Now bolt down the frame.

Consistent with the general upgrade, the following peripherals are being used:

• Here GNSS GPS
• FrSky RX8R receiver
• RFDesign RFD868x telemetry set
• Turnigy 5A (8-26v) SBEC for Lipo (6V supply to servo rail)
• Quanum 12V-5A (7.2 – 25.2V) Dual Output UBEC (12V supply to TX2)

First connect the ESCs to the Pixhawk2.

Mount the various antennae (receiver, TX2, telemetry unit).

All that’s left is the GPS, which can be mounted on a standard pole.  However, I am making a simple frame from nylon to do mount the Here GNSS unit which will also afford some knock-protection.  It is functional, if not beautiful…

Obviously the system needs to be tested before it can be flown.  In addition to the usual configuration settings, I am keen to check the settings on the telemetry unit to ensure the power output is legal in the UK.

In the first instance, the Pixhawk2/TX2 platform will mirror the progression in my series on ROS development, which is geared at the moment to a (regular) Pixhawk/Raspberry Pi system.  However, the development paths will diverge soon when we start to use the ability of this platform to utilise advanced cameras and machine learning.

In this post we will build a ROS node on a companion computer to subscribe to data being published by the flight control unit (FCU).  This will allow us to use the many data streams available from the flight controller as inputs to our system and then be able to make decisions over how the UAV should be controlled.

This post follows on from the previous post 1. Coding UAVs with ROS. SetUp using the Ubuntu image published by the wonderful folk at Ubiquity Robotics.

We are using a Pixhawk FCU running the PX4 flight stack.  This is connected to a Raspberry Pi 3 companion computer running Ubuntu, with ROS installed and specifically the MAVROS package to facilitate communication between the FCU and companion computer.

This is a very quick introduction!

In ROS, data is essentially communicated throughout the system using a publisher/subscriber model.

1. Nodes publish and subscribe to available data streams and process that data.  The MAVROS node for example, communicates with the Pixhawk FCU and publishes the data it receives.  We are going to create a node that subscribes to data published by the MAVROS node.
2. Topics are the data streams available between nodes.  Typically each topic ‘encapsulates’ some meaningful data, for example the attitude of the vehicle.  We are going to subscribe to the topic published by the MAVROS node that contains the current flight state of the FCU (so MANUAL, OFFBOARD etc.).  As you saw in the previous tutorial, data in topics is published at a particular frequency, for example 1Hz.
3. Messages are the data items themselves contained in topics.  So we subscribe to a topic and then read the messages as they are published.  Typically a message will comprise a header with a timestamp, and then the data itself, which might be very simple such a string, or more complex such as position data (x,y,z) and orientation data (roll, pitch, yaw).

As a visual learner, I envisage the system as a system of pipes (topics), connecting junctions (nodes).  Inside the pipes are the messages themselves being passed between the nodes. The great thing is that there is a utility built into ROS that allows us to see this structure, namely rqt_graph, which we will use extensively.

In fact, here the ROS graph of the code we are building.  It shows the /FCU_state_monitor node subscribing to the /mavros/state topic, which is published by the /mavros node.  (Ignore the /tf_static topic).

We are going to create a package for our files inside the catkin_ws workspace, in the src directory.  This will contain all our source code, data and documentation in one place.

1. Power up the Raspberry Pi companion computer and login (the default password is ubuntu).
2. In a terminal in the src directory of folder catkin_ws:
   • $ catkin_create_pkg fcu_monitor rospy
     (Nb. The argument rospy is a dependency of the package.
3. Open the folder fcu_monitor created in /catkin_ws/src
   It contains folders for the code and other information for the package.
   We will create our Python code in the /fcu_monitor/src folder.
   

1. In the /fcu_monitor/src folder, right click and create an empty file called FCU_monitor.py
2. Make the file executable.  I prefer to use the GUI for this  – right click, File Properties, Permissions.
3. Open the file for editing.  For some reason, IDLE does not seem to work (for me at least) on the image of Ubuntu Mate supplied by Ubiquity Robotics.  No matter – just use the GNU Emacs 24 (GUI) editor instead.  This is a little more complex to use – I dismiss the startup screen below the main editing area.  BUT remember to save using the Save icon on the menu bar and not just use ctrl-S.  This actually posts the changes made to the file and saves it.  Emacs also sets up a buffer file of changes alongside the source code file, which can be ignored for now.
   

We are going to create a class which defines a node to subscribe to the  /mavros/state topic.  The node has no idea what other node is publishing the topic and it doesn’t need to.  Let’s look at all the code, then work through it.

First we import the key Python libraries required to run the code – sys and rospy.  These are always included (for Python code).

The class needs to be able to interpret the message type within the  /mavros/state topic.  The next two lines import the definitions required to do this. The detail is easily looked up using ROS command line utilities, which we will go through together in the next section.

The class itself is standard Python.  We have a function to initialise an instance of the class and further functions as required.  We initialise the node (FCU_sub) to subscribe to the topic which calls a further function every time a message is received on that topic (FCU_callback).

The main program simply creates an instance of the node and handles the shutdown gracefully.

Before we can create a node, we need to drill down understand the message types contained within the topic(s) we are subscribing to or publishing.

We can start to do this by running the (other) nodes and examining the topics they are publishing.

• Open a terminal (anywhere) and start roscore:
  $ roscore
• Open another terminal (anywhere) and launch the mavros node:
  $ roslaunch mavros px4.launch

So mavros should now be publishing a whole bunch of topics based on data it is receiving from the FCU.  Let’s take a look at them.

In another new terminal:

• $ rostopic list
  
  

The topic to which we wish to subscribe is /mavros/state.  We need to know what message types it contains.  In the same or a new terminal:

• $ rostopic info /mavros/state
  
  

We can see (2nd line above) the type of the messages in the topic is mavros_msgs/State.  This allows us to define our first type import:

Now we need to see the details of the message type, to pick out the data types of any content we wish to work with. In the same or a new terminal:

• $ rosmsg info mavros_msgs/State
  
  

We can see the message comprises a header with a timestamp, some Booleans and a string containing the mode – it’s that we are after.  The type ‘string’ is a basic type within the ROS std_msgs library, so we import it from that.  Leave this terminal window open for now.

OK – so we have imported the libraries we need and key message types.  Now to the build the node itself.

First we specify the name of the node – ‘FCU_state_monitor‘.  Obviously keep it meaningful (it’s the name that will also appear on the ROS graph).

Then we set it up as a node to subscribe to the topic /mavros/state, specifying the topic type State to match that imported above.  Finally we specify the function to be called when each new message arrives – here it’s self.FCU_callback.

I like to store key data within the class so that is accessible across an instance of the class, for example to be used by another function when some new data arrives from a different topic.  Here we initialise a variable self.FCU_status to store the flight state mode.

Now we define the callback function, called when new a message of the /mavros/state topic arrives.  Note the name must match that specified when the subscriber node was set up above. The message is passed to the function in the argument, here imaginatively called msg, but you can call it what you like.

From our rosmsg utility used earlier, we can see the data item we want is called mode and it’s at the top level of the message.  So we can refer to the data item as msg.mode.

So here we store the value of  msg.mode into our variable self.FCU_status and then simply print it out to the terminal.
The main program simply creates an instance of the node, called sm (state monitor).

The question is then what happens?  In a ‘traditional’ polling approach, execution would follow through to the creation of the subscribing node and then wait until the first message arrives.  This would block further execution and obviously be fairly disastrous.  ROS however, uses a special version of  Python’s ‘sleep’ called rospy.spin that simply suspends the execution of the particular node(s) belonging to the class until a new message arrives.  This way the execution of other nodes in the system is unaffected and (robot) life goes on.  It’s very clever stuff with a bit of threading behind the scenes, but it’s also what makes ROS such a great platform for complex robotics, amongst other features.

1. As usual, run roscore and launch the mavros node in new terminals if they are not already running.
   • $ roscore
   • $ roslaunch mavros px4.launch
2. We are running the code directly within the package itself for simplicity, so make sure you open a terminal within the folder containing the Python code, namely ~/catkin_ws/src/fcu_monitor/src.  You are probably already there, of course.
3. Open the terminal and run the Python file:
   • $ rosrun FCU_monitor.py
     

The flight mode is printed out every second, or 1Hz.  This is because mavros publishes the data from the FCU at 1Hz, so the callback function is invoked at 1Hz..  Different topics are published at different rates, which can also be changed (on the FCU side).

Leave the new node running…

1. Verify the node is running (in a new terminal):
   • $ rosnode list
   • The node /FCU_state_monitor is listed with /mavros. Great!
     
2. Take a look at more information about the node:
   • $ rosnode info
   • Amongst other information, we can see the node subscribes to the topic /mavros/state
     
3. Finally, in a new terminal, show the graph of the current system of running nodes:
   • $ rqt_graph
   • (it may take a moment and ignore any component authentication errors)
     

We have built a simple subscriber to read data from the FCU, via mavros.  In doing so, we:

• Created a simple package.
• Started ROS with roscore and launched mavros.
• Listed running nodes and displayed information about them to be able to subscribe to published topics.
• Built our own subscriber node.
• Displayed information about our new node.
• Learned how to show a graph of running nodes using rqt_graph.

Code for this post is on GitHub here.

The purpose of nodes is (usually) to perform some operations on data from topics they subscribe to and then publish data through topics of their own.

Here are some suggestios of thing you might like to try now:

• Extract further data from the messages received by the /FCU_state_monitor node.  Combine these with a little logic to print something like ‘Armed and in Manual mode’ or similar.
• Add a further subscriber within the same class to a different topic.  Combine data from these topics in some way.

This series of posts is for those who want to take more control of their UAV (or other robotic vehicle) using a companion computer connected to the flight control unit.  Typically to get started, this might be a Raspberry Pi connected to a Pixhawk FCU.

The series will follow the development of a UAV which will autonomously recognise objects in it’s vicinity and track them in 3D space.  The focus of the posts will vary between different aspects, such as sensing, control and machine learning, for example.

A previous post detailed how to get started using a pre-built image from Ubiquity Robotics.  Parts of this post are repeated here alongside several important changes in order to provide a complete treatment in one place.

• Pixhawk/Pixhawk 2/ Pixhawk 4 flight control unit
• Raspberry Pi 3 or other Linux based companion computer

Development environment

For simplicity, development is directly on the companion computer.  Later we will network the companion computer and a desktop PC for simulation work.

1. Download and install QGroundcontrol on a PC from here.
2. Connect the Pixhawk to the PC. It should connect automatically over the USB link.
3. Install the latest stable release of PX4 and configure for your airframe here.
4. Now change the following parameter as on the PX4 guide  here.
   • Set Telem 2 for use by a companion computer: SYS_COMPANION to 921600 8N1, then reboot.

The RPi3 will need Linux, ROS and MAVROS.  Following the instructions on the ROS Wiki, we will install a version of Ubuntu Mate from Ubiquity Robotics, which already includes ROS.  We then install the package MAVROS, which provides the node needed to communicate between the Pixhawk and Raspberry Pi.

I suggest using a 32Gb, high speed card such as the SanDisk Extreme.  Pick a reliable brand and a fast card to support image transfer etc.  I am using a standard Windows 10 PC to prepare the microSD card.

1. Format the card.  A suggested SD card formatter is available here.
2. Download the Ubuntu image from Ubiquity Robotics here.

3.   Use Etcher or similar to create the boot microSD card for the Pi.

• Insert the microSD card, boot up the Pi and allow the card to expand to fill the available space.
• Open the home folder and show ‘Hidden Files’ using View on the menu bar.
• Modify the config file to allow the Pi to access the serial port.
  • The file is at /boot/config.txt
  • You will probably need to use VIM to edit the file from the command line.
  • add “enable_uart = 1”
  • modify “dtoverlay=pi3-disable-bt”
    
• Follow the instructions on the UR download page to remove specific UR configuration and allow more general use.
  • Remove the scripts for UR specific robot platforms
    $ sudo systemctl disable magni-base
  • Also remove the scripts that automatically start ROScore
    $ sudo systemctl disable roscore
• Remove or comment out the line invoking the startup script in the bashrc file.
• Package installation – make sure you have a valid internet connection for the next sequence.
• Install the MAVROS package as below (for info, it’s from here ) to allow communication between the Pixhawk and RPi. Download and run the geographiclib script.  Nb: The script will need to be made executable before it can be run ( right-click, properties…).

  $ sudo apt-get install ros-kinetic-mavros ros-kinetic-mavros-extras

  $ wget https://raw.githubusercontent.com/mavlink/mavros/master/mavros/scripts/install_geographiclib_datasets.sh
  $ sudo ./install_geographiclib_datasets.sh

• Update and upgrade.  This is important to prevent an error that will prevent mavros from launching.
  • $ sudo apt update
  • $ sudo apt upgrade

1. Connect the Telem2 port of the Pixhawk to the UART of the Raspberry Pi using a cable detailed in a previous post here.
2. Modify the launch file of the MAVROS package to connect with the correct baud rate.
   • The launch file is at: /opt/ros/kinetic/share/mavros/launch/px4.launch
   • You will probably need to use VIM to edit the file from the command line.
   • Set the fcu_url to serial0 at 921600 baud
     
3. Power up the Pixhawk, maybe by plugging it into QGroundcontrol on a PC.
4. Power up the Raspberry Pi.
5. Open a terminal on the Pi and start the ROS Core node:
   • $ roscore
     
6. Open a new terminal and start the mavros node:
   • $ roslaunch mavros px4.launch
   • As the connection is made, the node will display the parameters as they are read from the Pixhawk.
   • Please ignore the prefix on the parameters below – yours should just start with /mavros/…
   • 
7. In another new terminal, list all the data streams (topics) being published by the mavros node:
   • $ rostopic list
   • Again, ignore the prefix…
8. These represent a rich source of data that the companion computer can access. Of course messages can also be sent the other way to command the flight controller.
9. Take a closer look at one of the topics:
   • $ rostopic echo /mavros/state
     
     
10. This topic can be used to test for the current flight mode. Use Ctrl-C to stop further listing.
11. Find out how frequently a topic is published by default. Open a new terminal:
    • $ rostopic hz /mavros/state
      
      
12. You can use rostopic list and rostopic echo to explore information reported on many aspects of the operation of the flight controller.

UWE Bristol has been hosting 40 students from the prestigious Ecole des Mines d’Ales for the last four weeks for a Summer School in coding.

About half of the cohort elected to do two-week mechatronics course in autonomous UAV coding, supplied by Aisymmetrix and led by Miles Isted s’Jacob and myself, ably supported by Masters student Hamish Chalmers.

Most students had limited coding exposure and no experience of drones before the course, so this was going to be quite a challenge – great!

The priorities for the first week were:

• coding in Python
• flight concepts
• build a team drone
• fly some missions

The drones were based on standard 450 quad frames, with a Pixhawk flight controller running Arducopter.

We wanted to extend the autonomy of the drones so that behaviour could be directly controlled by the team’s own code. This was achieved through the addition of a Raspberry Pi companion computer and a webcam for computer vision.

A track was constructed of red webbing and teams had some ‘starter for ten’ base code to work from. The challenge was then to improve the performance of the drone in following the line around the track and also to introduce a new trick or feature.

The code on the Raspberry Pi was first tested on a simulator in the lab to check behaviour (or lack of it!).

The weather was great – sunny although with sufficient gusts of wind to provide extra challenge (maybe a bit too much!).  Some teams wasted no time in getting in some early autonomous flights to to see how the base code could be modified.

The teams also got straight to work in adding new functionality, including:

• making the drone fly backwards
• improving lap times with schemes for variable forward velocity
• improving data collection with remote computer connections
• remote control through use of smartphone
• recording track positions on initial lap to fly faster on later laps.

Of course there were occasional mishaps with some re-building necessary!

And plenty of team discussions…

Ah yes… and did someone mention a BBQ?

Teams were assessed on initiative and effort during the week and also asked to share their experience through a presentation to colleagues.  We were also joined by Tim Rook of IBM and David Palmer-Jeffery of HPJ Consulting for the final demonstration runs.

Several drones had multiple failures by the last day (more of which later), so teams were sharing those that were still fully operational.  But by the end of the week, all the teams had managed to complete successful laps and had explored different re-writes of the code to explore performance gains.

Team ‘Pick One’ modified both the computer vision and control algorithms to improve performance, showing excellent insights into the algorithms.

Team ‘Troublemakers’ introduced several new features, including variable forward velocity and more ‘intelligent’ behaviour to re-acquire the line when necessary.  Effective novel thinking!

Team ‘Hey OH!’ named themselves after their mission to control the drone remotely by voice.  They got a long way towards this objective, connecting smartphone to introduce variables into the controlling code, before simply running out of time.  Very impressive!  The team also modified the control code and in particular worked successfully with the ever-tricky area of PID control variables.

Team ‘Game of Drones’ successfully modified the code to make the drone fly backwards and made a number of other improvements, flying a number of laps – forwards.  Flying backwards turned out to be more of a challenge than perhaps anyone thought, but the team tackled several issues and were successful in this over a distance of a few metres – great effort!

I don’t think anyone would disagree that Team ‘Drone Project’ were technically the most ambitious.  However, perhaps one should expect that as three of the team work for Airbus!  Team Drone Project connected remotely to their drone to collect alot of flight data and images.  They also implemented an algorithm in which the drone recorded the track as a series of GPS positions on the first lap and then used those to fly faster subsequent laps.  And more besides…. a very impressive effort!

The overwhelming takeaway from the course was the impressive progress made by the students from the Ecole des Mines d’Ales.  In just 8 days of tutorials and support, the students built their quadcopters and learned basic avionics,  mastered safe flying skills, conducted ‘missions’ and finally coded their own autonomous behaviours in a coding language that few if any had used previously.  Awesome!

The group displayed all the qualities required to make the most of the experience; a ‘can-do’ attitude, curiosity and imagination, tenacity, teamwork and of course a great sense of fun!  All essential engineering characteristics!

As far as safety was concerned, all teams piloted their drones carefully and used the various safety devices appropriately.

There were of course issues that cropped up unexpectedly.  The drones suffered component failures from ‘heavy use’ and low-level ‘drops’.  In particular, compasses and camera gimbals took a heavy toll.  Of course some of the issues were also opportunities for further learning, such as the limitations that cameras experienced in identifying the red-webbing in very bright sunlight (I know, who would have thought that could happen in the UK!).

In summary, we could not have asked for more.  This proved to be a great learning experience for both the students and for ourselves in running this first UAV Coding Summer School event.  The masters of ‘playful learning’ are perhaps LEGO – for me, this seemed to work in exactly the same way for ‘grown-ups’ and as an educationalist makes me just want to do more project-based learning.

A huge thank-you to UWE Bristol and to the students themselves!

22 students from France will be spending the next two weeks building and coding autonomous drones as part of the UWE Bristol Summer School.  Along with Miles Isted s’Jacob, I am delighted to be leading on this activity and have produced a short sneak peek video of the challenge to share.

So six team drones racing autonomously on a single track? What’s not to like?

Code is based on that used for MAAXX Europe, so Python Dronekit, with ArduCopter on Pixhawk.  However, the final code will be posted on my github at the end of the Summer School.

If you have heard of Robot Operating System and want to use it to monitor and control UAV flight, this post will get you started…

More specifically, this post details how to set up a Pixhawk flight controller running PX4 firmware, with a Raspberry Pi3 companion computer running Robot Operating System.  This combination will give flexible control over the flight control unit and the ability to integrate a very wide range of features such as depth-sensing cameras and machine learning networks.

The system represents a fairly major change in direction as I move towards a new phase in what is becoming a quest to build a multi-role, resilient UAV platform. In previous posts I have used Arducopter firmware on the Pixhawk and the capable Dronekit API on the Raspberry Pi.  So why switch out Arducopter in favour of PX4 firmware, and why replace Dronekit for ROS?

I have used Arducopter for development for the last 4 years and it and remains a fine flight control package. The decision to move to PX4 has been based purely on a narrow set of requirements around my particular use of a companion computer. One reason is that the PX4 stack seems to allow more flexibility around the rate at which Mavlink messages are published to the companion computer. A second reason concerns potential delays in response in communications between the flight controller and companion computer. I have experienced this myself and whilst it has not previously been critical, it most certainly will be for future plans.

So whilst in some respects some might argue that the PX4 stack seems less flexible, it has particular strengths in some important areas for my purposes. At least I hope so!

Dronekit has proved invaluable for developing skills to control a UAV from a companion computer. My educational activities are based on it and will continue to be so, including the UAV coding Summer School I am running this July at the University of the West of England.  The move to Robot Operating System is simply because it offers a more open development environment for robotics and a broader technical community.

1. Download and install QGroundcontrol on a PC from here.
2. Connect the Pixhawk to the PC. It should connect automatically over the USB link.
3. Install the latest stable release of PX4 and configure for your airframe here.
4. Now change the following parameter as on the PX4 guide  here.
   • Set Telem 2 for use by a companion computer: SYS_COMPANION to 921600 8N1, then reboot.

The RPi3 will need Linux, ROS and MAVROS. To do anything useful with images it will also need OpenCV.

Rather than load it all up manually, I am starting with the Raspberry Pi image published by those wonderful people at Ubiquity Robotics.  It uses Ubuntu Mate and has ROS and OpenCV preinstalled. It’s hugely more convenient than doing it yourself, at least to start with.

1. Download the Ubuntu image from Ubiquity Robotics here.

1. Use Etcher or similar to create the boot SD card for the Pi.
2. Boot up the Pi and allow the card to expand to fill the available space.
3. Modify the config file to allow the Pi to access the serial port.
   • The file is at /boot/config.txt
   • You will probably need to use VIM to edit the file from the command line.
   • add “enable_uart = 1”
   • modify “dtoverlay=pi3-disable-bt”
   • 
4. Follow the instructions on the UR download page to remove specific UR configuration and allow more general use.
   • $ sudo systemctl disable magni-base
5. Remove or comment out the line invoking the startup script in the bashrc file.
6. Package installation – make sure you have a valid internet connection for the next sequence.
7. Install the MAVROS package as below (it’s from here ) to allow communication between the Pixhawk and RPi. Download and run the geographiclib script.  Nb: The script will need to be made executable before it can be run ( right-click, properties…).

   $ sudo apt-get install ros-kinetic-mavros ros-kinetic-mavros-extras

   $ wget https://raw.githubusercontent.com/mavlink/mavros/master/mavros/scripts/install_geographiclib_datasets.sh
   $ sudo ./install_geographiclib_datasets.sh

1. Connect the Telem2 port of the Pixhawk to the UART of the Raspberry Pi using a cable detailed in a previous post here.
2. Modify the launch file of the MAVROS package to connect with the correct baud rate.
   • The launch file is at: /opt/ros/kinetic/share/mavros/launch/px4.launch
   • You will probably need to use VIM to edit the file from the command line.
   • Set the fcu_url to serial0 at 921600 baud
3. Power up the Pixhawk, maybe by plugging it into QGroundcontrol on a PC.
4. Power up the Raspberry Pi.
5. Open a terminal on the Pi and start the ROS Core node:
   • $ roscore
6. Open a new terminal and start the mavros node:
   • $ roslaunch mavros px4.launch
   • As the connection is made, the node will display the parameters as they are read from the Pixhawk.
   • Please ignore the prefix on the parameters below – yours should just start with /mavros/…
   • 
7. In another new terminal, list all the data streams (topics) being published by the mavros node:
   • $ rostopic list
   • Again, ignore the prefix…
8. These represent a rich source of data that the companion computer can access. Of course messages can also be sent the other way to command the flight controller.
9. Take a closer look at one of the topics:
   • $ rostopic echo /mavros/state
10. This topic can be used to test for the current flight mode. Use Ctrl-C to stop further listing.
11. Find out how frequently a topic is published by default. Open a new terminal:
    • $ rostopic hz /mavros/state

You can use rostopic list and rostopic echo to explore information reported on many aspects of the operation of the flight controller.