DPRG
DPRG List  



[DPRG] Return of the AVR Mega-Geek

Subject: [DPRG] Return of the AVR Mega-Geek
From: Paul Bouchier bouchier at classicnet.net
Date: Sat Feb 20 23:15:22 CST 2010

Jon - thank you for contributing pointers to the TimedAction and FSM
classes. I have looked at the Arduino library many times and had not seen
those very valuable classes. 

TimedAction let's you create a kind of poor-man's thread scheduler such as
you'd find in an RTOS. Since it implements a rudimentary thread, I guess one
could even use it like a semaphore, where one thread can trigger another
thread. I imagine creating a thread to run every 1ms, then having it call
disable() on itself so it would wait to be enabled. You would have the
triggering thread call the triggered thread's enable() method. The triggered
thread would call it's disable() when it was done. Thus the thread's name
becomes a semaphore. If it would work, it would be pretty powerful. I
suspect the usual multi-threading traps await those using such a technique,
only perhaps simpler because scheduling is not pre-emptive.

Can you use this technique or others to pend threads on a mutex? 

Finite State machines are a very powerful technique, as you say.

This thread has had embedded it it the idea of comparing WinAVR and Arduino.
While I'm very ignorant of WinAVR & gcc support for AVR, IMHO the power of a
development environment is directly related to the power of its libraries. I
think that's where the Arduino environment shines for robotic use - it has
libraries for so many weird hardware-related things that you can use to
accelerate development. Yes, you can write functions to bit-bang I2C
devices, and run timers, and do serial I/O, and all that stuff, but if you
have libraries that do all that grunt work for you, you can spend more time
at a higher-level making more powerful software. That, in my opinion, is one
of the big values the Arduino environment brings.

Regards

Paul

> -----Original Message-----
> From: dprglist-bounces at dprg.org 
> [mailto:dprglist-bounces at dprg.org] On Behalf Of Jon Hylands
> Sent: Friday, February 19, 2010 7:13 AM
> To: dprglist at dprg.org
> Subject: Re: [DPRG] Return of the AVR Mega-Geek
> 
> 
> On Thu, 18 Feb 2010 23:37:10 -0600, "Dick Swan" 
> <dickswan at sbcglobal.net> wrote:
> 
> >.         Drive straight for two feet 
> >.         Turn right 90 degrees. 
> >.         Grab balls from storage rack 
> >.         Turn left 180 degrees. 
> >.         Drive straight for four feet 
> >.         Drop balls into scoring container 
> >.         And so on for the next task/activity. 
> >
> >It?s most natural to program this as a linear sequence of function 
> >calls. You could also fit this into a ?main loop? 
> architecture but then 
> >you need to have variables for managing the state (and various sub 
> >states) of each activity and you have to program the 
> activities so that 
> >instead of a single function call they need to be designed to be 
> >repetitively called until they return a ?activity finished? 
> return code 
> >whereupon you move to the next state.
> 
> I personally find it much simpler to implement scenarios like 
> the above using a finite state machine. The Arduino has a 
> really nicely implemented FSM class available that works 
> well, and fits nicely into the main loop metaphor. 
> 
> If you program the above using a linear sequence of calls, 
> its very difficult to ensure that the sensors are being read 
> and responded to correctly all the time.
> 
> For instance, my latest mini-sumo, Seeker 2x, although not 
> implemented with the Arduino library, could be, and we're 
> actually planning on doing the port sometime later this year.
> 
> http://www.huv.com/miniSumo/seeker2x
> 
> Here's what my main loop looks like:
> 
> 	while (1)	// outer loop is once every 10 ms
> 	{
> 		// pause for 10ms...
> 		previousCount = gTickCount;
> 		while (gTickCount == previousCount);
> 		LEDHeartbeat ();
> 		processSensors ();
> 		processRemote ();
> 		fsmExecute ();
> 	}
> 
> I have the following states:
> 
> enum mainStates {
> 	NO_STATE = 0,
> 	SETUP_STATE = 1,
> 	WAITING_FOR_BUTTON_STATE = 2,
> 	PAUSE_STATE = 3,
> 	SHUTDOWN_STATE = 4,
> 	REMOTE_RED_BUTTON_STATE = 5,
> 	REMOTE_GREEN_BUTTON_STATE = 6,
> 	LAUNCH_STATE = 7,
> 	LAUNCH_SWEEP_STATE = 8,
> 	HUNT_STATE = 9,
> 	HUNT_PIVOT_STATE = 10,
> 	HOMING_STATE = 11,
> 	FOUND_EDGE_STATE = 12,
> 	FOUND_SIDE_STATE = 13,
> 	BACKOFF_STATE = 14,
> 	BACKOFF_SPIN_STATE = 15,
> 	BACKOFF_STRAIGHT_STATE = 16,
> 	BACKOFF_STRAIGHT_TURN_STATE = 17};
> 
> Each state is fairly simple, and does one or two things.
> 
> I can't imagine trying to implement this using anything other 
> than a finite state machine...
> 
> Later,
> Jon
> 
> 
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org http://list.dprg.org/mailman/listinfo/dprglist


More information about the DPRG mailing list