APMRover 2, a fun UGV project for full autonomous recon missions...

[UPDATE: This project is now being ported to a proper Google Code repository and manual. For instructions, start there. You can also join the ArduRover User Group here.]

Hello to ALL, the new firmware for APMRover v2 has been tested successfully on my rover on may 1st, 2012 on full autonomous reco mission following a navigation plan. This new release of the APMRover v2 works on the APM v1.4 with the OilPan shield (magnetometer + MT3329 GPS) and also of course on the APM v2. The previous version of the APMRover v1.0 was a light size version specially designed for the APM1280 CPU (only) board and the MT3329 GPS.

For the frame, I have used a Traxxas Monster Jam Grinder with a brushed and high power motor Titan 12T and its XL-5 ESC.

The APMrover UGV is able to run itself following a list of recorded waypoints. The waypoints list (FPL) can be preloaded with the APM Mission Planner OR better in live, recorded by the pilot himself (with the SW7) during a manual run and then replayed in a full autonomous mission.

The firmware APMrover2 for APM v1 + OilPan or APM v2 successfully tested can be downloaded HERE

The APMrover v2 is also online on the official ArduPilot-Mega GIT repository HERE

Below the PID setup for the APMrover v1 and v2:

The light firmware APMrover1 for APM v1 (CPU 1280 or 2560) that I have tested can be downloaded HERE 

Here's how to connect your cables:

More infos at: http://diydrones.com/profile/JeanLouisNaudin

Have Fun and Enjoy with the APMrover...

Regards, Jean-Louis

Views: 79646

Comment by Thomas J Coyle III on November 8, 2012 at 5:33am


I believe that SerialPort2 is being used for the I2C function. Might want to check and make sure that it is really free for use.



Comment by Flavio Taborelli on November 8, 2012 at 6:07am


I'm not 100% sure but uP has dedicated i2c line that is phisically different from serial. At this point I need to test the line once I have the board on the bench or wait someone that know it.





Comment by KM6VV on November 8, 2012 at 9:41am


I was thinking serial in, serial out.  So you'd actually need two serials in, and another out ("merge" NEMA strings) on the uP.  You'd need a serial port on the APM2, or maybe use I2C.  The GPS would be moved out to the uP, so whatever it uses would be freed up. 

If you just bring ECHO into the APM2, then it would need a serial port.  Might be possible to convert serial to I2C, and then use an I2C port.  But then you'd need to modify APM2 code, rather then write code for the uP.


Comment by Flavio Taborelli on November 8, 2012 at 10:12am

Another way I'm thinking about is use a softserial library to emulate a serial port on one of the spare input pin on the APM.

Probably it will slow down a little bit the loop but I plan to read Echo every 2/3 sec as the data is already an average calculation from the uP of the the echo.

I'll try to read it with an arduino and softserial and we will see what will happens.

Do you think it could be a good way ?


Comment by KM6VV on November 8, 2012 at 10:36am

Soft serial can have problems when there are other interrupt-driven tasks running.  But sure, try it!


Comment by Flavio Taborelli on November 15, 2012 at 1:09pm

Hi All,

I did a big jump in my project, after hours of test I finally enabled on APM 2.5 a spare serial on Uart2.

I took the APM rover FW in arduino IDE and after a bit of trouble on the upload part I find the right way to declare the new serial port and use it.

I did a custom library ( to read and parse the Nmea string coming from the Echosounder and I sent it by mavlink using one of the existing variable ( for test I use BatteryVoltage because I dont use the sensor ), A big thanks to Riccardo Rocca and Roberto Navoni for the help on the parsing code and mavlink understanding.

Also the "mechanical part" is on the way, I have the hull with the motor and servo installed and the first "dry test" using the little rovver is ok in Manual mode and AUTO mode.

The only things not clear is the setup of the compass in the code... seems that heading is 180° reversed but #define MAG_ORIENTATION  AP_COMPASS_COMPONENTS_UP_PINS_FORWARD is commented in the code... missing something in this 71 pages ?

I did a calibration and declination is correct, but in HUD I still have reversed headind. Seems that this is not influencing the rovver auto mode, I'm able to perform 7 WP in 20mt square parking.

Actually I'm using a standard boat radio, the one with the wheel for the steering, is a 3 channel radio so I lost the ability to use the "learning" function and RTL but with telemetry enabled I need only the Manual and Auto mode.

here a quick photo of the boat and the rover used for setting up parameters ( Walk is better than swim to recovery the faulty UAV :-P ).




Comment by Flavio Taborelli on November 16, 2012 at 10:46am

Here a short video of the test :-)

Comment by Thomas J Coyle III on November 16, 2012 at 12:33pm


Impressive naviagation. Very well done!

Normal compass orientation is pins forward and components down. JLN used pins forwar and components up because of the way he mounted his compass on this rover. With pins forward and components down both my 5883 and the earlier 5843 calibrate correctly.



Comment by Flavio Taborelli on November 16, 2012 at 1:06pm


Thanks ! I'm very happy after a lot of work to have this results.

About compass the trange things is that the lines in MP that show heading, nav_heading etc are correct, only the HUD compass is reversed, also I suppose that to have the good navigation as on the video the compass is working in the correct way. Also on FW config the define of the compass orientation is commented out... maybe JLN or Chris know how this change was made.


Another strange things that happened is about failsafe, I disable both short and long failsafe but on the first power on today, with TX Off , the motor start at full speed in reverse....


Now the mission is to put everything in the Boat and restart the setup again . :-)





Comment by Jamie Glover on November 16, 2012 at 10:23pm

Hello all, I had a quick question.. I will admit upfront, that I have not read through all 78 pages of comments on here, however my question stems from an incident this past weekend.  I am using a Turnigy 9x tx/rx and APM 2.5 board.  I was doing somt FPV driving when I lost video signal driving around my apartment complex. As I walked toward my rc truck to get it back to me, before I could turn the corner of the building it was at, I heard the motor shrill up to full throttle and shortly after, a crash/crunch!  I thought.. hmmm... that sounded like my rc truck... well, sure enough, my truck had managed to reverse itself completely underneath a low rider vehicle. I could not understand at first how my truck that stood 8-9 inches off the ground, ended up under a car with 3 inches of ground clearance, but it was under there and wedged pretty freakin good... and smoking. I had to pull it pretty hard to get it out from underneath the car as it was wedged really tight. The motor wires were burnt to bare wire, and my ESC wires were melting. Now, having recently read how Turnigy 9x and APM were having fly away issues with Quad copters, I was wondering if the same could hold true to Ardu Rover.  I couldnt see how else this could have happened.  It was less than 300 feet away; but then again, Ive seen some wierd things in this hobby.. anyways, That is my issue and I was wondering if anyone had any input. 


Also, In RTL mode, is there a way to have the rover follow waypoints back to RTL instead of straigt LOS back to home?   Depending where Im at, straight back home would not be possible due to buildings, curbs, etc.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service