Greetings DIYDrones community!
I am planning on launching an autonomous boat this summer. The hull is built and the pixhawk purchased.
I have just finished up
testing the rover software on my 4WD buggy - since it is the best analogue for a boat. So my understanding the PIDS and telemetry system and other small issues have been ironed out.
Now that I have some time up my sleeve, the next step will be sea trials! Well ok, perhaps pond trails, then lake trials and then sea trials.
A little about the boat and the project.
The boat is designed to be a downwind sailer. Mast mounted in the front with a sail (that's the reason for that big wood stump in the front, to hold the mast). The sail is free to spin 360 degrees and will pull the boat along.
There is a keel mounted in back and weighted with lead shot.
The object of the mission is to sail from the Pacific coast following the wind and currents and eventually arrive at Hawaii.
Now to help (or hinder as the case may be) I will be installing a rudder on the boat. The rudder will steer the boat with the winds to keep it on course.
That much can be plotted in Mission Planner and uploaded to the pixhawk. The missing piece of the puzzle is how to update or course correct during the voyage.
Project RockHawk
Enter Rockblock Iridium modem transceiver. The RockBlock operates on Iridium's Satellite SBD - short burst data network. It can transmit up to 340 bytes and receive 270 bytes. Not alot but enough for position updates and course corrections.
This modem has its own arduino library: http://arduiniana.org/libraries/iridiumsbd/
and would be the perfect device for remote control of the boat while under way. Since sat time is expensive, the plan is to only update the boat as needed. Position updates will be twice per day.
The only issue is how to get the Rockblock to talk with the Pixhawk. This unfortunately is way above my understanding. So I am looking for help to get the RockHawk project going.
The RockHawk must be able to accept remote waypoint updates while under way as well as use the GPS data from the pixhawk to relay back position updates and other variables.
If you are interested, please let me know.
Comments
@The Sea Captain: You may also find some tips about remote piloting here and about GPS here.
@The Sea Captain: Nifty project. You may find some other useful information here.
Those numbers of bytes are way off. You can give latitude or longitude to centimeter precision worldwide in 4 bytes (we do that in APM). Battery voltage takes 2 bytes for plenty of precision. Temperature takes 1 byte. Speed takes 2 bytes in cm/s. Wind takes 2 bytes in cm/s. Heading takes 2 bytes.
That table probably assumes very inefficient ascii encodings. We can do better than that :-)
Cheers, Tridge
This is a sample of how many bytes a message could consist of:
In fact it would be easy to trim it down from the 84 bytes they have in the table to 50 bytes or one credit.
This is the link for the table, on page 13:
http://students.asl.ethz.ch/upl_pdf/124-report.pdf
Rockblock is from a company in England so prices are in pounds.
It is £8 month for the line fee and the data fee is below
1 credit is used per 50 characters sent or received.
awesome project! keep us posted. very very interesting! How much is the dataplan for the modem?
It would be useful to investigate what are NASA best practices in their communication protocol when remote piloting a rover on Mars where you have similar bandwidth and delay issues.
I should be getting my rockblock naked and breakout cable next week and it will be available to help out with testing.
Great project!
As you know from the discussions we've already had by email I think it will be possible to connect this sort of modem to a Pixhawk. The way I'd like to see it done is by adding a new AP_Telemetry library which allows for ardupilot on Pixhawk to output different types of telemetry data on the 2nd telemetry port.
Normally the 2nd telemetry port does MAVLink the same as the primary port, but I think we could have TELEM_* parameters to control what type of data goes to the 2nd port. This could include a TELEM_TYPE option which would be set to the telemetry protocol that is wanted.
In your case we'd need to come up with a 'SMS' style telemetry protocol which would have an option to send very infrequent short data messages containing just the essentials for telemetry, and which would accept small messages in for commands and mission updates. It would need to be a very compact protocol. I think we'd want to make this protocol usable not just for the sort of satellite link you have but also for more commonly available GSM modems using standard SMS messages. That would also make it much easier (and cheaper) to develop and test as the testing could be done with a cheap GSM module.
There have also been requests to support the FrSky telemetry protocol and the HoTT telemetry protocols in ardupilot. I think we should structure the AP_Telemetry library to make it easy to add support for these different telemetry types.
I think the AP_Telemetry library should hook into the rest of APM via the comm_send_ch(), comm_receive_ch() and related functions in libraries/GCS_MAVLink. That means the input to each telemetry protocol would be MAVLink packets, which would then be translated to whatever protocol is needed inside AP_Telemetry. That minimises the impact on the mainline code. We'd only do this on PX4 and above, as the extra processing of unmarshalling/marshalling the data again would probably be more than the APM2 can reasonably do.
For the SMS protocol we'd need to keep state information inside the protocol driver, so it gathers the information it needs to send. Then when the time for the next update comes it would send the SMS message.Similarly for input, when it receives a incoming SMS it would need to decode it then feed that the rest of ardupilot.
One tricky part for input is handling the handshaking involved in things like mission upload. I think that is best handled by passing a reference to AP_Mission into the AP_Telemetry library so it can do direct mission updates (that needs to wait for us to merge AP_Mission of course).
The ground station software is also going to be quite tricky. We'd need GCS software that can handle the SMS protocol, and handle very infrequent updates (maybe as low as once a day for this boat project?). We'd either need to write a GCS SMS<->MAVLink gateway to use existing GCS software or write a new GCS that handles this new protocol. That needs some more thought!
Cheers, Tridge