Hi,

I am working on an addition to APM that manages a data connection via a DroneCell or other cellular modem. It maintains control of the mobile and checks the state of the connection, instead of just putting it into transparent mode and hoping everything will be OK.

It has worked fine under ArduPlane 2.68. Now I am trying to integrate it into 2.70 while preparing for some finishing touches like being able to work with several different cellular modules.

I am running into a problem with the current design of the APM code, which I think will only get worse in the future, as we will probably have even more possibilities for data connections - on-board IP stack, 3 and 4G, etc.

The problem is that the concern of basic I/O is mixed with that of printing strings. This forces one to make more specializations for the different hardware and simulation platforms that may be necessary. I have made an UML, existingDesignWithAdditions.pdf, that shows the current layout with addition of my MobileDriver which is again made to work with 2 different modems. The need to support printing in basically all streams results in a (too) large number of subclasses for the different platforms.

In eg. Java the concern of printing character stuff is separated from that of doing I/O. That is quite nice - you can combine any I/O stream with any character printer, or with none at all. Could this be done here too?

I have put together the UML newDesign.pdf to illustrate (some trivial methods were omitted). Stream does not inherit from Print, and BetterStream basically is renamed to BufferedIOStream. To print, one makes a PrintStream with a reference to the BetterStream (could strictly just habe been a Stream). PrintStream implements the interface of BufferedIOStream but just forwards all non-print messages to its stream. For the platform specifics of printing, concrete subclasses of PrintStream for each platform exist.

Now things are orthogonal and the subclass explosion is gone.

Would there be anything in the way of using this design? OK I have only checked with ArduPlane. Is there some Arduino interface for streams that say they must have printf, and is it necessary to stick with that?

I'd happily implement it - just need to be on the developer list first... :)

Regards

Soren

existingDesignWithAdditions.pdf

newDesign.pdf

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Developer

    The printf family of functions with formatted text messages are very costly on a 8-bit AVR processor (even to some degree on 32-bit ARM), and should be avoided at all cost when doing real time communications. It's mostly there to support the CLI mode.

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @_JonMyer: 🚨Our 1st AWS DeepRacer Community Race is Underway on http://twitch.tv/aws 🚨 Join us to find out which member of your commu…
yesterday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @BackyardRobotcs: After an admittedly long wait, the new Tinymovr R3.3 motor controller is now available https://tinymovr.com 🥳
Monday
DIY Robocars via Twitter
RT @_JonMyer: 🏎 1 hr left before the #AWS #DeepRacer Community 🏎 Top 5 Race tomorrow LIVE on Twitch 1st Place = $50 Amazon GC or AWS Credit…
Monday
DIY Robocars via Twitter
Friday
DIY Robocars via Twitter
Oct 15
DIY Robocars via Twitter
Oct 14
DIY Robocars via Twitter
RT @davidfsmith: Race virtually with The AWS DeepRacer Community Race and then join us on the track to see how your times compare on the ph…
Oct 14
DIY Robocars via Twitter
Oct 14
Hiroki Tanaka liked Hiroki Tanaka's profile
Oct 13
DIY Robocars via Twitter
RT @breadcentric: It's now!
Oct 13
DIY Robocars via Twitter
RT @SahikaGenc: Happy Prime Day! AWS DeepRacer is available at a 30% discount today! @sunilmallya #AWSDeepRacer https://www.amazon.com/AWS-DeepRacer-Fully-autonomous-developers/dp/B07JMHRKQG/ref=sr_1_5?dchild=1&keywords=deepracer&qid=1602609599&sr=8-5
Oct 13
DIY Robocars via Twitter
RT @chr1sa: Printing all the parts for @DIYRobocars https://t.co/ygRxBBBQbi
Oct 11
DIY Robocars via Twitter
RT @chr1sa: Cool new @donkey_car controller app (iOS or Android). Can even do training in-app. Impressive! cc @DIYRobocars https://t.co/XD…
Oct 11
DIY Robocars via Twitter
RT @chr1sa: Drifting with @donkey_car! This is an example of the fully autonomous @DIYRobocars we race monthly now (virtually, in the shar…
Oct 10
DIY Robocars via Twitter
Oct 9
More…