Greetings enthusiasts!
Has anyone played with the Navio+ as the APM for the ROV controller? I am currently building the bits on the Pi (taking forever) and wanted to know if anyone has tried their hand at using the Navio+ as the APM?
Jim
Hey Jim,
We have not played around with a Navio+ yet, but it looks awesome! One of the reasons we chose the APM is because we knew the code base was strong and we felt like a lot people had an extra APM lying around. For folks buying new hardware, however, the Navio+ looks like it could be a better choice. Maybe we’ll get one to play with!
Josh
Small update, I’ve added you APM modifications to the navio branch of ardupilot. Compiled APMrover2 and all is well as far as the navio+ is concerned.
I’ve abandoned the rosberrypi install of ROS for wheezy on the RPi2 in the Navio+ RT patched kernel. I spent 1 week on it and could not get mavlink/mavros to compile. I installed ros_comm just fine, but mavros was just angry. I did, however, find cctronics image for the RPi navio+ shield.
Looks pretty solid so far. I wanted to stay as close to the bluerov-ros-pkg as possible, but I think it will need to branch off a bit given the navio+ nuance. Anyway, if anyone solves the navio+ issue with mavlink using ROS on the Rpi2, please let me know.
That being said, I am now re-writing the bluerov package to play with the ROS/Qt5/navio+ solution supplied by cctronics. They encapsulate the navio+ shield pretty well and you get direct access to the various IMU/barometer components. But here’s the thing, no mavros/mavlink.
Now the APMrover code talks just fine to my GCS using QGroundControl. But, no on-board mavlink message passing through ros. This is because I haven’t really researched and solved the issue, and I may never if I don’t really need mavlink…which it seems, given the cctronics guys solution, that I don’t.
That being said, let’s see how well of a solution I can come up with re-writing the bluerov package using the encapsulating autopilot code for the navio+.
More to come. BTW, here are some shots of the kit I am building. It’s 14"x21"x14", high pressure PVC frame (I’m poor…and it’s just a prototype testbed). Also, a protype PLA motor mount for the turnigy dst 700 motors I am using…yes they will be exposed to salt water…like I said, I’m poor. Anyway, more on the build soon.
Jim
Ok, so I take the part about not being able to compile mavlink on the navio rpi image. The cctronics img seems far more amenable to it then others…for reasons I have yet to understand…more to come…
Hey Jim,
I think we will want to move to having three distinct groups of code:
- common code - input mechanisms like the xbox controller and keyboard controller, auto-leveling, position holding, etc
- geometry / thruster configuration depend code - we would probably have a file for each supported thruster configuration; users would create their own file here for custom or unsupported thruster configurations
- interface code - i'm thinking we use a generic "thrusters" message and have separate files for each supported control path; we'd probably have one for an APM and one for the Navio+ to start
What do you think?
Also, we strongly liked installing the vanilla Ubuntu 14.04 image for the RaspberryPi because we didn’t need to compile any of the standard ROS libraries that way. All of the libraries, including mavros/mavlink, are available through apt. This made the install process notably easier and 10x quicker for us.
Sweet pics! Keep 'em coming!
Hi Josh,
Good ideas. I can certainly think about the architecture as I code through it. I’ve been away from ROS for a little while but diving back into it now. I’ve been wrapped up in DDS based pub/sub for the past year or so. Fun stuff. I hear ROS is considering DDS as the protocol of the future as well. I think they even have a repo or two on github devoted to that switch.
Anyway, breaking it out into controller types (teleop/mission file), behaviors(nav, position hold, pattern flight, auto level, etc), configuration (maybe .json files or the standard ROS config ) and autopilot interfaces makes complete sense.
Abstraction is good. Generic sensors, thruster, and high level control topics would be great.
Once I start writing the bits, I’ll draw up the architecture for the Navio+ implementation and go from there.
Completely get it with the Ubuntu install. I didn’t want to go down the preempt patch in ubuntu and configure the kernel as the emlid guys did (needed to run inner loop control on the RPi). I have no idea what they did with the RPi kernel as far as configuration of the RT patch, I plan on asking because I would rather have Ubuntu 14.04 or whatever with the RT patch than raspbian…so maybe a project for the future. It may be a trivial setup, I don’t know yet. Hopefully it is.
Mmm, I will definitely give deeper thought to the architecture. the navio interface is the first thing on the list.
Thanks!
Jim
Interesting note on the cctronics navio/ros/qt5 dev. CCtronics use Qt to wrap up both the ROS and Navio+'s some what verbose bits, giving access via CCLibROS, CCLibMath CCLibXml, and mBaro, mGPS, mIMU and mPWM files which wrap up the verbose bits of pulling data from the autopilot shield, in a succinct manner…nice. They basically abstract away the ros::subscriber … type calls and let you do Subscriber sub; and so forth. Also encapsulate data pulls from the Navio+ and publish them out of the box. Just subscribe to topics “navio/Barometer” gps, imu and so forth.
They also use ccsettings.xml to define frequency of the pub/sub, master uri and hostname for quick configuration. This can all run side by side with the APMrover2.elf which pumps out data via mavlink messages to a GCS (which I should really be calling TCS…topside control station) anyway, neat.
Some promising news. Looks like a standard catkin workspace outside of the cctronics libs and qt5 impl works on the cctronics image as it would on any given box. This allows for a far more generic solution to the re-write for the Navio+. I’ll dive deeper into the mavors issue, but modifying the existing bluerov code with the navio+ interface seems far less verbose then feared. More to come once I finishing up the modifications and unit testing.
Navio interface and navio controller are coming along swimmingly. I’ll post the bluerov branch to github this weekend if anyone is interested. Bare bones at the moment, teleop control only, but full suite in the works.
Jim,
Very cool! We’re looking forward to seeing your work. Thanks for contributing!
Best,
Rusty
<div class=“cooked”>
Non-optimal, but here’s what I have for thrusters on the new kit. I wouldn’t trust this stuff, PLA, below 100m (that and there’s nothing near 100m depth in the Chesapeake lol) but hay, it’s a good prototype for a magnetically coupled housing I am planning on building early next year.
Let me know if you all need a NAVIO+ board and/or components. I’m sure we can assist you.
Stupid question time … I thought PLA would break down by hydrolysis. So in simple stupid terms … it will decompose in water. This material is considered biodegradible for a reason.
I have doubts about ABS that is 3D printed because water can “leak” between the printed layers. But according to the chemistry of the PLA, it doesn’t seem like it would have a fun time in water, little lone long term exposure to water at various pressures.
Is the intended use of what you are printing just to see how it all looks as in building a 3D mockup of it or do you plan on using it in water?
Exactly, just for prototyping. I’ll drive it around a pool for testing with the PLA thrusters, but won’t use it on an actual deployment in the Bay. Delrin will most likely be the material I use for the finally kit. Maybe HDPE. Good question though. I haven’t had the time to write up anything to explain what I am doing, but maybe in the next few weeks.
Also, exposed motors like this in salt water is just silly as well, the bearings just hate it no matter how much you flush them after a dive. Some folks have potted designs that I will eventually test.
Wow, it’s been awhile. Had a series of flight demos out here in the Chesapeak, so I’ve been away, but now it’s go time…so to speak.
Updates on the Navio+ code base. Summary: Due to significant issues with Mavlink and the CCtronics image I am using for the RPi2, I ditched mavlink and the ArduRover code completely and built the interface interfacing with the Navio+ directly through the navio API using the BlueRobotics ROS code base. This has diverged so much from the original code base that it’s not very similar to the repo. I’ve also noticed the changes to the base that I haven’t reviewed fully, but seems to be a good code decision.
Anyway, deciding to separate the Navio interface from the repo code base as it can’t even use some of the features of the latest boost, the cctronics image is stuck on 1.49 and after many an hour, have failed at getting the cctronics image to be happy with even 1.50. So in auspices of ever getting into the water, I’ve set aside that rabbit hole for a later dive. Long story short, The 6 thruster kit of my own design using the Navio+ APM is now a completely separate ROS package. I would really like it to be a branch of the main repo, but I’d hate to decend back into the maelstrom of horror I faced when trying to get the image with arm build of ROS happy with the Navio. The underlying reason for all of this is that the Navio+ has the RT Kernel for inner loop running on the RPi2 image…so this is not similar to the current blue rov setup with an RPi connected to an APM Pixhawk…
Ok, anyway, pics of the vehicle coming soon. Just received the pressure housing and getting the custom setup build this week. Doing the OpenROV setup with a webcam and hinged internal camera mount. More to come.
You know…after thinking about this with a few months off…why do I need the RT Kernel for inner loop control? I’m not flying in air, so why the need for preemption and data frequency guarantees for control algorithms in a slower domain space? hmmm…
All I need is IMU data, ADC data, GPS when topside or attached to a topside GPS buoy… Just need the GPIO interface with the navio and no need to be constrained to an obscure arm build of the kernel with a ROS config that is just a pain to install packages, etc. Depends on the dependencies of the new bluerov ros package, i noticed PCL is now involved, which is great, but not great for arm builds unless on an odroid xu4 or none Navio image, LOL, more to come. Going to try the default ubuntu with NAVIO API … if this doesn’t work, I’ll stick with my separate Navio interface ROS node which runs great.
Hi Jim,
Thanks for the update. Sounds like lots of frustration!
We’ve been working on shifting the majority of the control off of ROS and onto the autopilot. That’s led to the new “ArduSub” project, which is an up-to-date fork of the main ArduPilot project. It’s fairly mature already and should work fine on the Navio. It can accept commands from ROS. You might want to give that a shot as well.
We’ll be cleaning it up and adding more documentation in the coming weeks, but here’s the repo in the meantime:
Best,
Rusty
Thanks Rusty,
That’s exactly what I am doing today. I will update you on outcome this evening
Thanks!
Ok, got the cross-compile for NAVIO + and ArduSub working and got things to talk on the NAVIO+/RPi. Nice work on the branch. I tried with the PREMPT-RT patch raspbian, I’ll give it a shot on the ubuntu install next. I will probably go ahead and add the prempt-rt patch to the ubuntu kernel for good measure anyway. I think once I get it tested, I’ll create a Docker image or just a standalone and if you cats want to have it as a possible options for folks to pull down the navio+ and ros bits in one go, then it can be available
Awesome!